How to use local version of C# dll instead of IIS loading default version of the library in an X++ Project ?

(0) Share

Report

Posted on by Pragun Saini

Hello,

I have a C# project where I have added 2 Nuget packages for Microsoft.Azure.Storage.Common and Microsoft.Azure.Storage.Blobs.

I also have a X++ project where I use this C# project. So I first build the C# project and then add it as a reference in my X++ project.

The issue I am facing is that there is already an older version of Microsoft.Azure.Storage.Common.dll present in AosService\PackagesLocalDirectory\bin directory.

The library I have included is present in K:\AosService\PackagesLocalDirectory\MyModel\bin after the build.

Now during runtime, when the X++ code calls the .Net classes, IIS service loads the version of the library from PackagesLocalDirectory instead of MyModel's directory. Which gives me an error in my code.

I tried to delete the dll from PackagesLocalDirectory, in which case it is loading the dll from MyModel's bin and my code runs fine in this case.

Now I don't want to delete dlls from PackagesLocalDirectory and it's also not possible in production. Is there any way so I can load my version of the dll at runtime ?

Also one similar question I have is how to make these additional dlls I am adding for libraries available in the deployable package for production deployment ?

I have the same question (0)

All responses (9)

Answers (3)

André Arnaud de Cal... 300,911 Super User 2025 Season 2 on at

Like (0)

Report

Hi Pragun,

Are you able to change your C# project to also use the same dll version? Or will that limit your possibilities?

Was this reply helpful? Yes No
Verified answer

nmaenpaa 101,160 Moderator on at

Like (0)

Report

As far as I know, you need to use the versions that are included in the standard application. I don't think that the system can load two different versions of the same library at the same time. How would it know which one is called from the code? They have the same name after all.

Was this reply helpful? Yes No
Pragun Saini on at

Like (0)

Report

Thanks for your response Nikolaos.

I tried this out. The default version of Microsoft.Azure.Storage.Common.dll is 10.0.3.0 (the one which is present as part of standard package).

The one I added in my project is version 11.2.3.0. This was causing the issue since the system was picking up the older version.

So I tried to instead use 10.0.3.0 version of the library in my code and now it seems to work without errors since it is also using same version as standard package now. So as per your suggestion, I should use the same version of dlls for those packages that are present already as part of the standard application, right ? And will this not cause any issues in case the standard libraries get updated (although I am not sure if they ever get changed by any platform updates or not).

One thing I also want to ask is that I am also using Microsoft.Azure.Storage.Blobs library in my project. This one isn't present in the standard package, I have downloaded it and the version I am now using same as the other one i.e 10.0.3.0 because they are compatible. So in this case I'll add this dll in my deployable package and then this dll will be used from my model whereas the other one will be picked from the standard bin folder. Is this approach correct or should I be doing something else ?

Was this reply helpful? Yes No
Verified answer

nmaenpaa 101,160 Moderator on at

Like (1)

Report

If MS would ever update the standard Azure Storage DLLs in D365FO, your code might break. But because MS has promised that they don't do breaking changes they are stuck with the old version. So I'm not sure if they will ever update it.

And yes, you can add additional DLLs as part of your deployable package.

Was this reply helpful? Yes No
Pragun Saini on at

Like (0)

Report

Thanks for your help Nikolaos.

Was this reply helpful? Yes No
Suggested answer

Joris dG 17,775 on at

Like (2)

Report

Those DLLs will get updated at some point. In fact, the documentation points out we only guarantee X++ code compatibility. If you take dependencies on any non-X++ binaries like the ones listed here, we may break you without warning.

docs.microsoft.com/.../one-version

So it's important if you do have these sort of dependencies, to have an easy test you can run prior to taking an update to ensure your code is still working correctly.

Was this reply helpful? Yes No
Pragun Saini on at

Like (0)

Report

Thanks for the information Joris.

So can you tell me what is the best way to use any additional library I want to use that is not present as part of the existing X++ packages. For example, Azure.Storage.Common was present already but I added a new library Azure.Storage.Blobs. Currently I just added it to the C# project and via that I am using it in the X++ code. But as you say if they update the existing package of the Common library, this may not work anymore. What is the approach recommended to add and use new packages in our projects.

I have tried to find some docs but other than basic examples couldn't find much. If you have any reference or examples for this kind of requirement, please share it.

Was this reply helpful? Yes No
Verified answer

Joris dG 17,775 on at

Like (1)

Report

Unfortunately, there is no good answer here. All the code runs in the same process, so DLLs can only be loaded once. To ensure the standard application keeps working, the F&O server is designed to load DLLs from our binaries first (which is why you see it ignoring your version).

I would encourage you to make sure you can test these dependencies quickly and easily, preferably automated, so you can check it with every update.

The only alternative would be to run your logic outside of X++. Create an Azure Function or some other process which you can call from X++. That outside process can load whatever dependencies it may need freely.

Was this reply helpful? Yes No
Pragun Saini on at

Like (0)

Report

Makes sense.... thanks a lot Joris !

Was this reply helpful? Yes No