Visual Studio Service 2005 Pack 1 provides the ability to hook up to IIS 7 and use the debugger properly in Integrated Pipeline mode, which previously caused errors. Or so they say <s>... Integrated pipeline in IIS 7 runs the IIS and ASP.NET event pipeline through a single model rather than the previous ISAPI mode which essentially used two completely separate engines interacting with each other. With the Integrated Pipeline request processing for IIS and ASP.NET is consolidated into a single mechanism that is extensible using familar ASP.NET Modules and Handlers – with the big advantage that you can now write these modules and handlers to extend the Web Server as a whole. This basically provides functionality that previous required ISAPI Handlers and Filters – something that you simply couldn’t do easily before with .NET code.

IIS 7 ships with Vista and the forth coming LongHorn Server (later next year). If you’re running Vista you can play with the Integrated Pipeline today. Note the Integrated Pipeline is the default, but you can still run IIS in the familiar ISAPI mode that works exactly the same as it did on IIS. Most ASP.NET applications can run in either mode without any changes.

If you want to use Integrated mode and debug, prior to VS 2005 SP1 you had to manually attach a debugger to debug your applications. You had start the Web application by hitting your site and then finding the appropriate W3WP.EXE instance to attach to. If you had more than one instance of  worker processes running this was a bit tedious and the whole manual attachment issue was tediuous enough to avoid using integrated mode for anything but code that actually took advantage of Integrated pipeline functionality (which at this point is probably not much).

With Visual Studio 2005 SP1 this issue is addressed and you can directly start an IIS 7 Integrated Pipeline project from within the IDE, which is great.

Problems, problems... and some solutions

Great if it works – not so great if it doesn’t and it’s VERY EASY for something to go wrong here as you’ll see in a minute. Before you start debugging make sure you can just get the site to run in Integrated mode. There are a few changes that need to be made in web.config in order for an Integrated Site to run. They are minor – the main thing is that any handlers and modules need to be moved to the new <system.webserver> section of the web.config file:

<configuration>

  <system.web>

    <!--<httpHandlers>

      <add path="ChatHandler.ashx" type="ChatService" verb="GET,POST" />       

    </httpHandlers>-->

  </system.web>

  <system.webServer>

    <handlers>

      <add name="ChatHandler" path="ChatHandler.ashx" type="ChatService" verb="GET,POST" />

    </handlers>

    <modules>

    </modules>

  </system.webServer>

</configuration>

So I was a little overeager earlier and DIDN’T check the app first and went straight ahead to trying to debug the app which got me an error dialog:

---------------------------

Microsoft Visual Studio

---------------------------

Unable to start debugging on the web server. Debugging failed because integrated Windows authentication is not enabled. Please see Help for assistance.

---------------------------

And yes it’s very important to make sure that you enable Windows Authentication in your site in order for debugging to work (this is true for IIS in general). Since I already use IIS for debugging this was not the problem for me.

The first site I tried this on is a my wwHoverPanel samples, which is pretty simple. And it’s definitely not an authentication issue since the site runs just fine with the integrated pipeline. So after screwing around with the settings in the IIS manage for a while I realized I should really look at this from the source:

IIS 7 includes a highly useful feature called Failed Request Tracing  which when turned on gives you a detailed accounting of the last n specified number of failed requests. This option can be enabled on the Web Server or as a whole or on an individual application and you can specify what errors to log and even which request you want to trace (excellent if you know exactly what the problem request is). The output is dumped into a directory of XML files which includes an XSL stylesheet for formatting. When you do, you get a rather useful error trace that looks like this:

(actually the failure is further down in the list but any warnings or errors are summarized above).

In this case you can see that it points at a configuration error in the site and the page that the debugger is apparently trying to hit (debugattach.aspx). Now you can take that page and run it in the browser, and at that point you get a whole bunch of useful error information that points – in this case – at the HttpHandler section not having been migrated to the <system.webServer> section of the web.config file.

If I had tried to run this site first before trying to debug it, I would have found this out immediately without going through the the trace, but hindsight is always… .

The key thing to remember here is that you’ll get an authentication error apparently on ANY KIND of error, so don’t assume it’s an authentication error just because it says so <s>

More problems and – but no Solution

Ok so one problem solved another to go. Originally I had tried this on my West Wind Web Store which is fairly complex application. And unfortunately – even with Failed Request Tracing – I’ve not been able to get to debug under Integrated mode.

The site runs just fine in Integrated mode, but it will not debug. On this site though I DO actually get an authentication error:

What’s interesting though is that the site runs, which means that Windows Authentication is definitely enabled – just to ensure that this is the case I removed the IUSR_ account from the site and sure enough when I run the site it authenticates.

As you can see here authentication fails on trying to read global.asax and FREB reports that authentication is not even available:

Which I don’t get. If that was the case the site would not work. And – if I cause a 404 with an invalid URL I do see the authentication:

I figured maybe this has something to do with the account that is trying to debug, but I even added Everyone to this folder just in case to see if this would make a difference – but no luck…

I’ve mucked around with the permissions, tried to ensure they match with the sample that works, I’ve compared the modules installed made sure that Authentication is indeed enabled – heck I even disabled all other authentication mechanisms (and turned the back on to the default). None of that has any effect. This damn app just does not want to debug under Integrated mode.

I’m giving up for the night…