Unload mixed mode assembly

I have native windows application developed mainly in C++. I would like to put some C# / UI components on top of that application. But main application is rather heavy to start up and debug, I would like for C# to be polite to application and it would be possible to develop UI without closing native application for as long as possible.

In C++ there is always LoadLibrary and FreeLibrary - so developer can release .dll during development of his component, in C# once you load your assembly it's practically impossible to release it. You're dealing with huge amount of documentation on AppDomains and so on.

Can someone propose a way to release C# assembly once it was loaded with as few source code lines as possible ?

I'll now briefly summarize what I know about subject:

• It's possible to create managed .dll and using C++ / cli it's possible to do whatever in your appDomain, but once you have used C++/cli - that .dll becomes load (cannot be freed). (#1)

• It's possible not to use managed C++ at all, but wire function calls using native C++ / COM technology using CLRCreateInstance, GetRuntime, GetInterface ... and so on - but then you're dealing with quite complex c++ / com classes. Just to wire one function call - it's pain in the ***. (managed c++ is easier to use) (#2)

• It's possible to create appDomain from c++ / com. You just call ICorRuntimeHost::CreateDomain. Most interesting thing is that assemblies loaded into that appdomain are not recognized as assemblies by visual studio, debug symbols for those are not available, and breakpoints are not working. You can break execution in a middle of assembly code.

• It's possible to use #2 together with #1 - however - Assembly.Load will not work due to error: "hr 0x80131019 : Attempt to load an unverifiable executable with fixups (IAT with more than 2 sections or a TLS section.)", and using Assembly.LoadFrom will again lock your dll.

• Finally it's possible to use #2 + Assembly.Load, but as loadable project to use C# based project (which is without IAT tables) - then you can finally allocate second appDomain, and start assembly from there. I have prototyped this, and I'll add it as an answer - but aren't there any simpler approach ?

C++ assembly is not possible to build without IAT tables - at least in here there are some mentions about proposed solution:

how to build an executable without import table in c/c++?

But it does not look as feasible solution.