Right now, all DLL dependencies (.NET assemblies) in a D365 package get loaded into the same process space as the whole AOS server. This has several drawbacks as it leads us in a DLL hell. If a DLL is included by the AOS or any default package, one must not add another version of the DLL, especially since it is often undefined, which DLL gets lucky enough to get loaded first. This kan wreak all kind of havoc, as the problems are not always reproducible.

This is especially critical with some of the Azure standard DLLs deployed by the standard. If - for whatever reason - you require another (mostly newer) DLL instead, you can't do so (usually leading to Azure Function micro-services or similar constructs).

Beyond that, if you have two ISVs with contradicting dependencies (been there in the past), you are at the whim of the ISV distributors to unify their packages to a compatible dependency version.

As a solution, custom DLL dependencies could be isolated in AppDomains. As a primary solution in .NET to isolate applications or extensions from each other, the AOS should formally support this. Ideally, all non Microsoft packages should use such a mechanism to avoid conflicts (you could check this in ISV / AppSource validations even).

While I'm aware that we can do this at the C# level ourselves, it is a rather deep change we would be doing there. Thus, a standard approach to introducing a new AppDomain with a depending assembly would be important, plus enforcing AppSource packages to use this.

Having the AOS kernel team support this, is therefore paramount.

In a perfect world, there would be an automatic proxying between X++ code and DLLs in their AppDomains.