IIS App Pool/Restart and ASP.NET

Question

We are using IIS7 to host an asp.net web-based application. In this environment administrators and developers can deploy code to the application on a regular basis.

The new code or app goes as a DLL to the ASP.NET bin folder. Upon deployment of the new DLL, IIS restarts the process, impacting (slowing down) all online users.

Is there a way to configure IIS to run the process in the background and once ready make the switch from old state into new without impacting the users?!

Thanks in advance for your feedback!

Answer 1

IIS already does this, that's what recycling is all about. IT's loading the DLL's while the old version of the application is still running. only after this is completed the recycling is complete.

However loading the DLL's is only part of getting web applications ready, there might also be initial loads like loading/caching the user db etc.
These actions are not part of the recycle process, they happen after all DLL's reloaded and the recycling is already completed.

A while back I ran into this issue with an application that had a huge startup time due to heavy db activity/caching during startup. So I was interested if there is some functionality that allows us to execute code before the recycle is marked as completed, so that the application is first considered recycled when everything is ready to run. Basically what I wanted is some kind of staging functionality.
I was in contact with the IIS team regarding this issue, sadly they told me that no such functionality exists, nor is it planned.

To solve this you could try do the following:

• Use alternating deploys:
  You setup 2 Websites with separate application pools. One of them is the LIVE website the other one is the STAGED website. If you want to deploy changed you simply deploy to the STAGED website. After everything is loaded/cached etc. you switch the URL settings of the web applications to reroute incoming requests from the LIVE to the STAGED one. So the LIVE one becomes the new STAGED and the other way around. The next deploy would then go to the new STAGED again and so on.

UPDATE
Apparently they have created a IIS Module that provides this functionality by now:

IIS Application Warm-Up Module for IIS 7.5

The IIS team has released the first beta test version of the Application Warm-Up Module for IIS 7.5. This makes warming up your applications even easier than previously described. Instead of writing custom code, you specify the URLs of resources to execute before the Web application accepts requests from the network. This warm-up occurs during startup of the IIS service (if you configured the IIS application pool as AlwaysRunning) and when an IIS worker process recycles. During recycle, the old IIS worker process continues to execute requests until the newly spawned worker process is fully warmed up, so that applications experience no interruptions or other issues due to unprimed caches. Note that this module works with any version of ASP.NET, starting with version 2.0.

For more information, see Application Warm-Up on the IIS.net Web site. For a walkthrough that illustrates how to use the warm-up feature, see Getting Started with the IIS 7.5 Application Warm-Up Module on the IIS.net Web site.

See:

http://www.asp.net/whitepapers/aspnet4

If you use ASP.NET 4 Auto Start feature:

You can still choose to auto-recycle the worker processes from time to time. When you do that, though, the app will immediately restart and your warm up code will execute (unlike today - where you have to wait for the next request to-do that).

The main difference between Warm Up and Auto Start feature is that the Warm Up Module is part of the recycling process. Rather than blocking the application for requests, while running the init code.
Only thing you get by using the Auto Start feature is that you don't have to wait for a user to hit the page, which does not help your case.

See the Gu's blog post:

http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx

UPDATE 2:

Sadly the Warmup Module has been discontinued for IIS 7/7.5:

http://forums.iis.net/t/1176740.aspx

It will be part of IIS8 though (It's now called Application Initialization Module):

http://weblogs.asp.net/owscott/archive/2012/03/01/what-s-new-in-iis-8.aspx

UPDATE 3:

As pointed out in the comments the Warmup Module resurfaced for IIS 7.5 as Application Initialization Module for IIS 7.5 after IIS 8 was released:

http://www.iis.net/downloads/microsoft/application-initialization

Answer 2

The first part of ntziolis answer is a wee bit inaccurate. The worker process isn't being recycled or restarted, it just keeps running. If this were the case, then in shared pool environments you would have sites knocked out every time a new one was deployed.

When you deploy a new ASP.NET application it's the site's "Application Domain" within the worker process is torn down, not the pool process.

In addition pool recycling is a completely separate concept to deployment

At this point in time in the commercial life of ASP.NET, during a deployment, a site will be in an inconsistent state until all of the site is deployed. There is still no good story about this from Microsoft at this time for single site on a single server deployments.

This is why ASP.NET has the special App_Offline.htm page. It's there so you can enable that page, deploy and then turn it off.

The second part of ntziolis answer is nearly correct but you don't need two sites or two application pools. You just need two file system folders that switch between being the physical folders for the site...if you're on a single server and not behind a load balancer or ARR.

If your sites were on a web server behind a load-balancer or ARR then having two different sites would make sense, you could route requests from one site to the other and round-robin on each deploy.

Obviously if there is a large amount of user generated content (uploaded files and the like) then you'd map a virtual directory in your site to a common location for this data.

In larger scale deployments where your app is running across (for example) a load-balanced environment you can do more sophisticated deployments.

For related questions please see:

How Do I deploy an application to IIS while that web application is running

Publishing/uploading new DLL to IIS: website goes down whilst uploading

Is smooth deployment possible with componentized ASP.NET MVC apps?