Visual Studio 2005 on Vista: Timeouts while Debugging Web Applications on IIS

Debugging web applications in windows Vista can be quite a pain if you run into the timeout issue: when you use Visual Studio to debug a web site (or any other web-project) and pause the execution or step through the program, then occasionally the debug session will be terminated unexpectedly.

Fortunately, you can fix that by disabling a certain timeout setting in IIS7.  The error occurs not because the network connection time's out, but because the webserver's .NET Application Domain was reset.

This occurs because IIS7 on Vista "pings" worker processes such as w3wp.exe regularly, and terminates them after a period of inactivity.  By default, if the ASP.NET hosting process seems hung for 90 seconds, it will automatically be terminated.

That feature is potentially a boon for a server's robustness - but it's problematic during development.  You can work around this issue by using Visual Studio's Internal Web Server.  That server brings its own troubles with it, since it's an entirely different server and not the best simulation of actual deployment in any case.

A better solution is to disable the "hung process" timeout.  To do that you'll need to modify the settings of the IIS application pool your web application is running in.

First, determine which Application Pool your web site is currently in by selecting the "Advanced Settings" of the Application in the IIS Manager.  In the screenshot I want to determine the application pool of application "webstatic" on "MySiteToDebug":

 

As in this screen shot, most applications will be in the DefaultAppPool application pool, which you will need to modify.

 

To modify DefaultAppPool (or whatever application pool your application runs in), select "Application Pools" from the tree control left, then select your application pool from the list in the middle, and Edit the "Advanced Settings..." by clicking the link on the right.

 

"Ping Enabled" should be set to false.  This affects all web applications using the application pool, so you'll probably only need to do this once per development machine.

 

By disabling pinging of worker processes, it's possible to debug web applications on IIS7 with VS.NET 2005 without interruptions.

Enabling SSL encryption in IIS7 on Vista

If you're developing web-sites you intend to deploy on IIS, it's useful to develop on IIS7 and Vista, since it's a good, easy approximation of the live, deployed website.  Having fewer differences between development and deployment environments makes you life easier.

If your site is using SSL (https URLs), it can be useful to enable that too on your development machine.  It's extremely simple on IIS7 in Vista, since the IIS7 Manager included with Vista can generate a self-signed SSL certificate for you.  This certificate will generate a warning when you browse to it (since you and no trusted third party signed the certificate), but otherwise it's fully functional.

To enable SSL with a self-signed certificate you first need to create such a certificate.  This is done ins IIS Manager Server Certificates section:

Then click on "Create Self-Signed Certificate":

 

You'll need to fill in a friendly name.  I chose "Progress.NET localhost development cert in this screenshot:

 

Once you've created such the certificate, you need to turn on SSL (i.e. https) support for the website you're developing.  You do this by adding a binding to the website:

 

Choose to make a "Type https" binding (it'll automatically select the default https port 443):

 

Then select the certification you've just made:

 

That's it! You can now browse to https://localhost/ and view your local website in SSL.  Remote users can also do so (if your firewall lets them connect at all).

SSL certifications are specific to a certain hostname.  However, the SSL certificate you created is for the hostname of your machine - whatever IIS7 happens to believe it is (this depends on your domain and computer name, for instance).  You can connect using a different name, such as localhost, but if unless you connect with the "proper" name, your browser will issue a warning.

You can find the name the certificate was issued to in IIS Manager's "Server Certificates" section:

 

My machine's called "PC219.cowog.local" here, so my browser won't warn me about the phishy URL if I connect to https://pc219.cowog.local/ - although some browsers will still warn you since the issuer (your own machine) isn't a trusted authority.  In any case, you can safely ignore these warnings.

Using IIS7 on Vista vs. Visual Studio's Internal Webserver

I spend quite a bit of time developing websites.  Being able to quickly create website is a boon, and if you're developing a website with Visual Studio, it's internal webserver is great for its ease of configuration.  There is no configuration - if you're website is open in VS.NET, you can instantly test and debug it right from within the IDE.

The internal webserver is extremely simple, and fails to implement many features which are available in "real" webservers.  Since it's only intended as a development server, this isn't necessarily a big deal.  As a developer-only tool you probably don't care about its performance much (it's noticeably slower), nor about logging (it can only serve local pages anyhow), SSL (not supported), the exact HTTP support (different from IIS), HTTP 1.1 Hostname-based processing (ignored), or any of a myriad advanced features found in IIS.

There's an intrinsic value in running on the same platform you'll deploy on - the fewer differences there are, the fewer bugs you won't be able to reproduce.  And of course, you can't easily test or debug anything relying on IIS features with a different web server.

Fortunately, you can set VS.NET to use IIS and not it's own internal webserver.  This is especially attractive on Vista, since its webserver is far less crippled than that of Windows XP.  The downside is that it doesn't quite work out of the box on VS.NET 2005.

Nevertheless, it's less buggy that the internal web server, it's faster, and it saves you time in the long run by avoiding an unnecessary difference between between the live site and your development environment.