ASP.NET Application Domains

Are ASP.NET Application Domains such a good idea after all? Well, yes, they are. In fact we welcomed the ability to separate ASP.NET applications into distinct domains, allowing exclusivity in the components and other resources they contain, with open arms at first. However, I've already had four occasions to curse them - and we've only had v1.0 of ASP.NET for a couple of months so far!

Firstly, they prevent true XCOPY deployment - a feature much touted during the development of ASP.NET. I can FTP all my files, assemblies and other resources to a remote server, but I still have to connect from a domain machine or use the clunky HTTP-based IIS Manager tool to create the vroots required.

Secondly, if I want to use ASP.NET authentication methods such as Forms or Passport, I have another vroot to create. Third, they prevent me from setting up ASP.NET error logging in the way I need - I can't directly pass values between separate application domains.

Finally, and this is an extremely annoying limitation when using the Microsoft Mobile Internet Toolkit (MIT), I have to have a separate application domain for my MIT-based pages as well. Even if they are part of the same Web application as other pages. Why? Well the current release of the MIT stores the ViewState in the user's ASP.NET Session. It does this because many mobile devices (particularly cellphones) can't accept large volumes of content in a WML "deck", so the use of "hidden" elements to store the ViewState is not a good idea. The problem is that if the device (and/or the wireless gateway) doesn't support cookies, and many don't, ASP.NET sessions cannot be maintained in the traditional way.

The answer is to use the cookie-less (URL munging) feature of ASP.NET, by specifying this in the web.config file. But this demands that the pages be in a separate application domain defined by another vroot. You can't use both cookie-based and cookie-less sessions in the same application domain. However, putting the MIT pages into a separate app domain means that they cannot use the same assemblies and other resources as other variations of the application.

So the data access, business logic and other tiers, plus any user controls, custom server controls etc. have to be duplicated. The only other alternative is to store them in the Global Assembly Cache (GAC). Do this, and you lose the ability to run and maintain side-by-side versions of the application during development.

OK, don't get me wrong. I think the fundamental idea of separate application domains is great. But let's have some ways handling the problems in a more intelligent manner in the next release please Microsoft? Maybe IIS6 will make life easier - and who knows what will be in ASP.NET v2.0?

You can also learn more about IIS from the Microsoft site, and don't forget to keep in touch with the official ASP.NET site as well.

Email:         Privacy and Acceptable Use Policy