<?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?
Solved! Go to Solution.
Solved by drauckman. Go to Solution.
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.
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.
Some extra points which might be useful to you guys:
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.