2

I'm loading new assembly (CLRHostHelper.dll) using Assembly.Load( byte[] ) method. From that assembly I'm calling AppDomain.CreateDomain - method throws exception:

Exception thrown: 'System.IO.FileNotFoundException' in mscorlib.dll Additional information: Could not load file or assembly 'CLRHostHelper, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

To my best understanding new appDomain creation can only proceed only if there physically exists .dll on disk (Using AppDomainSetup domainSetup = new AppDomainSetup() { ApplicationBase = inDir }; it's possible to specify from which folder) - and it's not possible to load it in ram only.

It's possible to use AppDomain.CurrentDomain.AssemblyResolve += newapp_AssemblyResolve; - but that event is applicable only to current appDomain, not to newly created.

It's also not possible to immediately hook AssemblyResolve of new appDomain - there is no such method.

In class AppDomainSetup - there exists also AppDomainManagerAssembly and AppDomainManagerType - more info can be found from here: https://blogs.msdn.microsoft.com/shawnfa/2004/11/12/the-managed-hosting-api/ In theory we could create our own AppDomainManager, and override EntryAssembly to provide our own assembly, but:

domainSetup.AppDomainManagerAssembly = Assembly.GetExecutingAssembly().FullName;
domainSetup.AppDomainManagerType = "EchoAppDomainManager";

Here you again specify assembly name, which in a turn needs to be loaded from disk.

In here - http://andrewzak.tumblr.com/ - Small .NET desktop applications. Turning on shadow copying. there is some mentions about similar problem, and potential walk around using SetAppDomainManagerType - but no practical example of performing this operation. Maybe you can find someplace else ?

Can anyone recommend me how to create appDomain from assembly that is in ram without performing any loading from hard disk (everything would be kept in ram).

TarmoPikaro
  • 4,723
  • 2
  • 50
  • 62
  • AFAIK, this is not possible because `AppDomain.CreateInstanceAndUnwrap` wants the assembly name and will load it from disk. You said you'd be loading the DLL from disk anyway, why not use the DLL for `AppDomain` stuff as well? Or a more general question, what is the use case here, i.e. why do you need to dynamically load assembly which then in turn creates `AppDomain`? Why not create the `AppDomain` in the calling code? – rbm Nov 04 '16 at 22:39
  • I'm analyzing deeper answer to this question: http://stackoverflow.com/questions/40293194/unload-mixed-mode-assembly Currently I can create unloadable assembly, but I want to get rid of additional C# hosting .dll from disk (Unnecessary clue). It's possible of course to survive without removal of this dll, but I really want to understand alternatives here. Why I cannot just load and unload assembly ?! Why I cannot do it from ram ? – TarmoPikaro Nov 04 '16 at 23:29

0 Answers0