Upgrading DLLs without any down-time

[Oenone]

My head is starting to hurt this afternoon so I'd love any tips anyone can
offer.

I'm currently going with the concept of putting all my DLLs in the bin/
directory inside my web application's root directory. This is working fine.

However, when I want to upgrade one of the DLLs (all of which are
strong-named and have unique version numbers that change each build), I have
to perform two steps:

1. Copy the new DLL into the bin/ directory, overwriting the existing DLL

2. Update the web.config file to implement the bindingRedirect option for
the new DLL version

Between the first and the second steps taking place, my application fails
(because it can't find the version of the upgraded DLL that it is expecting
things to bind to). This may only take a couple of seconds, but with the
thousands of hits we are getting on our web site this will most likely cause
at least one or two users to receive an error message.

Is there an obvious solution to this that I'm missing?

 

[Mythran]

My head is starting to hurt this afternoon so I'd love any tips anyone can
offer.

I'm currently going with the concept of putting all my DLLs in the bin/
directory inside my web application's root directory. This is working
fine.

However, when I want to upgrade one of the DLLs (all of which are
strong-named and have unique version numbers that change each build), I
have to perform two steps:

1. Copy the new DLL into the bin/ directory, overwriting the existing DLL

2. Update the web.config file to implement the bindingRedirect option for
the new DLL version

Between the first and the second steps taking place, my application fails
(because it can't find the version of the upgraded DLL that it is
expecting things to bind to). This may only take a couple of seconds, but
with the thousands of hits we are getting on our web site this will most
likely cause at least one or two users to receive an error message.

Is there an obvious solution to this that I'm missing?

What we do to prevent downtime is to have two different Virtual Directories
pointing to two separate folders. One is a "test" directory, the other is
the "live" directory. When it is time to deploy, deploy into the test
directory, then test it. If all is well, modify the Virtual Directory's
location (in IIS) of the live directory and point it to the test directory,
then point the test Virtual Directory to the old live directory.

No down time (not even for a first-time run-time compilation).

HTH,
Mythran

 

[John.Net]

One, simple solution, is to copy the project to a local directory, then
modify the web.config, then copy all to the target server using file
explorer. It will 'bounce' any users on the application and send them
back to the default page because the dotnet framework detects the new
dlls and restarts the application. No real 'downtime' but users could
lose session information when it restarts.

HTH

 

[John.Net]

One, simple solution, is to copy the project to a local directory, then
modify the web.config, then copy all to the target server using file
explorer. It will 'bounce' any users on the application and send them
back to the default page because the dotnet framework detects the new
dlls and restarts the application. No real 'downtime' but users could
lose session information when it restarts.

HTH

 

[Bruce Barker]

you have two options.

1) rename all the dll's in the next release, but can still run into timing
troubles with the pages.
2) upload all the pages to a new dir (say with the build number in the
name), after all pages/dll are copied, change the vdir to point to the new
dir.


-- bruce (sqlwork.com)