locked
How can I load an assembly in a domain-neutral fashion - once per process, not once per app-domain? RRS feed

  • Question

  • Hi.

    We are building a Framework for others to write their components that run out of process.  I'd like my hosting process to treat one of the dlls as domain neutral, specifially, the one which contains custom assembly resolution logic for the framework.  I had suceeded in loading it twice - one in the main domain and one in the hosting domain, so it works, but I'd be nice if I can load it once in a domain-neutral fashion so only load it once.

    How can I do this?

    Thanks,

    --Alex

    Wednesday, July 18, 2012 3:23 AM

Answers

  • You cannot say which assembly will be shared and which not - it is either nothing, all in GAC, or all. No other choice.

    What you have above is different problem - you have same file name loaded from 2 different places. That cannot be fixed by domain-neutral loading. Even in domain-neutral you can end up with multiple assemblies loaded from multiple places and it is correct.

    Find out who and why loads each of the assemblies (e.g. 'sxe ld REDIAppFW.Core.dll' in windbg, or something similar in VS) - take a call stack.

    -Karel

    • Proposed as answer by Mike Feng Thursday, July 19, 2012 11:49 AM
    • Marked as answer by Mike Feng Thursday, August 9, 2012 1:51 PM
    Wednesday, July 18, 2012 3:27 PM

All replies

  • Did you use LoaderOptimizationAttribute?

    Statics will be always domain specific - AppDomain is .NET isolation boundary (think of it as 'lightweight process'). When sharing is enabled, the assembly will share also ngen image accross AppDomains, therefore safe some memory.

    -Karel

    Wednesday, July 18, 2012 3:34 AM
  • Thanks, Karel, but this did not work.   I still see my assembly loaded twice.  Moreover, I was hoping that I could somehow control which assemblies to treat as domain-neutral, and which to not treat that way

    Assembly loaded twice into a multi-domain process

    Wednesday, July 18, 2012 12:21 PM
  • You cannot say which assembly will be shared and which not - it is either nothing, all in GAC, or all. No other choice.

    What you have above is different problem - you have same file name loaded from 2 different places. That cannot be fixed by domain-neutral loading. Even in domain-neutral you can end up with multiple assemblies loaded from multiple places and it is correct.

    Find out who and why loads each of the assemblies (e.g. 'sxe ld REDIAppFW.Core.dll' in windbg, or something similar in VS) - take a call stack.

    -Karel

    • Proposed as answer by Mike Feng Thursday, July 19, 2012 11:49 AM
    • Marked as answer by Mike Feng Thursday, August 9, 2012 1:51 PM
    Wednesday, July 18, 2012 3:27 PM
  • That's not accurate.  I have the same file loaded twice from a single place, but because my 2nd appdomain is configured to shadowcopy files, it, well, shadow-copied the first file into a 2nd location.  So it looks like a process has two distinct files loaded, in reality it's not.  The copy of the 1st file is made by the CLR and then loaded. I was hoping to avoid this altogether. 

    But if you say no other choice, I guess, I have no other choice. 

    Saturday, July 21, 2012 7:31 PM
  • Why do you enable shadowcopy only in 1 AD? Can you either enable it in both or disable it in both? That should IMO help.

    AFAIK shadowcopy is feature for apps like designers - they don't want the original source binary locked, because they will rebuild it (from VS) soon. If you do not have this scenario, I would strongly recommend you not to use shadowcopy.

    If there is any reason why you have to use shadowcopy, please share it here, that will help me understand your motivation and scenario and see if I can somehow help.

    -Karel

    Tuesday, July 24, 2012 4:47 PM
  • The 1st AD starts the hosting process, initializes a 2nd appdomain with ShadowCopy enabled then loads the 3rd-party libraries dynamically into the 2nd appdomain.

    The reason for shadowcopying is to enable users to upgrade a version of the 3rd-party libraries while they are being used by the process.  

    Tuesday, July 24, 2012 5:38 PM