如何避免执行 IIS 重置以确保调试器附加到*正确的* IIS 工作进程并命中断点？
我维护一个 ASP.NET Web 应用程序 (.NET 3.5)，它作为旧“伞式”ASP 网站的“插件”运行。
为了在进行一些更改后对其进行调试，我...
- 构建 web 应用程序并
- 加载“umbrella”网站
- ，该网站反过来将实例化 IIS 工作进程（即在其自己的应用程序池中，与旧的 ASP 内容分开）。
- 然后我将 VS2008 调试器附加到该进程。
现在我已经将所有这些内容托管在 IIS 7 中，除非我在步骤 1 和 2 之间重置 IIS，否则我无法让调试器命中断点。
为什么会出现这种情况以及如何修复它？我想这是 IIS 7 设置？
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...
- build the webapp and
- load the "umbrella" website
- which in turn will instantiate the IIS worker process (i.e. in its own application pool separate from the old ASP stuff).
- 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 and how can I fix it? I imagine it is an IIS 7 setting?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
新进程是否真的由伞式站点启动，或者只是寻找 .net 站点进程并找到它，然后使用它。我认为 IIS 不一定会拾取您新部署的代码。必须更改某些文件（例如 web.config），进程才能回收自身并获取更改，否则 IIS 将继续运行当前应用程序池进程中的代码。
我认为这就是 IIS 的工作原理 - 当您第一次浏览站点时，IIS 会启动运行它的应用程序池，并且站点会运行并存在于内存中。它停止查看大部分物理文件，只从内存中运行该站点。如果您对代码库进行一些更改，IIS 不一定会接受这些更改。仅当您更改某些文件（例如 web.config）时，IIS 才会回收应用程序池，从而获取您所做的更改。这导致 IIS 运行一组代码，而 VS2008 运行一组不同的（更新的）代码。当代码不匹配时，您无法调试它。
我认为您也许可以添加监视哪些文件进行更改，但我不确定如何执行此操作。
您可以只回收应用程序池，而不是执行 IISRESET。至少这对你来说会更快。
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.