How can I avoid doing an IIS reset to ensure debugger attaches to *correct* IIS worker process and hits breakpoint?

I maintain an ASP.NET web application (.NET 3.5) which is run as a "plugin" to an old "umbrella" ASP website.

To debug it after making some change, I...

1. build the webapp and
2. load the "umbrella" website
3. which in turn will instantiate the IIS worker process (i.e. in its own application pool separate from the old ASP stuff).
4. Then I attach my VS2008 debugger to that process.

Now that I have moved to hosting all this in IIS 7, I cannot get the debugger to hit a breakpoint unless I do an IIS reset between steps 1 and 2.

Why is this the case a开发者_如何学运维nd how can I fix it? I imagine it is an IIS 7 setting?

Is a new process really being started by the umbrella site or is it just looking for the .net site process and finding it, just uses it. I don't think your newly deployed code will be picked up by IIS necesarily. Certain files must be changed (eg web.config) for the process to recycle itself and pick up changes, otherwise IIS will continue to run the code that is in the current app pool process.

I think this is how IIS works - when you first browse your site, IIS fires up the app pool that is running it and the site runs and exists in memory. It stops looking at most of the physical files and just runs the site from within memory. If you make some changes to the code base IIS won't necessarily pick up on those changes. Only when you change certain files, like web.config, will IIS recycle the app pool and thus pick up the changes you've made. This leads to IIS running one set of code and VS2008 having a different (newer) set. When the code doesn't match you can't debug it.

I think you might be able to add to what files are watched for changes but I'm not sure how to do this.

Instead of doing an IISRESET you could just recycle the app pool. At least this will be quicker for you.