ASP.NET tab in IIS, more dangerous than it first appears!

This blog post was a long time coming and fortunately doesn't apply to IIS7, but I thought I would finally take a few minutes and cover this shortcoming with the ASPNET tab that ASP.NET 2.0 introduced into IIS 6 and IIS 5.

As I've covered in a previous post, only 1 version of ASP.NET can run at a time in each IIS Application Pool.  When you want to target a newer or older version of the ASP.NET framework for a particular site or application, you must update that website or application.

When ASP.NET 1.1 was released

When ASP.NET 1.1 was released, the common way to do this was to use aspnet_regiis.exe from the command line.  There was a serious shortcoming with that method though, as I detailed back in December of '03.  (That article and attached script is long overdue for a revision which I'll cover later in this blog post.)  The essence of what I said, and gave a sample script for, is that if you use aspnet_regiis.exe, it will cause an AppDomain recycle on ALL AppDomains on the server, even if you target a single site.  This means that on a production server, it is not safe to use aspnet_regiis outside of a scheduled maintenance window unless you don't mind the impact of an AppDomain recycle.  (for more information on what an AppDomain recycle is and what the impact is, check out this blog post)  The alternate is to change all of the script mappings manually, which properly changes the framework version but has zero impact on other sites on the same server.

When ASP.NET 2.0 was released

When ASP.NET 2.0 was released, Microsoft provided a new tab in IIS called "ASP.NET" as seen in the following screenshot:

aspnetTab

At first this appears to be a welcome addition, and for development computers, it really is.  The issue is this:

The ASP.NET tab in IIS 5 and IIS 6 uses the aspnet_regiis.exe command in the background and, if used, will cause a full AppDomain recycle on the *entire server*.

It's not what most people would expect, and there is no warning provided, so be very careful about this.  In fact, you may survive an AppDomain recycle without having anyone complain.  Therefore, I'm sure oodles of people use this tab on production servers without realizing that they are blowing away InProc session state, causing slow first loads on the pages, and, for sites that take a long time to start up after an AppDomain recycle, possibly causing downtime.

At ORCS Web, when v2.0 came out, I cleaned up the script to handle more than 2 versions of the framework and to I made some other enhancements, but I never got around to blogging about it because there were some features that I wanted to add.  The two features that it's lacking the most are 1) you have to manually enter the site ID rather than getting to pick from a list, and 2) it doesn't support changing the framework version for subfolders.  I kept telling myself I would spend 1/2 a day and finish this, but never got around to it.  So, I'll include it here, and if it interests anyone, feel free to use it.  We've been running it in production for years and it works just great, but it could stand for some further improvements.  You can download it here: Change_Framework_version.zip.  (Note: at ORCS Web we use our own control panel to change the framework version now instead of this script, but it was based on this script)

When ASP.NET 3.0 and 3.5 was released

ASP.NET 3.0 and 3.5 followed a new trend.  They aren't full side-by-side versions of the framework like v1.1 and v2.0 were.  Instead they are add-on extensions to ASP.NET 2.0.  So, when you set your site to use v2.0 of the framework but have ASP.NET 3.5 installed on the server, you are actually able to use all of the v2.0 - v3.5 features. 

IIS 7

IIS 7 allows you to set the framework version at the application pool rather than the website.  This change does not cause the server-wide impact and it is safe to do on a production server as long as you realize that the one app pool will have an AppDomain recycle.

In summary, the ASP.NET tab should not be run on a production server except during a maintenance window.  The impact is pretty minor or non-existent for some sites, but it can be pretty bad for other sites.  Just be aware that changing the framework version from the ASP.NET causes an AppDomain recycle on the entire server.  The alternative is to manually change the script mappings which can be done using the script provided above, or manually item by item at the site or application level in IIS.

5 Comments

  • Good to know, I guess I haven't done much with versions prior to 2 lately. Thanks for the info.

  • Whoaa. Did not know this. As an app company, I routinely walk new customers through installing our web apps and tweaking settings (including targeted framework) via the ASP.NET tab. Uh, what do I do now? Would be kind of difficult to have them use your script. Thanks for the info.

  • John, someone would do well to write a clean GUI app that doesn't call aspnet_regiis. It wouldn't take much to complete the .vbs script that I have and wrap it in a WinForms GUI.

    Without that, there aren't any cleaner solutions that I've run across.

    For you, you can consider modifying the script to use the "ServerComment" property, which is the friendly name of the site, and emailing a version to your customers with it already set for their site, so that they can double click and run it. Still not perfectly pretty, but it would be safer for a production server.

    Mind you, that only takes care of the framework version. Other app settings will case appdomain recycles, which can't be avoided, so being aware of it is the most important part.

  • I was hoping to get a shortcut for a similar exercise for an old server but alas... The link to Change_Framework_version.zip is broken.

  • Hi Billyana,

    Thanks for mentioning! It looks like that file was removed after some site changes. I fixed the reference.

    Scott

Comments have been disabled for this content.