I tend to use F5 to debug my code, my two teammates have a preference to have the codebase as a virtual directory in IIS and make changes to their code in Visual Studio and then reload the page in a browser to analyse the returned results.
Which is the better technique? Certainly my co-workers had a point that by running using Cassini instead of IIS I was opening up myself to bugs popping up when the application was deployed to a real IIS box on testing and some IIS-specific behavior arose.
But why must I hassle myself with attaching IIS to the W3wp.exe process every time I want to do a line-by-line debug my code? And I always want to be debugging, especially in this new realm of integrated ASP.Net MVC where debugging a View means you have to worry about if the bug lies in your ASP.Net code, your JQuery code, or the service(s) your .ajax or .getJSON calls are making. I didn’t mind the hassle of having to recompile every time a change needed to be made inside the Controller or Business Logic layers once it meant I could track the state of my application during events as closely as possible.
Turns out we can have it both ways. These recommendation from Stephen Walter, although set on the topic of running an ASP.Net MVC Application specifically, are useful for any developer looking to customise the debug and run process when using Visual Studio 2008. So my coworkers and I will both be happy, because now they’ll be readily able to debug their code in real time (and engaging in a better coding practice at the same time) and I’ll be running my debug sessions on top of IIS to remove any possible hiccups from using Cassini for testing.
The settings are available on the Web tab on the Web Application Project’s properties page (ASP.Net MVC or not) and to do this I have to make sure it is set to use a local IIS virtual directory (which I’ll make right there if it isn’t set already) and that I enable the check box that allows me to make code changes without the need to stop debugging and recompile.
