Top 6 Tips for a .NET Upgrade

So the time has come to upgrade your project to a new version. This can sometimes be a scary task for larger code bases that have many “dark corners” and are making a large jump in version number from one Long Term Support (LTS) version to another. In general, doing a small jump is easier than doing a big one. For example going from version 4.7 to version 4.8 is typically easy, and has many fewer factors that could change. Going from version 3.5 to 4.8 is what some developers call a “lift and shift” because there are lots of changes between versions. These are often the upgrades that cause the most headache for developers. Here are some tips to help get the job done.

Tip #1 - Check Compatibility of NuGet Packages

When doing an upgrade make sure all the NuGet packages have compatible versions for the version of .NET you are upgrading to. For .NET Framework developers, there was a lot of development for .NET Framework 3.5. Many packages built with that version may hold off on upgrading because it is a special extended LTS version. However, there are still many packages with up-to-date versions available.

Tip #2 - .nuspec Files

If your project has a nuspec file, and you are upgrading to a more modern version of .NET it is recommended to place the NuGet references in the .csproj file. This will help declutter the folder structure of your project, and make it easier for reviewing NuGet related items with the rest of your project settings. Most modern IDEs will have some type of tooling to help you migrate from a nuspec file, but it may not hurt to look at the Microsoft documentation to see what your specific version recommends.

Tip #3 - Picking the correct version

We need to think about support vs functionality with the versions we pick. Being on the newest version will grant you the most functionality because it will have the most features built into the language. The downside to being on the newest version is there could be bugs that have not yet been found. If you happen to be one of the unlucky few people to find a bug in a programming language you know what I am talking about. Finding bugs like this could cause your development to grind to a halt until a patch is released. This patch could take days or weeks for Microsoft to publish. I recommend being on whatever the second-newest version is, except for new LTS releases. For example, I wouldn’t recommend upgrading to .NET 7 unless the features outweigh the risk for you. I generally recommend an LTS version like .NET 6 for larger projects that may take a month or more to upgrade versions.

Tip #4 - Upgrade frequency

Companies with large code bases may be more hesitant to perform an upgrade if nothing is currently broken. There is nothing wrong with this line of thinking because “why should we risk possibly breaking the thing that makes us money” is a very common thought. My recommendation is to at the bare minimum stay within Microsoft’s supported versions just in case you find a surprise issue. If your codebase is on an unsupported version, there is nothing Microsoft will do.

Tip #5 - Microsoft’s Upgrade Assistant

There is an official tool used for migrating projects to new versions. This could be a really fast way of performing an upgrade on smaller and simpler projects. I would recommend checking out their website for more information: https://dotnet.microsoft.com/en-us/platform/upgrade-assistant

Tip #6 - Bring in Consultants

If you have never done an upgrade it may be a good idea to bring in a consultant. At DevObsessed we have Senior and Principal consultants that are very experienced in performing upgrades and migrations. Feel free to visit our Contact Page, and give us a call. We would be happy to have a chat and find out more about your upgrade project.