.NET

[#1]

Hi guys

I recommend you take a look at this bundle example http://adndevblog.typepad.com/autocad/2012/06/autocad-performance-gauges-app.html

It shows how to load multiple DLLs, and also how to automatically hook into the Autoloaders prebuilt AssemblyResolve event handler.

Also, take a look at this white paper http://adndevblog.typepad.com/autocad/2013/01/autodesk-autoloader-white-paper.html

[#2]

Would it be much trouble to copy project, delete most files, and strip down to one or two functions just for something to reference each other and post project?

[#3]

I did not see those articles previously, thanks!

The only two things I could see in those examples that I did not try was assembly mappings and the component entry with appname, version module etc.

I have tried different combinations of this in the PackageContents and it does not change the functionality.  I have tried the suggestion on the other page to 3. Load the extra dll before actually needing it: and 4. Handle AppDomain.AssemblyResolve event and load the assembly there (My AssemblyResolve event handler is never called though, why I do not know)

If this is true:

"One of the features of the Autoloader is the ability for it to load WPF Dll’s away from the acad.exe directory; it does this by implementing an AssemblyResolve event handler."

Then it means that AutoCAD is messing around with the same event handler I am trying to get into, although I read the last handler registered wins.  This does not appear to be the case for me.

There are two very important points to remember though -> This project can be loaded/run by using Netload, from the exact folder and structure that the bundle is in. 

Maybe though there is a reason why?  I do not understand how during the development/debugging process you can use Netload with no problems and then when you want to deploy all of a sudden there are these mysteries?  IMHO if you can hit Netload, point to an assembly and everything fires up, you should be able to have this equal functionality in the Autoloader, otherwise why introduce it if you have to go back to messing around with registry etc.

I see in the gauge example on that page that you have many assembly mappings, and I do not understand why these are required, I have a total of 8 .dll's and as long as they are all in the same folder as the dll that I am loading everything works.  I only have a single contents folder though so maybe when the layout gets more complex with versions etc I might need the same?

I did not see anywhere in the gauge example where Assembly.LoadFrom was used and this is currently the only part that is giving me a problem, the other assemblies can be found as far as I can tell.

Since all my other assemblies whether or not they are WPF, class libraries etc get loaded fine I suspect that there is a problem with how the Autoloader is handling the AssemblyResolve event or something related to its functionality.  All of the AssemblyResolve code in the gauge example is redundant and if you removed it everything *should* still load, AssemblyResolve is only called when an assembly can't be found.

[#4]

Any chance you can post your bundle so I can take a closer look for you?

[#5]

This the last iteration of the bundle that I created

[#6]

I get this error, do you see the same? If so, I'd like to know the code you have in that function please...

[#7]

The picture does not show up for me in any browser that I try

[#8]

Doh!

Looks like pointing to file on his computer.

[#9]

Just guessing, that the failure is happening before you've added the AssemblyResolve handler. If you can put it in another assembly that gets loaded before the one that's having the problem, it may be called.

[#10]

After a quick look at your bundle, here is what I would suggest you do.

1.  Remove everything from your MyPlugIn.Initialize() method, and put it in another static method on the MyPlugIn class.

2. In MyPlugIn.Initialize() add a handler for the Application.Idle event.

3. In the handler for the Application_Idle event, remove the handler from the event, so it is called only once, and then call the method that contains the code that you removed from Initialize().

The basic idea is to defer execution of that code until after the Autoloader has finished doing whatever it is doing that is causing the code to fail, so that it executes in the same context it would execute if  your plugin was loaded via NETLOAD.

This is really just a workaround, that you need to use to avoid having to dig a hole to China to find out what exactly is causing the failure. The AutoLoader doesn't seem to have any kind of built-in self-diagnostics that would allow you to identify what it is doing and deduce the cause of unexpected failures.  White papers are helpful, but built-in self-diagnostics that could be enabled to see what is actually going on, would be far better.