Take the 2-minute tour ×

So, I'm making a customized installer for a project of mine, and what I needed was to "pack" everything in one file. (I couldn't use ILMerge or .NETZ because one of the things I had to include was an unmanaged (was that how it was called?) assembly.) Anyways, I read a lot of stuff mainly from here, and people were saying to do this:

  • Add the .dll as an Embedded Resource;
  • Add a handler to the AssemblyResolve method so it fires up when my application can't find the assembly
  • In that handler, make it load the .dll from memory using a function that transfers the input stream into a byte array which the Assembly.Load() can use.

I did all that stuff and I added a normal reference to the .dll, so my code can compile properly. However, when I delete the .dll file from the directory where the application is, and try to run it, the "Failed to load file or assembly..." dialog (or whatever it was, you know what I'm talking about) pops up and tells me that it couldn't load my .dll, although I explicitly told it to load it from that byte array in the AssemblyResolve EventHandler.
I'm sorry if this is something which has been answered before. Looking at the recommended similar questions, I can't see an answer to this, though.
The only thing I could see that might be related is that "C# would not allow me to load from bytes, unless I'm in a high-security context." If anyone knows anything, can you please confirm/deny this statement, and tell me what a "high-security context" is? I admit, I'm a noober at complicated stuff. :)

Thanks in advance for your time and answers!

share|improve this question
add comment

1 Answer

Assembly is another name for managed dll - native dll's won't end up in the AssemblyResolve bit afaik. I don't know if there's any other option but saving the embedded dll to disk at startup, but I haven't found an option to tell the OS (which is responsible for loading unmanaged dll's) how to find the embedded dll.

share|improve this answer
"native" dll is equal to "managed" dll, is that so? Oh well, the user on here that had said the thing about the security context also said that it was no trouble if the assembly was streamed to disk, and then loaded from there using the Assembly.Load(filename);. I'll give that method a shot, we will see... –  Lumos Jul 2 '12 at 7:03
"managed", and "assembly" in this case are .NET-dll's. "unmanaged" and "native" are non-.NET dll's. The term "native" means the dll cannot be used on different platforms, where .NET dll's are not platform specific. –  C.Evenhuis Jul 2 '12 at 7:48
@C.Evenhuis Location of the dll should either be in the Environment PATH variable or the location from where the application is running. Best way to look for the locations where OS tries to search the dll is using sysinternal's ProcMon(technet.microsoft.com/en-us/sysinternals/bb896645.aspx) by monitoring the file read/write activity of the application's process. –  Amit Mittal Jul 5 '12 at 7:14
@AmitMittal in other words, a native dll has to be a file on its own, right? –  C.Evenhuis Jul 5 '12 at 8:59
As the easiest way, yes :). But as an overly complex implementation, even native dlls can be loaded entirely from memory by simulating what LoadLibrary method of win32 API (the workhorse that actually loads a native dll in the process address space) does. It also essentially reads the dll file in memory and then do its stuff. Something like this (though this is entirely in C++, this can be done in C# as well) joachim-bauch.de/tutorials/loading-a-dll-from-memory. –  Amit Mittal Jul 5 '12 at 9:51
add comment

Your Answer


