c# - x86 程序集的 null PublicKeyToken

Question

我在编译托管 DLL 项目时遇到问题。该解决方案由两个项目组成，第一个是用 C# 编写的 .NET DLL，另一个是直接引用 C# 项目的托管 C++ DLL。

这两个项目/DLL 都使用磁盘上的 snk 文件进行强命名。 C# dll 的目标框架为 "AnyCPU"，而 Manage C++ 项目编译两次，一次用于 x86 目标，另一次用于 x64。

我的问题是，当我编译托管 C++ 项目以针对 x86 平台时，结果 DLL 有一个 PublicKeyToken = null，如 ILSpy 所报告。在针对 x64 平台进行编译时，DLL 具有正确的 PublicKeyToken。我已经检查了我的项目属性，Configuration Properties -> Linker->Advanced->Key File 下的两个平台目标都正确引用了 snk 文件，没有延迟签名； Target Machine 选项也根据所需的编译目标正确设置。

这是加载 DLL 时 ILSpy 显示的信息。

对于 x64 dll:

// MyDll.x64, Version=1.1.1000.1, Culture=neutral, PublicKeyToken=XXXXXXXXX

// Architecture: x64
// This assembly contains unmanaged code.
// Runtime: .NET 2.0

对于 x86 dll:

// MyDll.x86, Version=1.1.1000.1, Culture=neutral, PublicKeyToken=null

// Architecture: AnyCPU (64-bit preferred)
// This assembly contains unmanaged code.
// Runtime: .NET 2.0

我关心的是 x86 程序集的架构描述:AnyCPU(首选 64 位)

我不确定为什么它使用 AnyCPU 配置以及 64 位首选注释的确切含义？

我还想提一下，我的项目是针对 C# 项目的 .NET Framwork 2.0 构建的，而托管 C++ 项目是针对 v90 平台工具集构建的。我正在使用在 Windows 7 64 位计算机上运行的 Visual Studio 2010。

谁能告诉我为什么会这样，我该如何解决这个问题？

Answer 1

这只是汇编中的 COR header 如何指示所需处理器架构的结果。您可以在 CorHdr.h SDK 头文件中看到声明，您可以在计算机上的 Windows SDK 目录中找到它。您可以使用 CorFlags.exe 实用程序来显示这些值。

唯一 可用的标志是 COMIMAGE_FLAGS_32BITREQUIRED。设置后，它向 CLR 表明您希望以 32 位模式运行程序，即使在 64 位操作系统上也是如此。 .NET 4.5 中添加了一个附加标志 COMIMAGE_FLAGS_32BITPREFERRED，它解决了 ARM 内核上的歧义。 32BITREQUIRED 实际上意味着“需要 x86”而不是“需要 32 位”的程序集过多。

因此没有类似于“需要 64 位”标志的东西，程序集只能指示“32 位”或“无关紧要”。抖动提供了“无关紧要”的胶水，它在运行时生成依赖于体系结构的机器代码。由于 32BITREQUIRED 选项未在您的程序集中打开，因此反汇编程序只能显示 AnyCPU。

下一个细节是可执行文件的PE头中的IMAGE_FILE_HEADER.Machine字段，它表示可执行文件可以在什么样的机器上运行。这对 .NET 程序集来说是一个微弱的信号，因为它们通常不包含任何可执行代码，仅包含 MSIL。它很容易被 Windows 加载程序忽略，.NET 程序集通常将此字段设置为 IMAGE_FILE_MACHINE_I386 以指示 x86。您仍然可以从这样的 EXE 程序集中获得 64 位进程，当加载这样的 EXE 时，会发生一些非常英勇的加载程序结构修补。 mscoree.dll 的工作，即“加载程序垫片”。有关更多信息，请参阅 this post .

由于您在 C++/CLI 项目中以 x64 为目标，因此链接器将 IMAGE_FILE_HEADER.Machine 设置为 IMAGE_FILE_MACHINE_AMD64。反汇编程序看到了这一点，因此生成了“64 位首选”注释。

不要被这里的“首选”这个词所迷惑。反汇编程序看起来不够深入，看不到您的程序集实际上包含由 C++/CLI 编译器生成的机器码。他们不喜欢，没有任何反汇编程序可以将机器代码反编译回 C++/CLI 源代码。该程序集永远不会在 32 位操作系统上运行。 Kaboom 在 32 位操作系统上，程序失败并出现错误 11，ERROR_BAD_FORMAT，“试图加载格式不正确的程序”。

这回答了您的问题，它与强名称没有任何关系。