开发工具应附带哪些类型和版本的.NET库？

我正在开发一个商业的.NET开发人员库，我希望它能公开，我想知道我应该为最终用户（开发人员）提供什么版本的.DLL

DLL可能会在我无法预测的各种环境中执行

我目前的计划是提供：

• .NET3.5和.NET4编译版本
• 每个版本都签署了任何未签名的
• 一个编译的32位和一个编译的64位

共有8个不同版本

问题是这是否是一个好策略

我是否应该为那些喜欢在32位和64位环境中运行DLL的人制作一个“AnyCPU”编译版本

---

我不在乎做所有这些版本的额外工作，因为我可以在我的自动构建/打包中轻松做到这一点。

没有理由将库构建为32位或64位，因为进程的“位”取决于应用程序启动，具体取决于.exe文件和操作系统。你选择哪一个无关紧要。但是，如果您的库中确实有一些可执行文件，那么使用32位构建可能是有原因的。只有当您的应用程序依赖于第三方32位库（使用COM互操作）时，才会出现这种情况

---

至于签名/未签名的困境，我不明白为什么你们应该同时发送这两个。如果您想限制开发者，请使用signed，否则就让它不签名。

如果程序集不关心它在哪个平台上运行，我会跳过32/64位的构建，而只提供任意CPU构建。任何CPU都意味着程序集不是特定于32位或64位运行时的，可以由任何一个CPU使用。提供未签名/签名版本有什么意义？为什么不干脆“签字”？事实上，我不明白为什么你不能只发送2；一个用于CLR v2，另一个用于CLR v4。您的应用程序真的从编译中受益吗？为什么版本不同？如果开发人员开发的是64位签名的应用程序，那么我假设他希望DLL是一个签名的64位DLL。这是一个性能有点关键的DLL。如果你有一个有签名的版本，有没有理由包括一个无签名的版本？（我不确定，这就是问题所在）。我认为3.5和4.0签名版本，任何cpu，都应该是好的。如果可能的话，将3.5版本改为2.0或3.0。（不是额外的版本…只是代码所需的最低版本，可能是3.5）@Andy任何CPU与32/64的特定DLL在性能上都不会有任何区别。始终使用强名称，以后再执行非常困难。而拥有一个也不是什么负担。