在混合托管/非托管环境中支持多种体系结构的最佳方法是什么？

Question

背景

我们有一个.NET库，它引用了我们的一个非托管dll，让我们说：

• DotNet.dll
• Unmanaged.dll

到目前为止，Unmanaged.dll只有32位，所以DotNet.dll标有32位CPU类型。

需要添加64位支持。如何组织dll？ 对于32位和64位版本，DotNet.dll的IL代码都是相同的。

选项1

• 32Bit Libraries文件夹
  • DotNet.dll，32位的CPU类型
  • Unmanaged.dll，编译为32位
• 64Bit Libraries文件夹
  • DotNet.dll，64位的CPU类型
  • Unamanged.dll，编译为64位

在这种情况下，使用这些库的开发人员被迫生成2个应用程序：32位和64位。但在这种情况下，确切知道发生了什么。

选项2

这与选项1相同，但DotNet.dll的CPU类型为AnyCPU。

• 32Bit Libraries文件夹
  • DotNet.dll，AnyCPU的CPU类型
  • Unmanaged.dll，编译为32位
• 64Bit Libraries文件夹
  • DotNet.dll，AnyCPU的CPU类型
  • Unamanged.dll，编译为64位

我不喜欢这个，因为使用这些库的开发人员在重新分发他们的应用程序时，如果不在他们的应用程序上设置CPU类型，就不能很好地使他们的应用程序崩溃：

• 如果他们使用32位库文件夹，则在64位操作系统上，他们的进程将崩溃
• 如果他们使用64位操作系统文件夹，则在32位操作系统上，他们的进程将崩溃

这使选项1优于选项2。

选项3

• Unmanaged_x32.dll，编译为32位
• Unmanaged_x64.dll，编译为64位
• DotNet.dll，AnyCPU的CPU类型

DotNet.dll在运行时会确定它运行的位数，然后PInvoke正确的Unmanaged.dll。

问题（S）

1. 作为这些图书馆的开发者，哪个选项最有意义？
2. 作为使用DotNet.dll库的开发人员，哪个选项最有意义？
   1. 对于选项3，如果您使用的是DotNet.dll，您是否想知道运行时库是否确定要使用的Unmanaged.dll？
   2. 如何使用这些库重新分发您的应用程序？
3. 是否缺少某些选项？

Answer 1

Answer 2

选项3似乎最简单，而选项1似乎是最安全的。仅从要调用的库的角度来看，除非你处理大量的调用，否则它们似乎并不难以管理它们。主要问题是你将不得不两次声明任何给定的函数，使用32位和64位版本的不同名称，然后只需将DllImport属性更改为指向正确的目标。你的存根函数必须在运行时决定调用哪一个。

请注意，除了物流外，您无需在库文件夹中包含两者。只要您不调用“错误”库的调用，排除它就不会产生任何影响。

Answer 3