Using AutoLoader with dependencies

[Anonymous]

<?xml version="1.0" encoding="utf-8" ?>
<ApplicationPackage SchemaVersion="1.0" AppVersion="1.0"
    ProductCode="{20F44DBA-0878-4ADE-91A4-E540E45A37FB}"
    Name="Menus"
>

  <CompanyDetails
    Name="Automation Inc."
    Email="au@automation.com"
  />

  <Components>
    <RuntimeRequirements SupportPath=".\Contents\" SeriesMax="R19.0" SeriesMin="R19.0" Platform="AutoCAD*" OS="Win64"/> 
    <ComponentEntry ModuleName=".\Contents\Data.Mapping.dll" AppName="DelcoMapping" AppType="Dependency">
        <RuntimeRequirements SupportPath=".\Contents\" />
    </ComponentEntry>
    <ComponentEntry ModuleName=".\Contents\Menus.dll" AppName="Menus" AppType=".Net" LoadOnAutoCADStartup="True">
    </ComponentEntry>
  </Components>

</ApplicationPackage>

I set the support path, and even define the component entry to look for the Data.Mapping.dll in the contents folder.  This file exists there however everytime I start AutoCAD it says it cannot load file or assembly Data.Mapping.dll in the C:/Users/User/Documents/ folder

So I am at a loss, how much more explicit can you get as to where this file is located in the packagecontents.xml???  Why does AutoCAD not read the file from the location which has been clearly specified? 

[Anonymous]

I am not building and supplying the path to LoadFrom because the code that calls LoadFrom is in a third party library.  Luckily in this case I have the source code that I can modify, so it is not a huge deal now that I understand what is going on.

This is why it threw me for such a loop, I did not even know about or ever used LoadFrom.  If I was going to build something extensible that dynamically loaded assemblies I would try use MEF which may or may not have avoided all this.

My main concern is that everytime I update that library this same issue is going to come up if I can't convince them to change their code base.  If I set the CurrentDirectory then this should allow me to upgrade the library as it is released without having to worry about changing this code every time.

The library is based around Entity Framework using a generic repository.  The mapping files are for linking POCO objects to the SQL server data store.

[Anonymous]

I had a similar problem to drauckman. Prior to using appautoloader my plugin assembly did not have any trouble finding direct dependencies. I had problems finding the dependencies of the direct dependencies. To resolve this issue I implemented AssemblyResolve Event and using the AppDomain my assembly was able to locate these "missing" dll's. A good article on AssemblyResolve can be found here: https://weblog.west-wind.com/posts/2016/dec/12/loading-net-assemblies-out-of-seperate-folders

While trying to deploy my AutoCAD plugin using the appautoloader I had similar error messages to drauckman - "Could not load file or assembly 'file///C:\...\Documents\Microsoft.Bcl.AsyncInterfaces.dll". Again similar to drauckman the appautoloader was looking for these assemblies in my Documents folder. Furthermore, the AssemblyResolve Event I implemented previously was no longer getting called.

I did not find a ton of documentation on this, but the solution I stumbled upon was to add a Component Entry in PackageContents.xml for every assembly that was not found. See example component entry below.

<ComponentEntry

AppName="YourAppName"

Version="1.0.0"
ModuleName="./Contents/Microsoft.Bcl.AsyncInterfaces.dll" />

Adding a component entry for every offending assembly resolved the issue for me.

[fenton_webb]

Some extra points which might be useful to you guys:

1. The bundle goes to a shared folder for all Autodesk apps to process. So make sure you have specific RuntimeRequirements for platform, os and series
2. The ComponentEntry's inside a Component section are loaded in bottom to top order, the main app loads last (the first entry)
3. The autoloader will add the path to your dependency if it is registered in the ComponentEntry. However, if you don't want the autoloader to also automatically load the dependency set the ComponentEntry->ModuleType = "Dependency". Also, you should know that the ModuleType is inferred from the file extension so it is not normally specified but that means a .dll will be netloaded which you might not want if it's a resource dll or unmanaged dll.

[Anonymous]

Also, for what it is worth. I am finding that (if I don't have component entries for missing dll's in PackageContents.xml) appautoloader is looking for assemblies in the current location of the drawing, which for me is my Documents Folder.

Again, add component entries for each offending assembly resolves this issue.

[fenton_webb]

If you don't specify the missing dlls in the package then it resorts to the OS dll dependency loader, nothing to do with AutoCAD.

[Anonymous]

Thanks for the tips Fenton.

It took a few hours to sort out xml syntax errors and dependency issues. So far, I am very happy with the appautoloader and will be using it for updating and deploying a local app for my company.

Thanks for your work.