Dynamically created assemblies

Dec 8, 2014 at 9:44 AM
Hi, I probably have the most advanced scenario of them all:
  • The main app should be using libz.
  • It dynamically creates assemblies (using CodeDomProvider.CompileAssemblyFromDom() ).
  • Assembly references are passed in as compiler parameters.
    Those assemblies should now move to a libz archive, possibly embedded in the main assembly.
  • The created assemblies are loaded into an extra AppDomain.
    This aspect should be solved as indicated here.
Compilation only works if referenced assemblies exist on the file system. Does anybody know a way to work around this? Maybe using Roslyn? Anyway, this looks very hard to do.
Dec 8, 2014 at 9:52 AM
Edited Dec 8, 2014 at 9:55 AM
I'm not really sure if I understand what you are doing but someone was using LibZ in separate AppDomain with success. Take a look here.
Oops, just realized you are already refering to this item.

I belive your problem is related to CodeDomProvider.CompileAssemblyFromDom() working in separate AppDomain, and I guess, you have no way to hijack this AppDomain as it is created behind the scenes?

Can you create really simple standalone example of your problem? I could try play with it in free time.
Dec 9, 2014 at 11:17 AM
I created a simple example, you can get it as ZIP here.
It contains a console project referencing a class library that should be included in the final exe or in a separate libz file.
The generated class derives from a base class that is defined in that class library. This requires an assembly reference during compilation and this is the challenge for libz.

BTW: I am impressed by your level of support.
Dec 10, 2014 at 10:42 AM
FYI: Your case requires some changes to LibZ itself but it is achievable.
The problematic line is:
Yeah, but this assembly does not have location (as it was load from memory).
I will add such functionality (assembly will force-saved to disk before being loaded so it will have location) but I need few days.

Dec 10, 2014 at 11:15 AM
Cool, I wasn't expecting you to change LibZ just for this case!
Will /can you do the force save only when accessing Location the first time? Otherwise it may be a performance penalty for other use cases that do not need Location. Or will there be an extra step to manually temp-persist LibZ-stored assemblies?
Jul 17, 2015 at 2:59 PM
Edited Jul 17, 2015 at 3:00 PM
I just tried with the current version on the master branch ( and the new option --safe-load for the add command. Now it works fine, thanks.
Do you have plans for releasing this version? It would be nice to get it by nuget instead of building the code myself.
Jul 20, 2015 at 2:17 PM
I had some problems testing it then I got distracted by some other project, but if you are saying it works for you I can release it then.
Jul 21, 2015 at 9:36 AM
Edited Jul 21, 2015 at 11:11 AM
You can test it yourself, just have a look here at my example project from above, extended by use of libz to move all DLLs (via containers) into one EXE. The libz-stuff is done in the a post build task of the csproj.

To make it all work, I first tried the approach used by ivan5o but realized I don't need it but I don't fully understand why. Still, I had to register a simple assembly resolver. See LibzAppDomainHelper.cs which I put into the ClassLibrary1. I put it there to show that it works too and because in my real world scenario I don't create my new AppDomain in code of the main app but in such a class library, hence the helper needs to be in a class library.

And yes, from my point of view you could release this version.