At runtime loaded assembly cannot find embedded assembly.
jnsn
Posts: 5
I am trying to obfuscate an application which loads libraries from a sub-folder at runtime. The libraries in the sub-folder reference libraries in my main folder which I embed in my main executable. (It might be worth noting that I am using the Microsoft Prism v4 framework.)
Example:
The setup from listing 1 works, after embedding the CoreA and CoreB assemblies my application fails when it tries to load PluginA.
My question is: why is this happening? It's my understanding that, when the main application is launched all libraries should be available from the application domain. Or am I missing something here?
Example:
Application + Plugins - PluginA.dll - CoreA.dll - CoreB.dll - Main.exe... becomes ...
Application + Plugins - PluginA.dll - Main.exe
The setup from listing 1 works, after embedding the CoreA and CoreB assemblies my application fails when it tries to load PluginA.
Could not load file or assembly 'PluginA, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
My question is: why is this happening? It's my understanding that, when the main application is launched all libraries should be available from the application domain. Or am I missing something here?
Comments
On the face of it, I'm not sure what is going wrong here. Although the CoreA / CoreB Dll's are embedded I don't think this should stop them being able to load the plugin dll (assuming that the file still exists separately).
Is it possible for you to let us know a little more about how the files are loaded, or, if possible, set up a simple example solution that demonstrates the problem? If that's possible, then could you mail it over to support@red-gate.com referencing F0061451 in the subject line? Thanks!
Redgate Software
The correct error message is:
So the problem is not that CoreA.dll is unable to load PluginA.dll, but PluginA.dll is not able to load CoreA.dll.
I will try to create a sample application later today and send it through.
Redgate Software
As I stated in my email, the main reason I choose to embed assemblies is because some things are quite hard to obfuscate. For example the data model used by several other assemblies contains a lot of public classes and properties. In one of the first releases we simply obfuscated the library without embedding which resulted in some users abusing it and modifying their saved data. After embedding it became hard for them to detect where the assembly was and how to use it.
So if possible I would really like to stick with this approach.
Normally the way you'd get around this is to also embed the referencing assembly but as it's a plugin type thing, I guess you can't?
One option is to obfuscate the two separately so they can still be found, but you said this isn't ideal. The other option which *may* work (I've not had chance to try yet) is to obfuscate the current assemblies as you are doing, then reference the combined/obfuscated assembly? Not sure if this work, I'll try and test it out today if I get chance, but if you've got some time yourself you may also want to see.
Redgate Software
Embedding the required assemblies in my plug-in has been an idea, but I would guess this might not always work. It is possible my main application is updated while my plug-ins are not. As long as one of the referenced assemblies does not contain a breaking change they should still work. I assume that the first assembly using another assembly is responsible for loading them into the application domain. So let's say that the plug-in loads CoreA first, using his embedded version, it is possible that another assembly which requires a new function added to CoreA cannot find that function and this would lead to a whole new set of problems.
Redgate Software