Back Draft

The IIS7 Difference

By Jonathan Goodyear

When Microsoft releases Windows Vista in 2007 (with Longhorn Server hopefully following shortly thereafter), a lot of new technologies are going to be brought to the developer table. I m sure that you ve heard all about Windows Presentation Foundation, Windows Communication Foundation, Windows Workflow Foundation, and Windows CardSpace (formerly InfoCard), which are packaged into the .NET Framework 3.0 (formerly WinFX) that will ship with Windows Vista. I m excited about all of these things, but what I m really looking forward to is Internet Information Services 7 (http://www.iis.net).

You may be wondering what s so special about Internet Information Services 7 (IIS7). After all, that stuff is for IT Administrators to worry about, right? It is true that IIS7 offers many new features for IT Administrators, but it offers a ton of features tailored for the ASP.NET developer, as well. In fact, my column is not big enough to cover it all. I m going to do my best, though, to hit the high notes of what I feel you should know about.

At its very core, IIS7 has been divided into more than 40 distinct functional modules. Some examples are authentication, caching, static file handling, and directory browsing. That means your Web server only has to have installed on it the modules you ll be using. That reduces its attack surface, as well as increases server performance, as unneeded modules are no longer loaded into memory, nor do they need to be part of the request pipeline. Need to swap out a module on the fly? There s no need to re-boot IIS7 won t even miss a beat.

Speaking of the request pipeline, ASP.NET will no longer be an ISAPI extension that is merely bolted onto IIS. Rather, ASP.NET will be fully integrated into the IIS7 request pipeline (referred to as Integrated Mode), enabling it to intercept and respond to the complete set of IIS events. This core integration also enables ASP.NET features like caching and authentication to be applied to all file types without sacrificing the performance of mapping non-ASP.NET file types to the ASP.NET ISAPI extension. The obvious use of that added power will be to replace and/or add to the list of modules mentioned above that comprise IIS7. As an example, you could build your own custom authentication store, state management mechanism, or native image handler, among other things.

Another programmatic enhancement that will come with IIS7 is the ability to modify Request headers as they are received. You can also modify the Response stream, as well as the cookies collection (even after the request has been processed by another application). This will enable you to easily integrate your Web application with third-party Web applications and ISAPI extensions that may require low-level editing of data as it is received and transmitted. It will also enable you to do things like modify static images as they are being streamed out from the Web server. Very cool.

In case you re trying to do a sanity check, there is a Classic Mode that will enable your ASP.NET application to function exactly like it does in IIS6. In IIS7, the version of ASP.NET that your Web application uses is specified in the application pool to which it is mapped. This change in philosophy prevents the problems that occur today when multiple Web sites running on different versions of the .NET Framework are mapped to the same application pool (crashing whichever one attempts to load second). There are only a few situations where you d want to revert to Classic Mode, though. The way that impersonation is handled in Integrated Mode is slightly different, so that might be a reason you d want to stick with the old model.

I m really pumped up about the configuration story in IIS7. Everything is stored in simple to read XML files. There are no more confusing bitmasks or integer values. In fact, there s no more Metabase, although scripts that you ve created to modify it will continue to run without modification, as IIS7 will map settings to their proper place in the new configuration system. The main IIS configuration file is called applicationHost.config and is located in the [systemroot]\system32\inetsrv\ directory. It inherits settings from the machine.config file that we all know and love. There also is a root-level web.config file containing global ASP.NET application settings that inherits from machine.config and applicationHost.config. Located in the [systemroot]\Microsoft.NET\Framework\versionNumber\CONFIG\ directory, this setup makes deployment from development to server, and from server to server, a snap. In addition, web.config files can be stored on a separate file server and referenced by multiple Web servers. Not only that, IT Administrators can now delegate some Web server settings, down to the individual Web application level, which would then be stored in its web.config file. As an example, wouldn t it be great if you could specify a default document in web.config, instead of having to dig through IIS Manager (if you even have access to it)? Web hosting providers are going to love that kind of flexibility, as it will push application-level responsibilities down to the developer level where they should be.

As if storing all the IIS configuration settings in XML files wasn t enough, there is now a completely new API for managing them, which is fantastically easy to use. It s all contained in the Microsoft.Web.Administration namespace. For instance, here s a little snippet of C# code to add a new Web site:

ServerManager iisManager = new ServerManager();

iisManager.Sites.Add("NewSite", "http", ":80:", _

    "d:\\domains\\NewSite");

iisManager.Update();

I think we can all agree that the user interface for the IIS Manager tool is a bit out-dated. The mantra of IIS7 is to keep everything modular, and the new IIS Administration tool is no exception. IIS7 introduces a completely new interface with a very browser-like feel. The layout of the interface is very intuitive, and is also extensible, enabling you to build and plug in your own screens to administer existing Web server functionality or new functionality that you build yourself.

There are a couple of additional IIS7 features that I feel warrant mentioning. First, the ASP.NET Tracing features can now be integrated with the IIS logging features to provide a single, consolidated place to go for diagnostic information, reducing the time it takes to troubleshoot server issues. Second, the version of IIS7 that comes with Windows Vista will now allow multiple Web sites to be configured at the same time. This is a big improvement over the single Web site limitation of IIS 5.1 that sits on Windows XP Professional. Not only that, but while there is still a limit of 10 concurrent connections on the version of IIS7 that comes with Windows Vista, the overage will not be denied. Rather, they will be placed on the request queue and processed in order.

There is no way I could adequately cover in one column all the new and exciting features and functionality that IIS7 will bring to the table when Windows Vista and Longhorn ship. However, I touched on the things that matter most to ASP.NET developers like you and me. As an entrepreneur, I m also always looking for ways that upcoming Microsoft technologies will spawn new product markets. Two years ago, I felt not enough people were building custom ASP.NET modules (see http://www.aspnetpro.com/opinion/2004/04/asp200404jg_o/asp200404jg_o.asp). A big reason for that was because we didn t have access to the entire IIS request pipeline. I believe that the modular architecture of IIS7, and the way in which its core is tightly coupled with ASP.NET, will create a great opportunity for the third-party custom IIS and ASP.NET module market to come to fruition. I am also quite confident that IIS7 s module architecture will enable Microsoft to release enhancements and patches more quickly and easily than with previous versions of IIS. It may seem far off now, but IIS7 will be here before you know it, so get coding!

Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, FL. Jonathan is Microsoft Regional Director for Florida, a Microsoft Certified Solution Developer (MCSD), and co-author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:jon@aspsoft.com or through his angryCoder eZine at http://www.angryCoder.com.