Dynamics 365 Business Central on-prem: be careful when referencing .NET assemblies across versions.

Last week I received a an help request from a partner that was in the middle of a Dynamics 365 Business Central on-premises upgrade process for a customer (yes, on-prem still exists ).

An old customer with a Dynamics 365 Business Central version 14 installation needed to be updated to version 25. This customer has a custom PTE used for integrations with an external system and unfortunately this PTE has Target = OnPrem because it directly uses some .NET assemblies like Microsoft.Data.SqlClient to connect to the external systems (Target = OnPrem in an extension should be absolutely always forbidden in your internal development policy IMO, but this is another topic).

The Microsoft.Data.SqlClient package supports the following environments:

• .NET Framework 4.6.2 (and above)
• .NET 8.0 (and above)

The partner’s developer setted in the app.json file of the extension the required application version to version 25.0.0.0 and the runtime version to 14.0 (so minimum Business Central supported version for the app was set to version 25).

The partner’s developer compiled the extension locally with a .NET Framework version of the Microsoft.Data.SqlClient DLL and everything was compiled correctly:

Then the partner’s developer placed the Microsoft.Data.SqlClient.dll file in the Add-Ins folder of the service tier and published the extension in the production environment. Result:

Error AL0451: An assembly named ‘Microsoft.Data.SqlClient, Version=6.0.0.0, Culture=neutral, PublicKeyToken=23ev7fc2d6eaa4a5’ could not be found in the assembly probing paths.

Why this?

It’s not the first time I see this error occurring, so a quick post could help someone for the future.

Business Central .NET Core support was introduced with the 2022 release wave 2 (version 21), which allows .NET add-ins to be compiled targeting the .NET Standard runtime. From Business Central version 21, all add-ins installed in the service tier must be compiled with .NET Standard, otherwise the extension cannot be published. I wrote different posts on this topic years ago, if you’re interested you can start from here.

But why the AL compiler is not throwing any error if the extension’s target is a Business Central version that is supporting only .NET Standard?

The AL compiler is (at least at the moment) able to load both .NET Standard and .NET Framework compiled assemblies that you have specified in the al.assemblyProbingPaths folders. This is the reason of the successfully executed compilation of your AL code. But when you publish the extension to your service tier, the assemblies must be strictly compiled using .NET Standard.

Recommendation is to always be careful with assemblies. If you’re targeting Business Central version >= 21, please check all your assemblies also in your local AL project repository. These must be .NET Standard compliant. If you replace some assemblies in the folders specified in the al.assemblyProbingPaths, remember also to reload Visual Studio Code (otherwise the compile could cache the old assemblies).

Original Post https://demiliani.com/2025/07/14/dynamics-365-business-central-on-prem-be-careful-when-referencing-net-assemblies-across-versions/