AppDomain and Shadow Copy

[Andrei Chifu]

I have the following problem when creating an AppDomain and loading an
assembly:
I followed the steps described as anywhere i looked for documentation
regarding this issue and the result is not quite what I expected. I obtain a
shadow copy of my dll, but both files, the original and the shadow copied
dll are locked by the process.
Here is a piece of the code, please tell me what is wrong with it and what
should i do for the original dll not to be locked anymore

System.AppDomainSetup appDomainSetup = new AppDomainSetup();

appDomainSetup.ShadowCopyDirectories = "D:\\pathToMyApp\\bin\\Debug";
appDomainSetup.ShadowCopyFiles = "true";
appDomainSetup.CachePath = "D:\\pathToMyApp\\bin\\Debug";
appDomainSetup.ApplicationName = "appName";

System.AppDomain appDomain = System.AppDomain.CreateDomain("Domain" +
"someName",
new System.Security.Policy.Evidence(AppDomain.CurrentDomain.Evidence),
appDomainSetup);

System.Reflection.AssemblyName assemblyName =
System.Reflection.AssemblyName.GetAssemblyName("pathToTheDll");

System.Reflection.Assembly assembly = appDomain.Load(assemblyName);

I also tried using the Load(byte[] buffer) version of AppDomain.Load, but in
this case, the shadow copy is not created anymore but the original dlls is
used by the application, which, by the way, seems very strange to me.

[Shell D00d]

Hi Andrei,

The problem lies in the way AppDomain.Load() works.

When you make a call to AppDomain.Load, the assembly is loaded in the
target domain (which is appDomain in your case) BUT the call returns a
reference to the same assembly back to your parent domain (the one
where the code is running). When this happens, the dll gets loaded in
the parent domain where there is no setting to shadow copy the files.

So you see, shadow copy is working for the target domain, but it
doesn't happen in the parent domain. Hence, the file gets locked.

If you want to load the assembly in the target domain without getting
a reference back in the parent domain, you will have to write a class
that will load the assembly for you in the target domain. i.e.,
something like a proxy object where you would first create an instance
of the Loader object in the target domain and then call
Loader.LoadMyAssembly(filename) which would load the specified file in
the target domain and NOT return any reference to it. The only caveat
is that you should never get a direct reference to the loaded
assembly, even if it just an interface. The moment you do that, it
will get loaded in your parent domain and you're back at square one.

There is an excellent article on this topic by Eric Gunnerson on MSDN
called 'AppDomains and Dynamic Loading'. You should take a look at
that.

Hope that helps.

[Janine Zhang[MSFT]]

Hi, Andrei,

The previous answer from shel...@yahoo.com got it exactly right:
AppDomain.Load returns an Assembly, and if it is called inside the default
AppDomain, then the default AppDomain would have this assembly loaded, and
thus caused the assembly to be locked.

as for the last question that Load(byte[] buffer) version of
AppDomain.Load, ShadowCopy would not have affect as you're loading from a
byte[], not an assembly. The reason for the file lock is probably because
you have not yet closed the file yet.

thanks,
Janine

--------------------
>From: "Andrei Chifu" <a...@a.com>
>Subject: AppDomain and Shadow Copy
>Date: Fri, 2 Jul 2004 16:20:45 +0300
>Lines: 31
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
>Message-ID: <uoP4ldDY...@tk2msftngp13.phx.gbl>
>Newsgroups: microsoft.public.dotnet.framework.clr
>NNTP-Posting-Host: andrei.ro.umt.com 81.196.104.178
>Path:
cpmsftngxa06.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13
.phx.gbl
>Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework.clr:11045
>X-Tomcat-NG: microsoft.public.dotnet.framework.clr

--

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Note: For the benefit of the community-at-large, all responses to this
message are best directed to the newsgroup/thread from which they
originated.