When the IIS Service Gets Unavailable(from DDJ)

Elite

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抰 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抯 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抯 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抯 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 揇efaultAppPool,?thus increasing the chances of raising
version conflicts.
The 揝ervice 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.


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/1421/showart_8482.html