在运行时从另一个AppDomain调试动态加载的DLL

Question

好的，在运行时解析如何在正在运行的应用程序中加载DLL之后（参见我的previous post），我注意到新加载的DLL中插入的断点未被命中。

场合
我有一个服务器应用程序，我想避免每次更改动态加载的DLL（通过反射）时终止/重新运行

目标
这是我想要做的事情（我知道这本身可能不可能）：

• 运行 Application.exe
• 在newAppDomain中加载 Process.dll 并运行Process
• 调试 Process.dll
• 卸载 Process.dll
• 编辑流程代码，重新编译 Process.dll
• 在 Application.exe
中动态重新加载
• 调试 Process.dll
• 等...

问题
我注意到当在Debug模式下启动Application.exe时，附加到Application.exe的调试器无法访问从另一个AppDomain加载的代码 （我想如果我只是直接从可执行文件启动Application.exe，就没办法让VS调试器调试任何东西，包括新加载的DLL）

可行的解决方法
解决方法（丑陋）解决方案是将DLL的“注入”分离到单独的可执行文件中运行的应用程序，然后由VS调试器监视

我承认我有点困惑。 任何有效，干净的想法？

Answer 1

因为它可以帮助其他人（因为这是我的最佳搜索结果），我发现将DLL的引用添加到＆＃34;其他＆＃34; project可以调试正在注入的组件。＆＃34;虽然我不会像这样部署我的解决方案，但它确实允许我至少调试注入的代码以解决其他稳定代码的问题。这表明IDE在确定程序集标识（或类似）时会查看引用。

在这种情况下，DebugBreak()什么都不做，如果没有添加引用，VS调试器就不会发出信号。我没有测试，但是可以想象任何其他调试器都会被发出信号，所以再次表明IDE明确忽略了信号（其他DebugBreak()工作正常。）

作为一名经验丰富的.NET开发人员，我不得不说这个问题对我来说是新的，即。我认为可以肯定的是，如果我们加载Windows 2000，VS.NET 2001-2002和相同的测试代码，那么休息信号就可以了。

基于OP之前的帖子，最有可能的是，正在加载的程序集实际上正在加载一个独特的标识，即使它是相同的程序集但是从不同的位置/机制加载（对于例如，CLR会将其识别为唯一的程序集，因此IDE也是如此。

某些读者在appdomains之间加载相同程序集的某些情况下可能会或可能找不到LoaderOptimization的值，并注意多次加载相同的程序集。

某人HTH，我被困了大约一个小时。感谢。

Answer 2

将System.Diagnostics.Debugger.Break()放在您当前有断点的DLL中，是否正确抛出？

  

http://msdn.microsoft.com/en-us/library/system.diagnostics.debugger.break.aspx

如果不是，我倾向于同意Sam，卸载失败，或者你正在加载一个不同于你想象的库。