【发布时间】：2019-10-08 06:51:13
【问题描述】：
考虑一个简单的 Console .NET 应用程序，它只包含 Visual Studio 的自动生成的空 Main 方法。
根据 Jeffrey Richter 在 mscorlib.dll 上下文中的“通过 C# 进行 CLR”：“当 CLR 初始化时会自动加载此程序集”。很容易理解，因为这个程序集包含 - 其中包括核心类型。
运行应用程序并设置过滤器以查找“mscorlib”文件引用只会产生mscorlib.dll 和mscorlib.ni.dll 的命中：
“ni”代表本机映像，鉴于 mscorlib.dll 程序集被大量使用，因此使用它制作本机映像 - mscorlib.ni.dll - 是有意义的，CLR 将加载它而不是“经典”，mscorlib.dll 一个。
这两个文件都在被访问是意料之中的，因为只要它仍然与生成它的原始程序集同步，CLR 只会使用本机映像。例如，如果源程序集发生更改，则本机映像为no longer used。因此，在加载本机之前，都需要检查两者。到目前为止一切都清楚了。
本机映像，如 Microsoft 所述 here，“是包含已编译处理器特定机器代码的文件”。
假设本机映像仅包含机器代码，我继续尝试使用反汇编程序 (ILSpy) 打开 mscorlib.ni.dll，只是期望“PE 文件不包含任何托管元数据"要抛出的错误。然而，我很惊讶地看到 ILSpy 正确加载程序集，包括清单、类型成员以及为方法显示的 IL 代码：
我怀疑以某种方式使用了对mscorlib.dll 的引用，并且实际上从那里提取了整个数据。然而，为 ILSpy 的图像名称过滤的进程监视器证明我错了：甚至没有一次尝试打开 mscorlib.dll；只有一些尝试获取 .pdb 文件 - 很可能是寻找符号 - 由于该文件不存在而失败。
事实上，这两个程序集 - mscorlib.dll 和 mscorlib.ni.dll - 非常相似，只是 Corflags 结构中的 IL_ONLY 与 IL_LIBRARY 不同。
尝试从 NIC（本机图像缓存）中加载其他本机图像会导致类似的行为。
我可以找到有关原生图像如何仍被视为有效 (here) 的高级详细信息，但对于我的实际问题却没有那么多：
原生镜像怎么能被反汇编到 IL 代码级别？ IL 和机器码一样存储在原生镜像中吗？
2019 年 5 月 27 日更新：微软的定义似乎有些难以捉摸。它可能应该被解释为原生图像“是包含已编译处理器特定机器代码的文件”，除了常规程序集元数据和 IL 代码。术语中的“原生”助词显然会导致错误的含义。
收到的 2 个好的 cmets 引出了下一个自然问题：机器码实际存储在图像文件本身的什么位置？
关于图像文件内容的细节，CFF Explorer 比 JetBrain dotPeek 显示的更多，并突出显示了 2 个额外的部分，一个相当大的 Relocation Directory 条目和一个支持原生图像的神秘 Native Header，但是差不多了。
ECMA 335 标准enter link description here 在第 II.25.4 节中对与代码本身有关的图像文件的物理布局只有几句话。除了方法体紧跟在方法头之后，而且在处理异常处理时有时会有一个额外的方法数据部分，标准并没有真正说明机器代码本身的位置。
【问题讨论】：
-
这看起来准确，实现它的最简单方法。很难看到文件中嵌入了相当多的机器代码。除了文件大小，mscorlib 为 5.5 MB，mscorlib.ni.dll 为 20 MB。我不知道有什么工具可以揭示它。
-
.NET 有反射。这意味着您应该管理元数据以使其正常工作。
-
@HansPassant 我已经添加了我能找到的东西，但就像你暗示的那样，我还没有走得太远。
-
@PetSerAl：你完全正确。假设本机映像只包含本机代码，则不会有任何程序集元数据，更不用说可以通过反射检索的 IL。当时我并没有真正把这些点联系起来。
标签： c# .net clr .net-assembly