Red Gate forums :: View topic - At runtime loaded assembly cannot find embedded assembly.
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SmartAssembly 6
SmartAssembly 6 forum

At runtime loaded assembly cannot find embedded assembly.

Search in SmartAssembly 6 forum
Post new topic   Reply to topic
Jump to:  
Author Message
jnsn



Joined: 18 Jun 2012
Posts: 4

PostPosted: Mon Jun 18, 2012 3:40 pm    Post subject: At runtime loaded assembly cannot find embedded assembly. Reply with quote

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:
Code:
Application
+ Plugins
   - PluginA.dll
- CoreA.dll
- CoreB.dll
- Main.exe

... becomes ...
Code:
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.

Quote:
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?
Back to top
View user's profile Send private message
james.billings



Joined: 16 Jun 2010
Posts: 1123
Location: My desk.

PostPosted: Tue Jun 19, 2012 5:34 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
jnsn



Joined: 18 Jun 2012
Posts: 4

PostPosted: Wed Jun 20, 2012 7:53 am    Post subject: Reply with quote

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

The correct error message is:

Quote:
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.
Back to top
View user's profile Send private message
james.billings



Joined: 16 Jun 2010
Posts: 1123
Location: My desk.

PostPosted: Wed Jun 20, 2012 12:13 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
jnsn



Joined: 18 Jun 2012
Posts: 4

PostPosted: Wed Jun 20, 2012 12:52 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
james.billings



Joined: 16 Jun 2010
Posts: 1123
Location: My desk.

PostPosted: Wed Jun 20, 2012 1:29 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
jnsn



Joined: 18 Jun 2012
Posts: 4

PostPosted: Wed Jun 20, 2012 1:36 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
james.billings



Joined: 16 Jun 2010
Posts: 1123
Location: My desk.

PostPosted: Wed Jun 20, 2012 1:39 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group