ASP.NET 1.x and ASP.NET 2.0 apps don’t play nice in the same pool
After installing any build of ASP.NET 2.0, you may have experienced an apparently inexplicable IIS 6.0 runtime error when trying to run or debug an ASP.NET application. The error has nothing to do with any line of code written in your app. For some reason, IIS doesn't even attempt to run the application, and the error message invites you to verify the correct functioning of the web server. What provokes this runtime anomaly? If you take a look at the Application section in the Event Viewer, you find concrete information on how to fix the issue and what caused it. But let's start with some background information about the context.
The erroneous situation can be easily reproduced on Windows 2003 Server machines with the Beta 1 of ASP.NET (same with any pre-Beta 1 builds and reasonably with future builds as well). Once you install ASP.NET 2.0 on a machine where a version of ASP.NET 1.x was previously installed, you get two different versions of the ASP.NET runtime running side by side. There's nothing wrong with this, except that the two runtime engines are made to conflict in the IIS 6.0 memory space. Only this conflict is at the origin of the anomaly and raises the exception.
By default, ASP.NET 2.0 registers its own script maps for all applications, including new applications. From now on, any application runs under ASP.NET 2.0 and any newly created application is registered to use ASP.NET 2.0 binaries. By using offline tools like aspnet_regiis or the ASP.NET 2.0 MMC snap-in, you can modify the binaries required to run a given application. Now suppose you open Visual Studio .NET to create a new ASP.NET application. Visual Studio .NET creates the IIS virtual folder for it, and in doing so, it binds the application to ASP.NET 2.0. What you want instead is just an ASP.NET 1.x application. So when using either the MMC snap-in or aspnet_regiis, you change the set of binaries and ensure that your app uses those of ASP.NET 1.x.
If you run Windows 2000 and IIS 5.x, there are no significant issues; if you use Windows 2003 Server and IIS 6.0, you must guarantee that each IIS 6.0 Application Pool is populated with homogeneous applications. In other words, it is not possible to run two different versions of ASP.NET in the same IIS Application Pool. What's an Application Pool? Basically, it is a pool of IIS applications that share the same copy of the IIS worker process (w3wp.exe). If you happen to have 2.0 and 1.x applications in the same pool, IIS can hardly figure out which binaries to use and blocks the execution making the WWW service unavailable. You use the IIS Administration Tool to reconfigure the application to run in a separate pool. By default, any new application goes into the standard pool named "DefaultAppPool, thus increasing the chances of raising version conflicts.
The "Service Unavailable error may occur when you run different versions of ASP.NET in the same IIS Application Pool. To fix the problem, you just move applications in different pools. A good approach is leaving, at a minimum, DefaultAppPool hosting ASP.NET 2.0 applications, and creating a second pool for all version 1.x applications. You can also resort to a more fine-grained subdivision as long as you keep 2.0 and 1.x applications separate in IIS 6.0.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].
