Hacker News Reader

Comment by orra | Hacker News Reader

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.

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).

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.

> 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.

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.

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.

Reply on news.ycombinator.com