Dynamics 365 Business Central and .NET 6

The upcoming Dynamics 365 Business Central 2023 Wave 1 version introduces an important server change: the NST server now runs on .NET 6. This is a huge improvement to the entire platform expecially in terms of performances and resource optimizations:

• Up to 30% faster AL runtime
• The NST is using less memory

But this new changement has also an effect on partners: .NET interops with .NET Framework assemblies do not work with version 22. I wrote a post about this long time ago to prepare for the change (see here), but now it’s time to act!

How can I act?

To be ready for the changes, the best choice that you can do is trying to avoid using .NET add-ins and instead moving them to external services. This is the best way to do in terms of SaaS-compatibility and in terms of Universal Code compatibility.

But if you’re still forced to work in an old-fashioned on-premises way and so using .NET add-ins, you need to move them from .NET Framework to .NET 6.

Updating your applications to target the latest version of .NET is easy if you already are on .NET Core or .NET 5. If you’re in this case, in Visual Studio, simply right click on your project in Solution Explorer and choose Properties. Under Application > General > Target framework, choose .NET 6.0:

Save, rebuild your application and you are done! Your app now runs on the latest version of .NET. In the future when new version become available, you can upgrade in the same way.

Migrating from .NET Framework could be something more difficult because there are more differences between .NET Framework and other platforms that were built on top of .NET Core. My suggestion is trying to use the Upgrade Assistant tool and in particular I want to mention that now there’s also a Visual Studio extension for this tool (so no more CLI).

Now you will be able to upgrade every type of .NET application from any initial version (.NET Framework or .NET Core) by right-clicking on your project in Solution Explorer and choose Upgrade.

The tool is not magic. The general philosophy of Upgrade Assistant is that it will take care of the mechanics, but depending on what framework and project type you’re upgrading from, you should expect to do some manual post processing. 

The Upgrade assistant tool supports the following 3 upgrade types:

• In-place. In this case your original project will be upgraded all at once.
• Side-by-side. With this option your original project will be untouched, and a copy of it will be added to the solution which will contain the upgraded code. This type can be handy if your application has many dependencies that might be broken after the upgrade. This way you can check-in your progress and not worry about the application not building.
• Side-by-side incremental. This is the ideal choice for web applications. Upgrade from ASP.NET to ASP.NET Core requires a lot of work and at times manual refactoring (because these two technologies are very different). Incremental upgrade will put a .NET 6/7 project next to your existing .NET Framework project and route endpoints that are implemented in the .NET 6/7 project there, while all other calls will be sent to .NET Framework application. This way you can combine upgrade with feature development and move your items to .NET 6/7 one by one without breaking your app. 

If your .NET add-in is composed by different components, you can also select the components to upgrade one by one:

When using .NET 6 add-ins, please remember that .NET Core and .NET 6 have no GAC concept, so in your Visual Studio Code project you need to edit your workspace or project settings.json file and add here the path to the relevant .NET 6 assemblies, like for example:

{
   "al.assemblyProbingPaths":[
      "C:\\Program Files\\dotnet\\shared\\Microsoft.AspNetCore.App\\6.0.14",
      "C:\\Program Files\\dotnet\\shared\\Microsoft.NETCore.App\\6.0.14",
      "./.netpackages"
   ]
}

The lack of this could cause also errors like “cannot convert from ‘DotNet “System.Xml.XmlNode”‘ to ‘DotNet “System.Xml.XmlElement”” which may happen if the list of assembly probing paths doesn’t include the .NET 6 assemblies location and the AL runtime resolves the assembly to the one in GAC which targets .NET Framework.

Please also remember that .NET 6 runtime or SDK aren’t part of the Windows installation and you need to install them from here in order to start creating applications.

Start upgrading your add-ins as soon as possible to .NET 6 (or better, start moving them to external and cloud-compliant services).