Force ASP.NET shadow directory to update?

27 Jan 2006 11:31 AM

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,

--

(O)enone

27 Jan 2006 6:21 PM

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)

Show quoteHide quote

"Oenone" <oen***@nowhere.com> wrote in message
news:%231exvUzIGHA.2064@TK2MSFTNGP09.phx.gbl...
>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,
>
> --
>
> (O)enone
>

27 Jan 2006 8:12 PM

Oenone

Bruce Barker wrote:

> 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,

--

(O)enone