When uploading a new DLL for a large web application (dll is around 1mb) IIS throws an error because the DLL is 'in-use', meaning the website is down while the DLL is being uploaded. Is there a way to stop this behaviour?
Also, although I am using Web Applications, not Web Sites, whenever I upload a new DLL it still takes a while for IIS to restart after a fresh upload. I thought this wait was generally only for websites as they need to be compiled by IIS, not Web Applications?
You can use AAR together with some Powershell scripting to deploy with zero downtime in the same machine.
Basically you set 3 sites up . One listening to the requests, passing them to ARR, which redirects them to one of the other 2 sites. Only one of these 2 sites is active at a time.
When deploying, you copy the new files to the stopped site, warm it up, and then tell ARR to start forwarding the requests to this node, at which point you can take the site with the old code offline.
This script pretty much automates this process. It assumes the following file / site / webfarm structure:
As soon as you make a change such as this you've effectively changed a dependency. The site will need to be recompiled in ASP.NET's shadow copy folders.
Update:
Based on your comment: What if someone was buying and item in an e-commerce site at the same time new updates were pushed out? Its one of my bug bears of .NET (one thing I miss about php was easily uploading PHP files without the hassle)
If you've only got a single server then you need to plan your updates and give some advance warning that the site will be unavailable due to an upgrade. There's a feature in ASP.NET called App_Offline.htm. It's a special page which when present in your application will cause ASP.NET to render its contents no matter which page is requested. You can use this to display a message explaining to users that the site is offline for maintenance. You can read more about it here on Scott Guthrie's blog.
It's not unreasonable to approach site upgrades this way because it's a mechanism to perform a site update in a single atomic step and provided you give users plenty of advance warning they won't mind (and perhaps do this at a time when your traffic is at a typical low point) .
You mention that in PHP you wouldn't have this problem. Actually, if you're updating anything more that a couple of non-related pages then you should be preventing users from accessing the site during upgrades as a matter course.
Say you're updating five or six pages all loosely related - perhaps as part of an e-commerce application. During the upload process you deploy the first page and it gets served to a user. One of the changes you made to this page was to add a a new field to a form. The page posts back to a another PHP script that uses this field. Two scenarios exist:
The postback page is new and is still in your upload queue. This breaks the newly uploaded script because when a user clicks submit there is nothing to submit to.
The postback page already exists but hasn't been updated. This page writes the form post fields to a database. You've added this new field to the database but it's a mandatory field and can't be null. Your no-yet-updated postback script tries to update the DB but an error is raised because the new field isn't in the postback form's INSERT statement and thus is null causing a NOT NULL constraint violation.
I could go on. If your site provides more than just a trivial amount of functionality then you should go offline for ALL updates to ensure that ALL you're updated code is deployed in a single atomic update.
