4 ms·

At only three years the "LTS" releases aren't exactly "long term" either.

by mikece 2y ago

orra 2y ago
True, for a corporation it's not that long. But as a developer it's nice for there to be momentum for platform updates. I discovered last week that .NET Framework v3.5 is still technically supported. Shudder.
- mikece 2y ago
  Why shudder? Sure, devops to VMs instead of .NET Core containers isn't as nifty but there is something to be said for code that can run for 5+ years without needing to be touched. Zero-maintenance is a big selling point but right now MSFT is requiring us to update ALL of our code just to rev the version every 36 months (not counting security issues -- we lost more than two weeks of productivity eradicating the Newtonsoft exploit at my last company).
  - neonsunset 2y ago
    Staying with .NET Framework is a factor that increases talent attrition and the cost because less people are willing to work with it. This is without discussing technical downsides.
    - metaltyphoon 2y ago
      > Staying with .NET Framework is a factor that increases talent attrition 100% this. If a company is not willing to move the product forwards because "there is no need to" then I would be looking else where. .NET Core will be a decade old very soon and a company not willing to move to that tech stack is just pure neglect.
    - mikece 2y ago
      You're assuming a workshop where there's just one significant app. The last several places I've worked there were dozens of apps, microservices, and APIs; some of the old and stable APIs were .NET Framework and those never needed to be touched. We built all of the new hotness using .NET Core, Blazor, and whatever the JS framework de jour was, all without needing to touch the old, stable, and working Framework code happly humming along in its VM.
  - orra 2y ago
    But even old .NET code needs touched. Every month, transitive dependencies need upgraded for security fixes. And that's when you realise SDK style projects are much nicer than the old project files. The tooling has massively improved in the past decade.

At only three years the "LTS" releases aren't exactly "long term" either.

by mikece 2y ago

At only three years the "LTS" releases aren't exactly "long term" either.

orra 2y ago

True, for a corporation it's not that long. But as a developer it's nice for there to be momentum for platform updates. I discovered last week that .NET Framework v3.5 is still technically supported. Shudder.

mikece 2y ago
Why shudder? Sure, devops to VMs instead of .NET Core containers isn't as nifty but there is something to be said for code that can run for 5+ years without needing to be touched. Zero-maintenance is a big selling point but right now MSFT is requiring us to update ALL of our code just to rev the version every 36 months (not counting security issues -- we lost more than two weeks of productivity eradicating the Newtonsoft exploit at my last company).
- neonsunset 2y ago
  Staying with .NET Framework is a factor that increases talent attrition and the cost because less people are willing to work with it. This is without discussing technical downsides.
  - metaltyphoon 2y ago
    > Staying with .NET Framework is a factor that increases talent attrition 100% this. If a company is not willing to move the product forwards because "there is no need to" then I would be looking else where. .NET Core will be a decade old very soon and a company not willing to move to that tech stack is just pure neglect.
  - mikece 2y ago
    You're assuming a workshop where there's just one significant app. The last several places I've worked there were dozens of apps, microservices, and APIs; some of the old and stable APIs were .NET Framework and those never needed to be touched. We built all of the new hotness using .NET Core, Blazor, and whatever the JS framework de jour was, all without needing to touch the old, stable, and working Framework code happly humming along in its VM.
- orra 2y ago
  But even old .NET code needs touched. Every month, transitive dependencies need upgraded for security fixes. And that's when you realise SDK style projects are much nicer than the old project files. The tooling has massively improved in the past decade.