Redeploying an ASP.NET site in IIS7 without files in use interfering

Question

Hey,

We've got a process currently which causes ASP.NET websites to be redeployed. The code is itself an ASP.NET application. The current method, which has worked for quite a while, is simply to loop over all the files in one folder and copy them over the top of the files in the webroot.

The problem that's arisen is that occasionally files end up being in use and hence can't be copied over. This has in the past been intermittent to the point it didn't matter but on some of our higher traffic sites it happens the majority of the time now.

I'm wondering if anyone has a workaround or alternative approach to this that I haven't thought of. Currently my ideas are:

1. Simply retry each file until it works. That's going to cause errors for a short time though which isn't really that good.
2. Deploy to a new folder and update IIS's webroot to the new folder. I'm not sure how to do this short of running the application as an administrator and running batch files, which is very untidy.

Does anyone know what the best way to do this is, or if it's possible to do #2 without running the publishing application as a user who has admin access (Willing to grant it special privileges, but I'd prefer to stop short of administrator)?

Edit
Clarification of infrastructure... We have 2 IIS 7 webservers in an NLB running their webroots off a shared NAS (To be more clear, they're using the exact same webroot on the NAS). We do a lot of deploys, to the point where any approach we can't automate really won't be viable.

Answer 1

You could also try to modify the timestamp of web.config in the root folder before attempting to copy the files. This will unload the application and free used files.

Answer 2

What you need to do is temporary stop IIS from processing any incoming requests for that app, so you can copy the new files and then start it again. This will lead to a small downtime for your clients, but unless your website is mission critical, that shouldn't be that big of a problem.

ASP.NET has a feature that targets exactly this scenario. Basically, it boils down to temporarily creating a file named App_Offline.htm in the root of your webapp. Once the file is there, IIS will takedown the worker process for you app and unload any files in use. Once you copy over your files, you can delete the App_Offline.htm file and IIS will happily start churning again.

Note that while that file is there, IIS will serve its content as a response to any requests to your webapp. So be careful what you put in the file. :-)

Answer 3

Unless you're manually opening a handle to a file on your web server, IIS won't keep locks on your files.

Try shutting down other services that might be locking your files. Some examples of common services that do just that:

• Windows Search
• Google Desktop Search
• Windows Backup
• any other anti-virus or indexing software

Answer 4

Another solution is IIS Programmatic Administration.

Then you can copy your new/updated web to an alternative directory then switch the IIS root of your webapp to this alternative directory. Then you don't matter if files are locked in the original root. This a good solution for website availability.

However it requires some permission tuning...

You can do it via ADSI or WMI for IIS 6 or Microsoft.Web.Administration for IIS 7.

About your 2., note that WMI don't require administrator privileges as ADSI do. You can configure rights by objects. Check your WMI console (mmc).

Answer 5

Since you're already load balancing between 2 web servers, you can:

1. In the load balancer, take web server A offline, so only web server B is in use.
2. Deploy the updated site to web server A.
3. (As a bonus, you can do an extra test pass on web server A before it goes into production.)
4. In the load balancer, take B offline and put A online, so only web server A is in use.
5. Deploy the updated site to web server B.
6. (As a bonus, you can do an extra test pass on web server B before it goes into production.)
7. In the load balancer, put B back online. Now both web servers are upgraded and back in use in production.
8. List item