ASP.Net 1.1 shadow copy + reflection problem

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I use this function to load some assemblies from a directory into ASP.Net
application:

Private Function CaricaLibShadow(ByVal Libreria As String) As [Assembly]

Dim Backup As String

Dim Assbly As [Assembly]

Backup = AppDomain.CurrentDomain.SetupInformation.ShadowCopyDirectories

AppDomain.CurrentDomain.SetShadowCopyPath(System.IO.Path.GetDirectoryName(Libreria))

If Not AppDomain.CurrentDomain.ShadowCopyFiles Then
AppDomain.CurrentDomain.SetShadowCopyFiles()

'Carico libreria

Assbly = [Assembly].LoadFrom(Libreria)

'Ripristino dirs shadowcopy originali

AppDomain.CurrentDomain.ClearShadowCopyPath()

AppDomain.CurrentDomain.SetShadowCopyPath(Backup)

Return Assbly

End Function

This work fine letting me load any assembly in shadow copy so that I can
copy a new version of it over the old one even when the application is
running. The problem is that after I do the copy any application
using that assembly see the old version (even if I close the browser and
reopen it or use another computer to connect) until I restart IIS or cause
the aspnet_wp.exe process to be recycled.
What I would like to obtain is that the system would load the new version
immediately without having to disrupt the session state by
restarting/recycling aspnet_wp.exe thus not letting users connected realize
of the changments but for the fact that bugs disappears.
Am I doing something wrong? Is that possible?

Thanks in advance.

ACL
 
The way I see it you need to recycle the web application each time a file
changes. This is so by default. But since you messed with the shadow copy
(SC) it probably monitores those files (in SC) and doesn't react to the
change in the original folder. I'm not an expert but I suppose you can't do
anything much.

What I would like to know is why do you use SC? .NET by itself does not lock
dll's so you should be free to change/delete/add them even when the
application is running. If you are getting locked files then it is most
likely the Visual Studio that does it and this issue has been addressed in
other forums.

Joco
 
What I would like to know is why do you use SC? .NET by itself does not lock
dll's so you should be free to change/delete/add them even when the
application is running.
Click to expand...

First of all thanks a lot for the hint.
To answer your question, I use SC explicitly since I need to load libraries
(assemblies) from other directories that are not the bin. If I was using just
the bin then SC would be on by default and the binaries would not be locked.
In my case, instead, through reflection I can load the assembly but it's
locked. I needed to be able to update the binaries and so I activated the SC
on the directories I need to load from.

Now I am experimenting strong naming the assemblies since I read that if you
do so the LoadFrom should be able to differenciate between two different
versions of the assembly loaded from the same dir. So far I'm not getting any
good response.

Anyone has some other hint?

Thanks in advance for any help.

ACL
 
ic.

Well if you use strong naming (SN) the problem will not dissapear but rather
escalate. The thing is (IMHO) that then some portions of your application
would use the old code and others the new one. If that is OK with, great.

If not: I would suggest placing file watchers on the dll's and reloading
them or even restarting whole application when one of them changes.

If you load all your dll's from the same folder you can simplify this by
adding a watcher to the folder and restart/reload each time contents of the
folder change. Hope this helps somewhat.

Joco
 
Back
Top