At runtime loaded assembly cannot find embedded assembly.

jnsn

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:

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?

James B

Thanks for your post.
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!

jnsn

Oops, it seems that by editing my copy paste I've made a mistake.

The correct error message is:

Could not load file or assembly 'CoreA, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

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.

James B

Ahh, okay, that would make more sense. If it's trying to dynamically load it in any way, it won't be able to find it once it's embedded. I see you've sent a sample in so I'll take a look just to confirm that and see if there's a simple way around it.

jnsn

Thanks!

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.

James B

OK, I've had a quick look, and because the Plugin references the two Core DLL's these need to be found at runtime. Because they've been embedded into the main assembly, they cannot be located and thus you get the error.

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.

jnsn

Embedding the plug-in is not an option, indeed. These are sold separately or made specially on a customer request base.

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.

James B

Sorry, I was thinking more of referencing the main + core combined assembly after obfuscation from the plugin, not embedding the core ones into the plugin itself - does that make sense?