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-bit preferred)

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

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

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

Answer 1

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

only 可用的标志是 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，“尝试加载格式不正确的程序”。

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