A long path away from the .NET Framework. Part 1 - Prerequisites.

Our company has a relatively big desktop product that still uses the .NET Framework. We tried to switch to .NET 5 in 2020 but we had one dependency that we could not make to work for the .NET Core family because it used things that were considered legacy even for .NET Framework. But this time it was way more successful and this is a story about how we were switching from .NET Framework to .NET 6 and what issues we had on our way.

But before you do anything you need to know why are you doing it. This is a really important question because such a huge change will create a lot of regression and your clients will be upset because they don’t care about the technology you are using. It is your problem and they all care about the bug-free product. So let's start to explain why we decided to make this move.

While Microsoft stated that the .NET Framework will be supported for quite some time, they clearly stated that they will not do any development and will only make sure that it will continue to work on any new OS they release and fix security issues. And they obviously will not fix any bugs unless they impact a lot of users. And 100% there will be no new features.

All new development happened with the .NET Core family only. All new features, all new language features and it is open source which can help debugging any issues. And I used this quite a lot. And lastly, because it is open source, there is a probability that we can fix some bugs by ourselves.

Because it is open source and hosted on GitHub it is much easier to get support and I also did it a few times. The developers are quite helpful there and each time they helped me with my issues.

Next, our source code is quite big and we are using quite a lot of packages. Some time ago we found that some packages simply don’t have versions for the .NET Framework anymore. And I can understand why because the latest C# version supported by the .NET Framework is 7.3. So if you are a developer of some package you must limit yourself to using C# 7.3 or place ugly #ifdef’s if you want to use any new language features.

And the .NET 6 is faster. When we compare the performance of the .NET Framework with most ngen’ed images and .NET 6 without R2R, almost all tests show a performance increase. All regressions were attributed to slightly slower startup time.

We are not planning to stay on .NET 6 and the next step would be to switch to the .NET 8 and it is even faster. And this is before we added Ready To Run which will increase startup time.

The latest versions of C# make developers much more productive and spend less time doing “monkey work”. Also, from my point of view, nullability is quite a nice feature after I got used to it. It means fewer bugs and less money spent fixing them.

I think everybody understands that if a company is using one of the technologies that are in high demand then you have a bigger selection of potential developers and more potential “stars”. And the opposite is also true. The less compelling the technology the fewer “star” candidates you will have and eventually it will start to hurt business.

This applies not only to new candidates but it will also to existing employees. Most developers love to play with new stuff and because it is the latest and greatest it will look quite good in the eyes of your developers.

Next, the .NET Core can work on different OSes. Right now our product is strictly for Windows but who knows what will happen in the future. For example, we found that we can run a few tools in a Linux environment and it costs way less than a Windows environment for any cloud provider.

And last and probably most important thing: the longer you wait the more painful it will be. We had this experience with many other tools. Switching from version X to X+1 is usually easy unless there are some critical bugs. Let's say there are 50 bugs. Around 35-40 bugs we will find internally. Maybe 10 will be found by our beta testers and 1-2 will be in public builds.

And in this case, customers in general will tolerate it because bugs are side effects of any development. But if we switch from version X to version X + 10 then there will be 500 bugs and as a result around 10-20 bugs will make it to the public builds. And when the same customer finds a few of them it will create an impression that the whole product is broken and buggy and it upsets any customer. And it is one of the reasons we are switching to .NET 6 and not to .NET 8.

In the next part, we will go over how we implement it.