.NET instability
(In-)stability in .NET

Reading time: 2 min.

Over the last 5 years I have programmed against .NET 4.5 to 4.8 and then 5.0 to 8.0. There have been several transitions and they have not been smooth (but neither impossible). Luckily the code I write only uses mostly the computational side of .NET, and the pain has been mostly in the tooling and interaction with the outside world.

The first transition from 4.8 to 5.0 was mostly painless. We switched to netstandard 2.0. Nice, finally some explizit guarantees. The tooling changes around nuget and the dotnet tool itself broke our CI scripts several times. Luckily our projects were already in the new XML format.

The transition from 5.0 to 6.0 was mostly painless. We stayed on netstandard 2.0. We had to drop support for one UI on 4.8, because a particular service library was 6.0 only. We slowly arrived at a sane integration of a few chosen nuget packages.

The transition from 6.0 to 8.0 was hard. Netstandard 2.0 was dropped and we had used BinarySerializer in a completely contained fashion. There went 1/2 year redoing the serialisation.

So now we are looking to a major biennial upgrade. The next one will be to 10. There are no stability and forward compability guarantees. Which sucks a lot trying to build stable things. The tech stack is given for me, but the JVM ecosystem looks a lot greener in this regard.

Personally, I would welcome a reduced netstandard 3.0 for computation + basic scheduling + basic IO, which allows stable domain and backend code. UIs and the network side of things will have to update anyhow to keep up with the environment.