更改 web.config 会卸载 ASP.NET 应用程序，但不会卸载“足够”的应用程序。
我们有一个 ASP.NET Web 应用程序，它是一个 C# DLL，它引用一个 C++/CLI DLL，链接到一些本机静态库。
当我们编辑 web.config 文件时，appdomain 会按预期卸载自身，但是在下一个 Web 请求时，应用程序会因本机代码中的一些访问冲突异常而崩溃。
进一步的调查表明，一旦应用程序域“卸载”，w3wp.exe 进程实际上仍然存在，并且它只卸载我们的 C# DLL（而不是我们的 C++） /CLI DLL）。这可能就是我们收到这些异常的原因。
我们怎样才能阻止这种疯狂呢？我们能否让 ASP.NET 在 web.config 更新时完全回收 w3wp 进程？如果 w3wp 继续存在，我们能否让 ASP.NET 真正卸载所有 DLL？
We have an ASP.NET web application, which is a C# DLL, that references a C++/CLI DLL, that links against some native static libs.
When we edit the web.config file, the appdomain unloads itself as expected, however at the next web request the application crashes with some access violation exception from our native code.
Further investigation has shown that as soon when the app domain "unloads", the w3wp.exe process actually lives on, and it only unloads our C# DLL (and not our C++/CLI DLL). This is probably why we're getting these exceptions.
How can we stop this madness? Can we get ASP.NET to completely recycle the w3wp process upon web.config update? Can we get ASP.NET to actually unload all of our DLLs if w3wp lives on?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
创建包装器程序集，并在程序集/appDomain 被回收时手动 GetModuleHandle + FreeLibrary。
但是，如果您手动创建应用程序域或在 IIS 中为多个应用程序使用一个应用程序池，则会导致问题。
Create a wrapper assembly and manually GetModuleHandle + FreeLibrary when the assembly / appDomain is recycled.
It would cause problems if you create Application Domains manually or use one Application Pool in IIS for multiple applications, though.
找不到比在
Application_End末尾调用Environment.Exit(0)更好的解决方案。Couldn't find any solution better than calling
Environment.Exit(0)at the end ofApplication_End.