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

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位
• 64位库文件夹
  • DotNet.dll,64位CPU类型
  • Unamanged.dll,编译为64位

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

选项2

这与选项1相同,但DotNet.dll具有AnyCPU的CPU类型.

• 32Bit Libraries文件夹
  • DotNet.dll,AnyCPU的CPU类型
  • Unmanaged.dll,编译为32位
• 64位库文件夹
  • 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

我会选择选项 3，为 AnyCPU 编译托管程序集，并根据其架构命名非托管程序集。我认为做出这个决定有两个不同的考虑因素：

托管程序集应该针对 AnyCPU 还是特定架构进行编译？

我认为 .NET 开发人员不会期望必须为每个体系结构引用单独的文件。我会使用 AnyCPU 以便拥有一个 dll。

DLL 是否应该根据其架构明确命名？

如果您使用 AnyCPU 作为托管程序集，则只有一个 dll，因此这是一个有争议的问题。

对于非托管程序集，可能期望为不同体系结构编译的文件具有不同的命名。从技术角度来看，以不同的方式命名文件可以让您将两种架构的文件放在同一目录中；这意味着根据架构在运行时调用不同的文件，但这并不是一个巨大的负担。我会对文件进行不同的命名。