[Rohansi]

The only chaos occurred in the transition from .NET Framework to .NET (Core). Upgrading .NET versions is mostly painless now because the breaking changes tend to only affect very specific cases. Should take a few minutes to upgrade for most people.

[pjmlp]

Except it is a bummer when one happens to have such specific cases.

It never takes a few minutes in big corp, everything has to be validated, the CI/CD pipelines updated, and now with .NET 10, IT has to clear permission to install VS 2026.

[lan321]

If you can't get permission to update/change IDE, the company processes aren't working at all tbh. Same if cicd is in another department that doesn't give a shit.

[pjmlp]

That is pretty standard in most Fortune 500, whose main business is not selling software, and most development is done via consulting agencies.

In many cases you get assigned virtual computers via Citrix/RDP/VNC, and there is a whole infra team responsible for handling tickets of the various contractors.

[da_chicken]

Similar story at my prior job. Heck, we still had one package that was only built using 32-bit .Net Framework 1.1. We were only just starting to see out-of-memory errors due to exhausting the 2 GB address space in ~2018.

I love the new features of .Net, but in my experience a lot of software written in .Net has very large code bases with a lot of customer specific modifications that must be supported. Those companies explicitly do not want their software framework moving major supported versions as quickly as .Net does right now, because they can't just say "oh, the new version should work just fine." They'd have to double or triple the team size just to handle all the re-validation.

Once again, I feel like I am begging HN to recognize not everyone is at a 25 person microservice startup.

[lan321]

I might be missing something but the combination of 'we mustn't break anything' and 'we can't test it without 2-3* team size' sounds like release deadlock until you can test it..

The migrations where I've worked at have always been a normal ticket/epic. You plan it in the release, you do the migration, you do the other features planned, do the system tests, fix everything broken, retest, fix, repeat until OK, release.

Otherwise you're hoping you know exactly how things interact and what can possibly have broken, and I doubt anyone knows that. Everyone's broken things at first sight seemingly completely unrelated to their changes at some point. Especially in large systems it happens constantly. Probably above 1% of our merges break the nightly in unexpected places since no one has the entire system in their head.

Or you're keeping a dead product just barely alive via surgical precision and a lot of prayers that the surgeon remains faultless prior to every release.

[tracker1]

On the migrations... read the comments through this thread.. there are many, and none have mentioned any significant pain points at all, just hypothetical ones from people like you who aren't actually actively using it.

As to the CI/CD pipelines... I just edited my .github/workflow/* to bump the target version, and off to the races... though if you're deploying to bare metal as opposed to containers, it does take a couple extra steps.

As to the "permission to install..." that's what happens when companies don't trust the employees that already write the software that can make or break the company anyway... Defelopers should have local admin privs, or a jump box (rdp) that does... or at the very least a linux environment you can remote-develop on that, again, has local admin privs.

I'm in a locked down environment currently, for a govt agency and hasn't been an issue. Similar for past environments which include major banking institutions.

[pjmlp]

Each one is their own anecdote.

[orphea]

You're describing a specific case of working in a big rigid enterprise. It doesn't have anything to do with .NET itself, does it?

[pjmlp]

Guess where most .NET developers employeers happen to be?

[orphea]

I have no idea about most .NET developers. At my current job (a public software company in US with thousands of employees) it's up to engineers to decide when to upgrade. We upgraded our main monolith app to .NET 10 in the first week.

[pjmlp]

For me, customers IT and their management decides.

[tracker1]

I've been using .Net since late 2001 (ASP+) including in govt and banking and rarely have had issues getting timely updates for my local development environment, and in the past decade it's become more likely that the dev team controls the CI/CD environment and often the deployment server(s).... Though I prefer containerized apps over bare metal deployments.

[pjmlp]

Some devs get lucky.