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:
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!
