performance - Memory and CPU impact when a DLL is embedded inside a .NET DLL / EXE? -

we have dll distribute has external dependencies on other dlls. rather risking missing dlls or having potential mix-and-matching situations, embed dlls inside our own dll/exe , load @ runtime satisfy runtime linking.

question:

a) between

• embedding dll inside our .exe/.dll , loading memory @ runtime and
• keeping dll separate file on file system , having system load us

which approach consumes more memory , approximately how much?

b) have better approach above? item #3 in details below.

---

details on our process interested:

1. register assemblyresolve event @ portion know runs before code in assembly called (eg: init time)

   public void someinitcode() {     ...     appdomain.currentdomain.assemblyresolve += (sender, args) =>     {         string[] assemblydetail = args.name.split(',');         var assemblyname= assemblydetail[0] + ".dll";          var thisassembly = assembly.getexecutingassembly();         var allresourcenames = thisassembly.getmanifestresourcenames();          string requiredresname = allresourcenames.singleordefault(a => a.endswith(assemblyname));          using (var input = thisassembly.getmanifestresourcestream(requiredresname))         {             return input != null                  ? assembly.load(streamtobytes(input))                  : null;         }     };     ... }  static byte[] streamtobytes(stream input) {     var capacity = input.canseek ? (int)input.length : 0;     using (var output = new memorystream(capacity))     {         int readlength;         var buffer = new byte[4096];                  {             readlength = input.read(buffer, 0, buffer.length);             output.write(buffer, 0, readlength);         }         while (readlength != 0);          return output.toarray();     } } 

2. embed assembly. done "add existing item" .net project => pick .dll => ok. go , pick .dll , in properties change "build action" "embedded resource".

3. we still have add same .dll reference , still need have using externalnamespace; statements on top of classes using it. if not, build process fails since can't see external dll code @ compile time. post-build action, have delete .dll file (not it's embedded clone) final bin folder.

a: long inner assembly doesn't have huge size (some massive embedded resource, example) should work acceptably - bit of wriggly answer, don't have better 1 other "measure it". i've done similar things (and similar reasons).

b: set "copy local" on reference properties (f4) false. need using externalnamespace; if files in same project - brings namespace play.