Releasing a loaded assembly in ASP.NET 2.0

[Oenone]

I've an ASP.NET 2.0 project into which various Plug-In DLLs can be
installed. I'm running it in the ASP.NET Development Server. In order to
load one of the PlugIn DLLs I'm using
System.Reflection.Assembly.LoadFrom(filename) to load the DLL and then
calling CreateInstance on the assembly that is returned.

This is all fine, but when I stop the project from running, change the code
and then re-compile it, I'm frequently getting a message from the compiler
as follows:

\\\
Unable to copy file "obj\Debug\Plugin.dll" to "bin\Plugin.dll". The process
cannot access the file "bin\Plugin.dll" because it is being used by another
process.
///

The only way I've found to get past this is to right-click the ASP.NET
Development Server icon in the system tray and tell it to Stop. This gets
extremely tedious after a while.

Is there any way to programmatically release the loaded plugin assemblies
once I've finished using them? I can't find any method on the Assembly
object that looks like it may facilitate this.

Failing that, can anyone suggest any other method of stopping the
development server from locking the DLL, so that subsequent builds can be
copied over the top of it?

Many thanks,

 

[Oenone]

Hi Cesar,

This happens because the IIS locks any referenced dll when utilized
for first time.

Thanks for the reply, but I'm not actually using IIS, but the ASP.NET
Development Server instead. I was expecting that the DevServer would close
itself down each time I stopped debugging my project, but that doesn't seem
to be happening...

 

[Cesar Ronchese]

This happens because the IIS locks any referenced dll when utilized for
first time. What you can do is build a .bat that have the following
commands:

net stop w3svc
net stop msftpsvc
net stop smtpsvc
net stop iisadmin

net start iisadmin
net start smtpsvc
net start msftpsvc
net start w3svc

pause


You can double-clicks it everytime you need recompile your dll or execute it
via macro inside Visual Studio.

There is another way, configuring the IIS to don't lock the dlls, but you
need search for it in Google. This other way sometimes still locks the dll,
in some circunstancies. I can't remember which, because long ago I used it.


[]s
Cesar