Is it possible to debug IIS without affecting all users of the service?

This may seem like a silly question, but we are having an issue debugging IIS in a shared test environment and I'm hoping that someone out there can give us an answer.

We have a Windows Server 2003 that is runnin开发者_开发知识库g IIS 6 and sharepoint 2007. We are debugging locally on the server with visual studio 2008.

When someone attaches the debugger and steps through the code, we find that all users are affected. In essence the web server stops handling all requests from all users.

Our question is whether this is a typical situation and is to be expected? Or is there some configuration that we can change that would allow the one user's session to be debugged but leave the other's unaffected.

Kev's on the right track. You need to make sure that the project you want to debug separate from the others is in its own application pool. This will isolate it to its own process and allow that process to be stopped/debugged without affecting the other applications which can remain in a different pool.

Setup

• Start -> Run -> inetmgr
• Right Click on Application Pools
• Click New -> Application Pool
• Name the new pool
• Right Click on the application you want to isolate
• Click Properties
• Click on the Home Directory tab
• In the application pool drop-down list select your new pool
• Click OK

If there are any requests queued in the old process, they may take a few minutes to terminate before all requests are being diverted to the new process.

Debugging

To figure out which instance of w3wp.exe you need to attach the debugger to:

• Start -> Run -> cmd
• Type iisapp
• You may be prompted to register CScript, if so click yes and run it again

The only gotcha you may still find is that if multiple applications are using the aspnet_state service you may run into blocking issues if you need to debug that process as well.

Links

• MSDN
• Developer.com

"When someone attaches the debugger and steps through the code, we find that all users are affected. In essence the web server stops handling all requests from all users."

This is normal, once you attach a debugger to a process such as inetinfo.exe or w3wp.exe and set a break point, every request/thread will be blocked until you allow the debugger to continue, until the next break-point.

I've never found a way around it. Is there some reason you can't debug on each developer's workstation?

Set up a parallel project on the server and try using that. You could use debug.mydomain.com and then just use that for testing. The only reason that I personally can think of to debug on your live servers is if there is a significant difference in the functioning of your app due to either hardware or software configuration.

Ideally you want to have a separate server/instance of your system in as similar an environment as possible so that you don't have to debug on your live machine. Also you might want to consider writing all errors to the event log or at least checking the log since asp.net usually get logged there. This way you can see where your errors are and use that to help you solve your problem in the development environment.

I believe in visual studio you can set the debugger to break only the process being debugged, and not all the processes. Depending on how your system is set up, YMMV with this.

It can't be changed AFAIK. But that's a normal practice to set up separate web-node or web-application for development/debugging purposes. If that's necessary to know exact values of some vars in certain situations you can always use debug logging.