从.net Core 2.0中动态加载的程序集调试代码

本文介绍了从 Core 2.0中动态加载的程序集调试代码的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我有一个 core 2.0控制台应用程序，它执行以下操作（简化）：

var a = Assembly.Load （Assembly.GetEntryAssembly（） .GetReferencedAssemblies（） .First（i => i.Name == MyAssembly））； var t = a.GetType（ MyType）; var i =（MyBaseType）Activator.CreateInstance（t）; i.Execute（）;

当我调试代码时，它会逐步进入 MyType.Execute（）如预期。

但是，如果我使用以下代码加载程序集：

var path = new FileInfo（Assembly.GetExecutingAssembly（）。Location）; var a = Assembly.LoadFile（Path.Combine（path.DirectoryName， MyAssembly.dll））;;

代码仍然有效，但我无法进入 MyType.Execute（ ）调试中。

知道为什么/出什么问题了吗？

解决方案

这可能是由于应用程序无法找到与 MyAssembly 程序集关联的PDB文件所致，如其中一条注释所述。但是，似乎不需要PDB文件与程序集位于同一文件夹中即可进行调试。

要检查是否已加载符号，请在命令行中输入一个在调用 Assembly.LoadFile（）之后打开行中的断点，然后打开 Modules 窗口（可以在 Debug\Windows 菜单）。在此窗口中，找到 MyAssembly 程序集，并在 符号状态 列中验证值。如果是缺少PDB的原因，则值为 无法找到或打开PDB文件。。您还可以在该窗口中查看调试器在何处查找符号文件。

调试器在多个位置查找PDB文件，如下所述： 在Visual Studio调试器中指定符号（.pdb）和源文件。

根据该文章，PDB文件的默认位置为：

在程序集内部指定的位置（在编译程序集时由链接器放置在该位置）

动态加载的程序集所在的文件夹

本地符号缓存文件夹

Internet，网络或本地符号服务器

我想在您的情况下，

需要注意的另一重要事项是PDB必须与程序集完全匹配，因此在重新编译程序集后，PDB文件应人因此，请进行更新以匹配新版本。

如果PDB文件与程序集匹配并且位于上述位置之一，则您应该能够调试代码。 / p>

可能还有其他原因，这与使用.NET Core并不直接相关，但是我认为正确的PDB加载可能值得验证。

I have a core 2.0 console app that does the following (simplified):

var a = Assembly.Load(Assembly.GetEntryAssembly() .GetReferencedAssemblies() .First(i => i.Name == "MyAssembly")); var t = a.GetType("MyType"); var i = (MyBaseType)Activator.CreateInstance(t); i.Execute();

When I debug through the code it stepps into MyType.Execute() as expected.

However If I load the assembly with the following code:

var path = new FileInfo(Assembly.GetExecutingAssembly().Location); var a = Assembly.LoadFile(Path.Combine(path.DirectoryName, "MyAssembly.dll"));

The code still works but I can't step into MyType.Execute() while debugging.

Any Idea why/what's wrong?

解决方案

This may be caused by the application not being able to locate PDB file associated with MyAssembly assembly, as mentioned in one of the comments. However, it seems that the PDB file is not required in the same folder as the assembly to make debugging work.

In order to check if symbols are loaded, please put a breakpoint in the line just after calling Assembly.LoadFile() and open Modules window (it can be found in Debug\Windows menu in Visual Studio). In this window, find the MyAssembly assembly and verify value in Symbol Status column. If missing PDB is the cause, the value will be "Cannot find or open the PDB file.". You can also use that window to see where debugger tried to find the symbols file.

Debugger looks for the PDB files in several locations, as described here: Specify Symbol (.pdb) and Source Files in the Visual Studio Debugger.

According to the article, the default locations for a PDB file are:

Location specified inside the assembly itself (placed there by a linker when the assembly is compiled)

Folder where the dynamically loaded assembly resides

Local symbol cache folders

Internet, network or local symbol servers

I suppose that in Your case, the first or the second location mentioned should be considered.

Another important thing to notice is that the PDB must exactly match the assembly, so after recompiling the assembly the PDB file should also be updated to match the new version.

If the PDB file matches the assembly and resides in one of the mentioned locations, You should be able to debug the code.

There may be other causes and this is not directly associated with the fact that .NET Core is used, but I suppose that correct PDB loading may be worth verifying.