Extending your IIS 7 server with .NET

I feel like I got off on the wrong foot in my blog coverage of IIS extensibility … I started spending a lot of time talking about building IIS7 server modules with the native API, but did not mention anything about the new .NET extensibility. This is strange for two reasons:

1. I spent the majority of my time over the past year, including many late nights and weekends, working on .NET extensibility and the .NET runtime engine for IIS7.
2. Most of the IIS developers I’ve talked to were a whole lot more excited about writing server components with .NET then with the native C++ APIs.

So, before I do any more posts about IIS7’s native C++ extensibility, let me do a little bit of justice to the .NET side of things.

IIS7 .NET

First things first – IIS7, for the first time in the history of the server, provides first class support for extending the server with .NET.

But wait, you say, couldn’t you develop .NET components using ASP.NET as early as IIS 5.0 on Windows 2000?

That’s absolutely true, and thousands of developers have taken advantage of that to build powerful ASP.NET applications.

However, ASP.NET is an application framework running on top of the IIS web server and therefore has had certain key limitations when it comes to using it for server-level development:

• ASP.NET components only execute for ASP.NET requests. So, that fancy authentication module you wrote in ASP.NET would not work for PHP content or static image requests, only for ASPX pages.
• ASP.NET components cannot replace/customize much of server functionality, due to runtime limitations of ASP.NET. In many cases, writing a native C ISAPI filter/extension was required to tackle those low level tasks.

IIS7 provides a brand new integration mode for ASP.NET, dubbed "Integrated" mode, which allows components written using the existing ASP.NET extensibility model and APIs to execute with the same runtime capabilities as server components written using the native C++ extensibility APIs. This model enables the existing ASP.NET APIs to serve as a primary extensibility layer for the IIS7 server, removing the aforementioned limitations of the ASP.NET application framework runtime.

In Integrated mode, ASP.NET modules can execute for all requests to the server (regardless of what application framework produces the actual response), and have the full runtime fidelity to replace/add to any of the IIS7 server features. This is also commonly referred to as the "Integrated pipeline".

The ASP.NET Integrated pipeline enables a couple key things:

1. You can extend IIS with .NET components without having to write native components almost all of the time. Your .NET components have full access to the server’s new powerful extensibility model, and you develop using the familiar ASP.NET APIs.
2. Your existing ASP.NET components continue to work on the server, and with a few configuration options can become more powerful without a single code change.

If you haven’t read about this before, go check out:

• Taking advantage of the IIS7 Integrated Pipeline – a walkthough on how you can take existing ASP.NET components and leverage the ASP.NET Integration in IIS7 to benefit your app without writing a single line of code.
• ASP.NET Integration in IIS7 – a whitepaper on ASP.NET integration in IIS7 that explains some of the architecture / specifics behind it.
• Writing an IIS7 managed module using IIS7’s .NET extensibility via ASP.NET integration. In future posts, I’ll be diving into the nitty-gritty of IIS7’s .NET extensibility, and hopefully get to share some of the modules I’ve written over the past year as we were designing and implementing the .NET runtime for IIS7. Stay tuned …

In future posts, I’ll be diving into the nitty-gritty of IIS7’s .NET extensibility, and hopefully get to share some of the modules I’ve written over the past year as we were designing and implementing the .NET runtime for IIS7.

Stay tuned …