IIS6 | Application Pools | ASP.NET Framework

Question

In IIS6 it's possible to have more than one ASP.NET application running in the same application pool. This is fine, except that there is nothing in IIS6 that prevents you from running multiple .NET versions in the same pool.

When you create application pools in IIS7 you must explicitly state was .NET version will be running in that pool. Running multiple .NET versions in IIS7, in the same application, is impossible.

How can I enforce such rules on my IIS6 server in order to prevent my deployment team from creating such problems?

Answer 1

If I remember correctly, you can also setup application pools in IIS6 (Windows 2003). Create one application pool per framework version in use.

I am not aware of any possibility to enforce the version of the .NET framework being used by an application. If you have setup an application pool to use .NET 1.1 and you have a .NET 2.0 application running in that application pool, you will get an exception in the application (yellow screen of death), since it will not find some referenced assemblies and classes.

Answer 2

I don't think you can. What I do is name my app pools in IIS 6 so that they show what .Net version they host. That way it's easy to pick the correct app pool when creating a new application.

Answer 3

What I do:

Step 1. Create the following application pools:

.NET 1.1 Apps
.NET 2.0 Apps

Step 2. Disable the "Default App Pool"

Now, any time a new application is configured in IIS, it will not work right away because the default app pool is disabled. This forces the person configuring the application to select an app pool that is appropriate for the .NET framework version of the app.

Answer 4

We tend to use one application pool per site, so that each application is isolated in its own process space. Application pool recycles will only affect a single application, and each worker process ends up with its own 4gb memory space. Badly programmed applications have no chance of affecting other applications, resulting in a highly isolated deployment model.

We've also standardized on x64 OS builds running 32bit application pools. While there is overhead using this technique since each application ppol contains a separate copy of the .Net framework, we feel that the added granularity of the application space adds stability to our deployments. You also get the ability to run each application as it's own domain identity, allowing for further memory space isolation and eliminating any need for identity impersonate in web configs.

With IIS 7, you have the ability to run each application pool as either 32 bit or 64 bit, so you can run large memory applications in 64 bit application pools. IIS 7 application pool security is also much more simplified.