AppDomain Issue...

[Satinderpal Singh]

Hi All,

I have an EXE, I load the DLL from that exe in a seperate AppDomain. (I have
not given reference to that DLL from the EXE).

Now, i call some commands of that dll from the EXE, and in the background i
try to delete the DLL, it does not allows (fair enough).

Now, I unload that AppDomain using AppDomain.Unload method. Now, I try to
delete that DLL from the background it still does not allows, I thought the
reason could be Garbage Collector, but then I used System.GC.Collect
immediately after unloading the AppDomain, and also waited for 10-15 mins
before deleting it again, but it still does not allows, then i closed the
EXE and now it allows immediately.

What could be the reason ???

Does AppDomain works only for EXEs or is that we cannot unload an assembly
through AppDomain ???

I read few articles on net, www.gotdotnet.com says you can achieve the above
thing, but they have not given any example. Some articles says, this is not
possible, some says you use ShadowFolder of AppDomain to make this work,
with ShadowFolder it works fine, but i dont want to use it (i mean i dont
want to create a seperate folder and maintain a copy of my dll there).

Can anyone please help me out with this ?

I want to load and unload a DLL from the EXE and the moment I unload the
AppDomain of the DLL it should allow me to delete the DLL. This
functionality is to be achieved for AutoDeploy feature.

Thanks,
Satinder

 

[Dan Ignatov]

Hi, Satinderpal Singh.
There is an article on microsoft.com: "Let Users Add Functionality to Your
..NET Applications with Macros and Plug-Ins",
http://msdn.microsoft.com/msdnmag/issues/03/10/plug-ins/default.aspx
The article describes some techniques that can help you.
Loading an assembly to reflect on the types in the assembly works fine for
discovering which types you want to plug into your application logic. But
what happens if none of them match your criteria? The short answer is that
there is no way to unload an assembly that's already in your AppDomain. This
is the second reason that a reflection-based discovery method is slightly
more difficult to implement than the XML approach.
For certain client applications it may be acceptable to litter your
process with all of the assemblies that your code reflects over, even the
ones that don't meet your plug-in binding criteria. But for an extensible
server application its insufficient to load anything that can't subsequently
be unloaded. The solution for this comes in two phases. First, you can
unload an assembly so long as you unload the entire AppDomain in which the
assembly was loaded. Second, you can programmatically create a temporary
AppDomain for the sole purpose of loading assemblies to reflect over to find
out whether you want to use the types in the assembly as plug-ins. Once you
are past the discovery stage, the temporary AppDomain along with all of its
assemblies can be unloaded.
<