views:

29

answers:

1

Hi,

i was only able to read up that ASP.NET detects changes to specific files like aspx files, DLLs and others. It will restart itself, finish current running requests and new requests with the new deployed files.

But what is happening in the time from the first file beeing copied till the last one has been exchanged? If i exchange the first DLL file, then a request comes in but the other DLL files are in an older version - will it just crash? Will asp.net wait for some seconds and only starts itself new after X seconds of no (relevant) file changes?

Thx!

+1  A: 

You have 4 questions here: What is happening in the time from the first file beeing copied till the last one has been exchanged? - There is a set time while .net waits to see if any other files have been modified before it starts up the new app domain with the new dll's loaded.

If i exchange the first DLL file, then a request comes in but the other DLL files are in an older version - will it just crash? - It depends on what code changes are in the dll's. If the new dll can run fine with old code then it will be fine. But if the app domain spins up the new DLL and that new dll is dependent on something that isn't there yet... then yes it will throw an exception.

Will asp.net wait for some seconds and only starts itself new after X seconds of no (relevant) file changes? - Yes. I haven't been able to find how long that time is. But in my personal experience it's somewhere in the 1-2 second range.

I also found a good explanation here on app domain and re-loading of DLL's: http://odetocode.com/Articles/305.aspx

If you copy an updated dll into an application’s bin subdirectory, the ASP.NET runtime recognizes there is new code to execute. Since ASP.NET cannot swap the dll into the existing AppDomain , it starts a new AppDomain. The old application domain is “drain stopped”, that is, existing requests are allowed to finish executing, and once they are all finished the AppDomain can unload. The new AppDomain starts with the new code and begins taking all new requests.

Typically, when a dll loads into a process, the process locks the dll and you cannot overwrite the file on disk. However, AppDomains have a feature known as Shadow Copy that allows assemblies to remain unlocked and replaceable on disk.

The runtime initializes ASP.NET with Shadow Copy enabled for the bin directory. The AppDomain will copy any dll it needs from the bin directory to a temporary location before locking and loading the dll into memory. Shadow Copy allows us to overwrite any dll in the bin directory during an update without taking the web application offline.

Paul Lemke
Great - that exactly answers my questions!Thank you for your detailed answer :)
Eleasar