[mikece]

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]

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.

[mikece]

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.

[metaltyphoon]

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

[orra]

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.