ASP.NET Development Webserver Starts but does not Serve Anything

I created a Virtual Application in IIS 7 to host my app so I could test it on other machines on the local network, since the development web server will not respond to requests from machines other than the local machine. I had to allow IIS to login as me to get into My Documents, and enabled ASP.NET impersonation through the IIS. That worked fine, but...

Now the ASP.NET Development Webserver won't serve anything at all. I hit debug in VS2008, the dev webserver starts up seemingly fine, but then the IDE launches Chrome and the browser just sits there twiddling its thumbs. It never fails, but never loads. Nothing.

There are no errors from ASP.NET Development Webserver or Visual Studio or Chrome that I can find. I even looked in the Event Log. Nothing开发者_C百科.

What did I just stupidly do?

---

I haven't got Chrome installed at the moment so i can't confirm for sure before i answer this, but IIRC i have seen this before and the VS debugger cannot correctly launch Chrome and serve it pages from Cassini (the VS development webserver).

The way i got round this previously is to just create a virtual directory in the local (dev machine) instance of IIS, and point it to the folder containing your web project. Then you can use Chrome to browse it just like a normal web site. You can then manually attach the VS debugger to the right worker process.

Alternatively, you could start up the debugger as you are now, and when Chrome sits there, you could manually enter the url for the page you want to start with (it will be http://localhost:<some port>/default.aspx or similar). VS won't be able to debug the script in the page, but it should still debug the compiled code just fine (like it does for Firefox).

---

Holy crap, I know what it was. When I changed the IIS settings to have ASP.NET impersonate me to get into the My Documents folder, it modified the web.config file. Now you're probably thinking, well duh, of course it did. I honestly thought that IIS 7 had some new way of dealing with impersonation other than the web.config setting. Turns out it's just built into the MMC snap-in to manage it now, but it does it in the same way.

Once I reverted back to the original version of the web.config file, ASP.NET Development Server happily worked exactly as intended again. I suppose ASP.NET Development Server craps out if there are impersonation settings in the web.config.