c# - x86 程序集的 null PublicKeyToken

Question

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

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

我的问题是，当我编译托管 C++ 项目以面向 x86 平台时，结果 DLL 具有由 ILSpy 报告的 PublicKeyToken = null。当编译为目标 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，“尝试加载格式不正确的程序”。

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