Why would you use built-in WebDev instead of local IIS

Question

Since starting developing ASP.NET projects I find myself familiar just touching F5 for debugging. I think most of us are learned that way?

From then and much later I learned to live with the spooky port number dedication, xx multiple instances of WebDevXX.exe in my notification bar and the relatively slow loading time. Partly by the start-up and partly also the browsing and testing. Who avoided any kind of issues with erroneous PDB file locations? (Breakpoint could not be hit) Not me!

I never had a real reason to dispute this. But the project settings tab has always been there. "Web" tab, "Servers". I never touched it. Sometimes I manually entered a port number and or a start page path. Custom IIS Web Server? Custom Web Server? That option looked too spooky to touch.

I've now taken the step to kick this absurd thing "WebDev", freshen up my local IIS installation and hooked it into my Visual Studio environment to see and decide what I will loose on this...

Surprisingly, I just press F5. The web page opens surprisingly quick (compared to webdev). The breakpoints were hit immediately. Browsing and testing the web app is nearly the same speed as deployed.

I thought, "OK I'm Lost with IIS when it came to debug client side content" Again, I was surprised. I put breakpoints in a line of JavaScript. I got a superquick break of code and second later Visual Studio showed the breakpoint to me.

My question for discussion is, why are we so automatically using Cassini and what are the drawbacks of local IIS? I say we because I know lot of developers do this - including a few really experienced ones.

Answer 1

The main drawback of using IIS to debug is that you either need to run as admin or turn of UAC to enable debugging. Also, you have to install IIS, which is easy to do but not the default on Windows 7 for example, Cassini will be there with VS so no extra work.

It looks like IIS Express will actually be a better bet going forward. More details here from the Gu.

Answer 2

I set Steve's answer as accept because he have a good reasoning on the use of alternative debuggers. I have used the IIS that ships with Windows clients (XP/Vista/7 whatsoever) for a month.

My grade for the IIS as debugger is very high. You can easy set up applications in IIS within VS2010 itself and load the debugging state very fast from F5. There are also two major benefits. One is that the sites are browseable completely without VS environment. The second is important to me, you know that the files inside the local IIS public folder, are of the structure and dependency that the real iis want.

Using the w3wp process and IIS there are also easier to attach external process debuggers to measure kernel time and so on. This isn't my strongest area, but however.

I found a bug though, which seems to loose/hook up the references to the symbols and dll files used by VS Debugger. The result is that you can't breakpoint (can't currently not be hit - warning). Some of you may experienced this from WebDev. In this IIS case I have to force-shutdown the w3wp processes and delete files inside "c:\windows\Microsoft.NET\Framework\vX.X.XXXXX\Temporary ASP.NET Files\", then up n running again.