The breaking changes are very well documented and are esoteric in nature. https://learn.microsoft.com/en-us/dotnet/core/compatibility/...

Scott Hanselman has a very short blog on how 20 year old code is upgraded to the latest .NET in just a few short minutes: https://www.hanselman.com/blog/upgrading-a-20-year-old-unive...

▲

AtNightWeCode 2 days ago | parent [-]

Bs, basically, the docs about upgrading between frameworks and what works with what is actually pretty current and often disappears after some years. Especially anything about edge cases. Several upgrades also demands that you do the upgrade version by version. It is tedious work if you don't have a full understanding of the app. Nuget has also become a complete dependency hell. Today you often have to point out what to use to get your legacy apps to build with newer .NET versions. You can't just go with latest.

▲

licon4812 2 days ago | parent | next [-]

I just upgraded a .NET Framework 3.5 Windows application to .NET 9, with little to no issues. I even decided to remake it as a WinUI app instead of leaving it in WinForms. The entire process took me less than 2 weeks, of just casual development

▲

GreymanTheGrey 2 days ago | parent | prev [-]

"Several upgrades also demands that you do the upgrade version by version"

This seems unlikely. Do you have a source?

	▲	AtNightWeCode 2 days ago \| parent [-]
		I upgraded hundreds of projects. The docs with breaking changes are by version. For smaller solutions you can create a new solution and pull in the code and try to fix everything that breaks. There is also an upgrade tool that can work for smaller projects. But the fastest way for normal sized solutions is to update version by version up to the closest LTS. Then you can go LTS to LTS. .NET does also not only break in code, it breaks in behavior so you really want to test those changes in isolation.