Force ASP.NET shadow directory to update?

[Oenone]

I have an application which loads plugin DLLs from various directories on
the local disk. To avoid problems with the DLLs being locked by IIS, I have
modified my code so that it copies the DLLs to the /bin/ directory if it
determines that they are newer than the version already there, and loads the
copy. This then takes advantage of Shadow Copying, so the DLLs never get
locked.

This is all fine, but the very first time I put a new DLL into one of the
source directories, that page execution still runs the old code, despite it
having copied the new version to the /bin/ directory before loading the
assembly. I am guessing that this is because when I tell Assembly.LoadFrom
to load the assembly, it actually loads it from the Shadow directory, not
directly from the /bin/ directory. I guess further that the Shadow directory
is not updated with the new /bin/ DLLs until the current page request has
completed.

Is there any way I can get the first page request to load the updated
assembly rather than the old shadowed version? Perhaps some way to force (in
code) the shadow directory to refresh itself so that the updated DLL is
immediately available to be loaded?

TIA,

 

[Bruce Barker]

actually when you drop the dll in the bin, a recycle starts. this creates
new shadow directories for the new appdomain to use, so that newer dll can
be used (the old dll files will be locked until the old appdomain exits).
if you want the old appdomain to use the new dll when it appears will
require you to implement your own shadow copy scheme rather than using the
default asp.net one.

your other option is to detect the file change (say with a filewatcher) and
do a redirect to start the processing over with the new appdomain. another
alternative is to change the plugin calls to webservice calls which would
also let you use the default shadowing.

-- bruce (sqlwork.com)

 

[Oenone]

actually when you drop the dll in the bin, a recycle starts. this
creates new shadow directories for the new appdomain to use, so that
newer dll can be used (the old dll files will be locked until the old
appdomain exits). if you want the old appdomain to use the new dll
when it appears will require you to implement your own shadow copy
scheme rather than using the default asp.net one.

your other option is to detect the file change (say with a
filewatcher) and do a redirect to start the processing over with the
new appdomain. another alternative is to change the plugin calls to
webservice calls which would also let you use the default shadowing.

Hi Bruce,

Those are all very interesting workaround, I shall definitely consider some
of those. I suspect that implementing my own shadow copy system may be the
easiest way, all I need to do presumably is add an incremental number to the
DLL filename as I copy it, that'll ensure it's always the new version that
is picked up.

Many thanks for the suggestions,