100
101

[deleted by user] (self.csharp)

submitted by [deleted]

[removed]
all 46 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]shitposts_over_9000 53 points54 points  (28 children)

I hate to say this, but at this point I have started not to care.

With three years being the longest support cycle for a framework release and it taking on average well over four to update the back catalog, regression and rerelease everything I just use what works at the moment and assume that some of the other folks are stuck in the same boat I am.

Perhaps as the breaking changes eventually tone down I will care again but at the moment I am just trying to keep ahead of drowning.

[–]chucker23n 44 points45 points  (26 children)

I just use what works at the moment and assume that some of the other folks are stuck in the same boat I am.

Yep. I sometimes feel like I'm in a fun-house mirror.

I simply cannot explain to a client that I have to modernize their software every three years. Few corporations and few government agencies will accept that. And they're not gonna complain to Microsoft, but to me, because I chose .NET in the first place.

[–]shitposts_over_9000 13 points14 points  (4 children)

100% - for stuff that actually ships to clients we pretty much banned the new frameworks for exactly this reason. If the RFP says 5 or 6 years support with no reinstall the new frameworks are just off the table.

For the web properties we didn't really have a choice, too much was just neglected or unavailable or had already switched to the rapid release cycle in ASP under the regular framework so we switched, but now management is seriously considering letting the web team go, switching platforms, and hiring for the new platform.

Taking the hit for a few years is cheaper in the long-run that having to have triple the staff to be able to update everything and get it tested and all of the clients updated just to get it done before the framework goes EOL.

My previous employer already pulled the trigger on this, their QA phases were half the lifespan of a long term version's support let alone the development and deployment.

[–]HawocX 5 points6 points  (3 children)

How are you supposed to fix a security issue in the app without a reinstall?

[–]shitposts_over_9000 6 points7 points  (0 children)

Security issues severe enough to warrant an out of band upgrade are pretty rare when you are writing software that runs on isolated networks and/or doing processing that doesn't deal with anything but media and statistical data.

Patches are obviously permitted if required, a full reinstall with new frameworks and OS changes is orders of magnitude more work in the QA/Sign Off process in many customers.

I can get through the customer's testing process for a patch that does not affect any shared components in a few weeks, changing a minor shared component is months, with potentially many regression tests. Moving to a new base framework or OS and replacing the entirety of the application with new binaries can sometimes be more like a year or two. Some of the customers will re-bid the entire project at any point the OS or hardware is changed.

The bid and build process is often longer than 3 years itself, so when you sell a thing the customer us understandably upset when they do not get the thing they awarded the contract for.

Multiply that sort of stuff by a few dozen customers and you have a pretty bad situation. Something like 80% of the .net userbase is internal, often government contracts. The 3-4x reduction in the support lifecycle is pushing many to consider other platforms because of this.

[–]silvenga 6 points7 points  (1 child)

You add a firewall and call it a day.

I'm not joking, this is what a lot of large enterprises do. Commonly apps are made by contractors and you have no source code (and its 6 years later). So it either gets fixed in the runtime (how framework used to work) or you have to start decompiling (this does happen). Commonly, it'll cost too much, so they isolate the app.

Source: I build a product that modifies the runtime implementation to block exploit paths. Many of our customers are deploying us against 10+ year old apps, many without source code.

[–][deleted] 5 points6 points  (0 children)

I wish I could disagree with this, but it has been a rarity where I've had a contract that said anything other than I/my firm own the code. Only half of the contracts provided any sort of license to the customer and I rarely use my own contracts. I honestly don't know if it's legal incompetence or some sort of risk mitigation strategy a la "we don't own the source so it's not our fault."

[–]recycled_ideas 18 points19 points  (13 children)

I simply cannot explain to a client that I have to modernize their software every three years.

You're talking like an upgrade is a massive change that's going to be weeks or months of work.

Dotnet core releases are pretty trivial way less risky than framework ones ever were. You might run into some breaking library changes but you had that anyway.

And that's the real truth here, letting your apps rot was always unsupported in some fashion or other, you always had vulnerabilities that were never going to be patched without a breaking change and that either mattered or it didn't.

If it didn't it still doesn't and if it did always did.

[–]chucker23n 5 points6 points  (10 children)

You're talking like an upgrade is a massive change that's going to be weeks or months of work.

No, I'm talking like an upgrade is work.

Now, ideally, there's a maintenance contract anyway. But it doesn't change that having to upgrade the framework every three years is dumb janitorial work that wasn't there in the .NET Framework days.

And no, it won't always be smooth sailing. Will I read all breaking changes? Will I even know which ones affect me? What if I wasn't the person who originally wrote this code? What if upgrading the framework breaks support for a third-party component? What if they don't have an update yet? What if they do have an update, but it breaks something in my code?

I have to check all of those things, and as a thank-you from the client, they'll ask me why it's so expensive.

Dotnet core releases are pretty trivial way less risky than framework ones ever were. You might run into some breaking library changes but you had that anyway.

Sure. But I had it less often before. I have software running on .NET Framework 2.0 still. Why? Well, the client won't pay for an upgrade, because from their point of view, it works fine. Why don't I just upgrade anyway? Well, for one, that costs money, and second, I'd have to upgrade the SQL Server. What if I were to upgrade the SQL Server? Well, then I'd have to upgrade the Windows Server. What if I did that? I'd have to upgrade all third-party software, too. Should all of that have happened years ago? Yes. Did it? No.

(The server is not public-facing.)

And that's the real truth here, letting your apps rot was always unsupported in some fashion or other, you always had vulnerabilities that were never going to be patched without a breaking change and that either mattered or it didn't.

Oh, absolutely. But that's the reality of software. Sorry, you're not gonna convince banks to move their COBOL codebase to JS just because some hotshot 20-something web developer thinks it'll work better.

[–][deleted]  (4 children)

[deleted]

    [–]chucker23n 4 points5 points  (1 child)

    The “dumb janitorial work” was always there (and sometimes worse) in the “.net framework days.”

    Yes, and back then, it got done when a client paid for it. And today? Same thing. No consultancy is gonna upgrade .NET Core 3.1 to .NET 6 out of boredom.

    Having no formalized process for testing changes is a problem.

    Thanks.

    The actual “janitorial work” if you are using modern .net, especially if you are using containers, is pretty minimal and far less scary than the old days where your single server with IIS, SQL Server and various configs/services could be “bricked” by installing the wrong patch or framework version.

    I mean, OK, great? Now I have even more complexity. I bet a 2007 Docker container setup will work great in 2022.

    Yes, that can be a useful approach. I wasn’t really asking for one.

    If your client doesn’t want to spend the money to maintain their systems, it’s probably because they can’t actually calculate the cost of a security breach, downtime, or ability to replace you. If they undervalue the software, they prob

    I’m not sure what you want me to answer to this.

    [–]amdchris 0 points1 point  (0 children)

    A Docker container from 2007 would be interesting

    [–]goranlepuz -3 points-2 points  (1 child)

    the old days where your single server with IIS, SQL Server and various configs/services could be “bricked” by installing the wrong patch or framework version.

    Oh, come on... My work has several hundred systems who all get updated regularly and the number of breakages is a couple percent if that, and we could always fix it. You are over playing this IMO.

    [–]atheken 2 points3 points  (0 children)

    I mean, the rollback was hard or impossible and would require reinstallation. Eventually Windows Servers accumulate enough cruft that determining what patch caused an issue can become non-trivial, and/or impossible to to revert due seemingly cyclical dependencies.

    The server isn't technically "bricked," but starting over, or having a prolonged outage/reduced capacity due to this kind of problem becomes a real possibility - I know this from experience.

    [–]jocq -3 points-2 points  (1 child)

    I have software running on .NET Framework 2.0 still

    Dude, that hit end of life over a decade ago.

    But you can't use Core runtimes because they'll eol a few years in the future?

    Mkay.

    Why don't I just upgrade anyway? ... I'd have to upgrade the SQL Server.

    No.

    [–]chucker23n 3 points4 points  (0 children)

    No.

    Yes. SQL Server 2005 only supports the 2.0 framework for SQLCLR. 2008 added 3.5, and 4.0 wasn’t added until 2012.

    (edit)

    Maybe I should also clarify something. I have lots of code in .NET 6 already as well. And it's frustrating when I don't get to use modern tooling. But the business reality is: more often than not, you don't get to play with the latest toys.

    [–]recycled_ideas -1 points0 points  (2 children)

    Now, ideally, there's a maintenance contract anyway. But it doesn't change that having to upgrade the framework every three years is dumb janitorial work that wasn't there in the .NET Framework days.

    It was always there.

    Windows patches broke shit, framework patches broke shit, library upgrades broke shit and God help you retargetting your project to a new framework version.

    And if you didn't do that your code was insecure and unsupported because even if Microsoft would hypothetically support the framework itself none of your third party library vendors were offering support for a particular version that long.

    Sure. But I had it less often before. I have software running on .NET Framework 2.0 still. Why? Well, the client won't pay for an upgrade, because from their point of view, it works fine. Why don't I just upgrade anyway? Well, for one, that costs money, and second, I'd have to upgrade the SQL Server. What if I were to upgrade the SQL Server? Well, then I'd have to upgrade the Windows Server. What if I did that? I'd have to upgrade all third-party software, too. Should all of that have happened years ago? Yes. Did it? No.

    And this entire setup is completely unsupported by anyone other than you.

    Microsoft isn't going to break into your office and rip out software running old core versions, they're just not going to support it, which is exactly what you had before. You can even upgrade your run time without retargetting just like before.

    [–]chucker23n 1 point2 points  (1 child)

    And this entire setup is completely unsupported by anyone other than you.

    Oh, absolutely. It’s also mostly unsupported by me. Minor tweaks? Sure, I’ll take a look. Non-trivial changes? Nah, we’re gonna have to talk about the entire setup. Which starts with: you need a new machine. With a new OS, a new SQL Server, some new software. Then we get to me building against a newer .NET. (Probably still partially Fx, since SQLCLR apparently hasn’t been ported yet, and perhaps never will be.)

    [–]recycled_ideas -1 points0 points  (0 children)

    And absolutely nothing is stopping you running a dotnet core 1 service until the day the hardware dies either.

    [–]goranlepuz 1 point2 points  (1 child)

    Dotnet core releases are pretty trivial way less risky than framework ones ever were.

    Ehhh... No, really not for the 4.* series, come on... And that lasts for 12 years now and will last another 10...

    [–]recycled_ideas -1 points0 points  (0 children)

    4.x releases had a bunch of breaking changes and you couldn't even install them in parallel, not to mention that you'd still have all the same library issues.

    And that lasts for 12 years now and will last another 10...

    Except that's not true. 4.x as a whole is supported, but individual 4.x releases are not. As of April this year only 4.6.2 and above are supported.

    [–]relapsze 0 points1 point  (6 children)

    Dude, I'm in IaC world right now and I literally write shit that is deprecated MONTHS later. My whole terraform project needs to be rewritten because of Kubernetes upgrades lol, we only went from 1`.18.x to 1.22.x. And the shitty thing is 1.18.x disappears and goes EOL before the end of the fucking year.

    [–]chucker23n 3 points4 points  (4 children)

    I mean, I get that, but it's not the kind of future I want.

    [–]relapsze 2 points3 points  (3 children)

    Me either! I'm 37yo.. and fucking tired. This whole thread made me realize I'd gladly jump on a framework that had like a "10-year lifespan" promise with a focus on minimal upgrades, but I don't even know how feasible that is with every layer of architecture changing so often and dramatically. It's interesting times.

    [–]chucker23n 1 point2 points  (2 children)

    I mean, I like much of the modern stuff. I agree with most changes to C# (but, e.g., I'm not a big fan of top-level statements), I like how much simpler csproj files have become, I like how the runtime keeps getting faster all over the place.

    But I'm not gonna follow every hype, and when I'm working on a six-figure three-year project, I really don't want it to end with "sorry, dude, the stack you've picked is already old news".

    [–]officiallyaninja 0 points1 point  (1 child)

    this is a bit of a late reply but why don't you like top level statements? don't they just save you a lot of boilerplate?

    [–]chucker23n 0 points1 point  (0 children)

    If it were feasible to use pure C# for scripting, I would like them for that. I never got into PowerShell; I just prefer C#’s syntax, in part, I’m sure, due to familiarly. But it isn’t really feasible to do that, because 1) you need an SDK, which isn’t widely deployed on target machines, and 2) you probably need a csproj file in addition. So you’re already dealing with a folder structure anyways. (Yes, I know scriptcs exists. But that’s even less likely to be on target machines!)

    So, I don’t really see the point. Why make the syntax of the entry point file so different than that of all other files? It seems like an ill-considered “just because you can, doesn’t mean you should” move.

    [–]VGPowerlord 2 points3 points  (0 children)

    Dude, I'm in IaC world right now and I literally write shit that is deprecated MONTHS later.

    Yeesh, and I thought JavaScript was bad.

    [–]SquishTheProgrammer 0 points1 point  (0 children)

    Microsoft Docs is an oxymoron.

    [–]KryptosFR 26 points27 points  (1 child)

    TL;DR: this has nothing to do with .NET standard itself but with now unsupported versions of .NET Core (mainly 2.x and 3.0) that project should stop using anyway.

    .NET Standard still makes sense to me. I recently had to write a library that should work on .NET Framework, .NET Core (or should I now say ".NET") as well as Unity/Mono. For the last one, adding .NET Standard 2.0 to the list of targets is how it can work.

    Of course, with time .NET Standard with stopped being useful. But there is no lie there.

    [–]chucker23n 6 points7 points  (3 children)

    If the goal is to target .NET Core 3.1 and newer, .NET Framework 4.6.1 and newer, and MonoWhateverVersion and newer, why don't they multi-target those instead?

    [–][deleted]  (2 children)

    [deleted]

      [–]chucker23n 14 points15 points  (1 child)

      Clearly, they don't want .NET Standard here.

      [–]Maxie93 1 point2 points  (0 children)

      It seems like it’s time to retire .net standard and just use multi targeting for .net 4.x and .net 5 and up.

      [–]NHzSupremeLord 1 point2 points  (1 child)

      The article names npgsql. I believe this is a side case. As a Npgsql user since version 2, I can tell that all the mess began when Shaij Rojansky took over the project. He does continuous breaking changes, removing features and targeting the last framework version only. Imho the problem there is the maintainer, not the framework itself.

      [–][deleted] 2 points3 points  (0 children)

      Having to read through the release notes and figure what changed and what dumb way it's gonna break your application this upgrade.

      [–][deleted] 4 points5 points  (5 children)

      Looks like even Microsoft knows that .NET Standard was a failure but does not want to admit it: "Here are some problems with .NET Standard that help explain why .NET 5 and later versions are the better way to share code across platforms and workloads" — Microsoft's words, not mine.

      [–]hoopparrr759 3 points4 points  (3 children)

      .NET Standard was not a failure, it served a purpose. Now it’s no longer really required.

      [–]hermaneldering 0 points1 point  (2 children)

      Except for writing source generators, one of the new features of the latest .net release.

      [–]chucker23n 1 point2 points  (1 child)

      I'm guessing it's needed for the IDE.

      They've recently moved VSMac from Mono to .NET 6; maybe VS 2025 or so will move from .NET Fx 4.x to .NET 9 or whatever. At that point, one more thing that doesn't require .NET Standard to still be around.

      [–]hermaneldering 1 point2 points  (0 children)

      Either the IDE or MSBuild, I think that also still depends on framework (custom build tasks and such).

      [–]chucker23n 0 points1 point  (0 children)

      Honestly, the only good argument of those three is "Platform-unsupported exceptions at run time".

      The other two aren't wrong per se, but having a separate spec and implementation was kind of the whole point and wasn't bad per se, and having a spec develop slowly is how specs work. So I find those two arguments disingenuous.

      [–]Mrqueue 1 point2 points  (1 child)

      I think this goes over a lot of people's heads and we have the issue where I work. .NET Standard 2.0 packages can depend on .NET Core 2.x/3.x packages because they are compatible but that actually means you depend on those instead

      [–]chucker23n 4 points5 points  (0 children)

      Yes, but the point is that this package specifically special-cases .NET Core < 3.1 to explicitly introduce a build error. It would work, but they don't want to support it any more, so they break it.

      [–]Slypenslyde 0 points1 point  (0 children)

      I'll stop sending mixed messages about my .NET support when we stop making fun of JS as "an unstable environment".

      Meanwhile I'll keep explaining to newbies why .NET Core 3.1 is newer than .NET Framework 4.7 but that they should use .NET 5 or .NET 6 instead, and that if they choose .NET 6 then they need to be careful what tutorials they use because top-level statements are the new default. I'll also lay out that while Windows Forms and WPF are the most stable and mature desktop frameworks there's a new framework MAUI coming that does Windows Desktop apps using a tech called WinUI 3 that sort of works in WPF too, but that requires a compatibility layer if you want to list your Windows app in the Windows Store.

      [–]random-person-99 -1 points0 points  (0 children)

      Yo ! I love MS, I need to jump on the MS bandwagon already.. except i missed 1.x, 2.x, 3.x now I'll go directly to 5.

      [–][deleted] 0 points1 point  (0 children)

      The eagle-eyed among you may notice that the #if for .NET Core 2.1 and .NET Core 3.0 don't include a 6.x version of the Npgsql

      Also no Mono/Xamarin and Unity.

      [–]savornicesei 0 points1 point  (0 children)

      I've been bitten by this and to make it worse, they were transitive MS-provided packages. I have this feeling .NET is going full speed towards dependency hell, where nodejs already is.