AX7 ERROR: "External DLL Name" Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

Hello there,

At times, we get this kind of error when dealing with the external DLLs within X++.  If you look at the error, it is not much descriptive enough to understand, it says retrieve the LoaderExceptions property for more information.  So, we really need to know what’s inside the LoaderExceptions.  There are many ways to track the LoaderExceptions, a simple debugging would help.  But we were stuck with this error only when the solution is deployed in Azure, but works just fine in the local VM.  The Azure one was only for Demo, so we could not go with the debugging approach here.  Luckily, we do have logging feature where all the errors would get logged into a file. 

First thing first, modify the respective “catch” statement in the DLL codebase to dig deeper and retrieve the LoaderExceptions.

catch (System.Exception ex)

{

      Log(ex.message); //this would log the LoaderExceptions error

      //here is where we go deep and retrieve the details

      if (ex is System.Reflection.ReflectionTypeLoadException)

      {

          var typeLoadException = ex as System.Reflection.ReflectionTypeLoadException;

          var loaderExceptions = typeLoadException.LoaderExceptions;

          foreach (var errorItem in loaderExceptions)

          {

              Log(errorItem.Message);

          }

       }

 }

Now, go run the process, it will show up the error with more details.  This is what we got in our case,

ERROR: Could not load file or assembly <DLL name>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

This <DLL name> is not same as what we got in the original error, as we have more DLLs referencing each other in our case, it is little complicated.  But, we ensure that all the DLLs are added as References in the solution model. 

There are some articles that talks about these kind of errors, see the links below:

https://blogs.msdn.microsoft.com/asiatech/2013/01/09/how-to-resolve-the-could-not-load-file-or-assembly-issues-on-windows-azure-web-sites/

https://blogs.msdn.microsoft.com/avkashchauhan/2011/02/23/exception-could-not-load-file-or-assembly-dll_name-or-one-of-its-dependencies-the-system-cannot-find-the-file-specified-in-windows-azure-vm/

Just make sure your solution model follows what is specified in the above links.  In our case, it seems like Yes, but still the error does not go awayL. 

After a little struggle, it is found the problem was with the deployment.  Usually, when you deploy AX7 model, you create a package and deploy using LCS (the first time at least).  The package you create does include the DLLs so thought it may not be required to manually copy over the DLLs to the respective folder in Azure VM.  But it some cases, it is very much required, otherwise, the solution won’t work.  We actually had done that in the local VM!  The LCS automation is what was driving us crazy!

Go to IIS manager > Locate the AOSWeb service > Locate the “bin” folder within > right-click “bin” folder the select “Explore”.  It will take you to the File Explorer and to the respective path.  Typically, the path is “C:\CustomerServiceUnit\Dobind\Packages\Cloud\AosWebApplication\AosWebApplication.csx\roles\AosWeb\approot\bin” in local hosted VM and would be different in Azure hosted ones.  Place your DLLs there and restart AOSWeb service and IIS.  Bingo!  The error goes away and it works just fineJ. 

Couple of things to note here, this process is not always required for all the external DLLs we consume in our solution.  Perhaps, which is why, Microsoft does not automate this during LCS deployment.  But in certain complex scenarios where we have different DLLs and referencing each other in a complex way, this seems to be required. 

Cheers!