Why attach debugger to IIS instance

Question

It may be a silly question but why one would like to attach debugger to IIS instance?
These SOs
Attach Debugger to IIS instance
How do I attach the debugger to IIS instead of ASP.NET Development Server?

show you how to do it but could you let me know what are the benefits of doing this?

Answer 1

One time, in my entire career, we had a web app that started getting strange errors that had us baffled. We tried a dozen things to try and figure out what was wrong, but we were panicking and needed an answer immediately. So, we attached a debugger to the production instance and set up a few watch/break points. It helped us track down the errors and fix the problem.

Naturally, it hung the server during our debugging session, and made people mad, but no more mad than they already were, because of the problem we had.

It would not have been necessary if the code had been written better, with error logging and diagnostic points. I don't expect to ever do it again.

Answer 2

Apart from TimG's post a couple of reasons I can think of are:

1. To debug the application in a closer representation of its production environment
2. To debug on a remote machine

Answer 3

Example, like @TonE #1 -- in order to test a deployed website (with web.config transformations) locally, like if you can't remote debug a live website or just need to test config transforms (since you can't run them in-place):

1. Open site project from C:\Dev\AwesomeWebSite\AwesomeWebSite.sln
2. Publish the site to a local folder C:\Webs in Release mode (or Whatever mode)
3. Set up a local IIS website pointing at the published project
4. Do stuff on the locally-deployed version (e.g. browse pages, make webservice calls, etc)
5. Attach VS to w3p.exe (appropriate instance) in order to debug the deployed version

You might be able to effectively do the same thing by instead pointing the Project at your IIS website per this answer.