Quantcast
Channel: Visual C# forum
Viewing all articles
Browse latest Browse all 31927

shared embedded assembly resource not working

$
0
0

Hi there, I've got a tricky problem.  I'm trying to use embedded assemblies so that I can have a single EXE deployment.  ILMerge is not an option here.

There is one main exe.  Let's call this main.exe.

There is one shared library assembly.  Let's call this shared.dll.  All assemblies have a reference to this.

There is one other assembly called pluginmanager.dll.  This manages plugins.  It is referenced by main.exe.

There are 10 other plugin assemblies.  All reference shared.dll.  None are directly referenced.  They are loaded via reflection.

OK here is what I have done:

- all assemblies are embedded as resources into the main.exe

- The main.exe has a static Program() constructor which creates an AssemblyResolver.

- I have confirmed that the AssemblyResolver does in fact load shared.dll before any other of my assemblies load

Please keep in mind I am not new to embedded assembly resources.  I've done this many times. But this is the first time I've had library assemblies that referenced other library assemblies, and the exe assembly has referenced both.  This is also the first time where I've loaded assemblies through embedded resources which in turn load other assemblies that are also embedded resources via reflection.  Perhaps that is not possible? 

The issue is it doesn't work, I am unable to load any of the other plugin assemblies.  The resolver event doesn't even fire for them.  I thought AssemblyResolver would work for both referenced assemblies as well as those loaded dynamically?

Shared.dll loads just fine.  pluginmanager.dll loads just fine.  None of the other plugin assemblies can be loaded dynamically via reflection by the pluginmanager.

This is another important key point.  If I place shared.dll on the file system, then the plugins DO load dynamically from embedded resource.  I'm completely befuzzled by this.  At this point when they are loaded, the shared.dll has ALREADY been loaded into the domain and resolved via AssemblyResolver!!!  But the plugins, which do reference this shared assembly, do NOT see it!  But it's already in the domain!?!? 

This seems odd.  The shared.dll assembly loads fine dyanmically from the resource.  The plugin manager loads fine. But these were both directly referenced from the main.exe.  The other plugin assemblies don't load, and none are referenced.  But they do in turn reference shared.dll, which has already been loaded into the domain.  If I put shared.dll back on the disk, where .Net normal assembly searching rules can find it, the plugin assemblies will load from embedded resource just fine.  But if I remove it from disk, they won't, yet the shared.dll they are referencing has already been resolved and loaded into memory for this Domain!

Seems very broken to me, but 100% reproducible.

Anybody have any idea why this wouldn't work, and if so, how to work around it?

Thanks,
Ryan






Viewing all articles
Browse latest Browse all 31927

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>