我的开发工具应该附带哪些类型和版本的 .NET 库？
我正在开发一个商业 .NET 开发人员库，我希望将其公开，并且我想知道我应该向最终用户（开发人员）提供开箱即用的 .DLL 版本。
.DLL 可能会在我无法预测的各种环境中执行。
我目前的计划是提供：
- .NET3.5和.NET4编译版本
- 每个版本都签名任何未签名
- 一个编译32位，一个编译64位
总共8个不同的版本。
问题是这是否是一个好的策略？
我是否应该为那些喜欢在 32 位和 64 位环境中运行 DLL 的人制作一个“AnyCPU”编译版本？
我不关心完成所有这些版本的额外工作，因为我可以在自动构建/打包中轻松完成这些工作。
I am working on a commercial .NET developer library that I hope to go public with and I want to know what versions of the .DLL I should provide out of the box to the end user (developers).
The .DLL might be executed in a wide variety of enviroments that I can't predict.
My current plan is to provide:
- Both .NET3.5 and .NET4 compiled version
- Each version signed any unsigned
- One compiled 32-bit and one compiled 64-bit
Totally 8 different editions.
The question is if this is a good strategy?
Should I perhaps also make a "AnyCPU" compiled version for those who prefers that that runs the DLL in both 32 and 64 bit environments?
I don't care about the extra work doing all these editions as I easilly can do that in my automated build/packaging.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
没有理由将库构建为 32 位或 64 位，因为进程的“位数”是在应用程序启动时根据 .exe 文件和操作系统决定的。你选择哪一个并不重要。但是，如果您的库确实有一些可执行文件，则可能有理由进行 32 位构建。仅当您的应用程序依赖于第 3 方 32 位库（使用 COM 互操作）时才会出现这种情况。
至于签名/未签名的困境，我不明白为什么你应该同时发送两者。如果你想对开发者施加限制，请使用签名，否则就保持未签名。
There is no reason to build your libraries as 32 bit or 64 bit because 'bitness' of a process is decided on application start up depending on .exe file and OS. It doesn't matter which you choose. If your library does however have some executable file, there may be a reason to have 32 bit build. This is the case only if your application depends on 3rd party 32 bit library (uses COM interop).
As for signed/unsigned dilemma, I don't see why you should ship both. If you want to place a restraint on developer, use signed, otherwise just leave it unsigned.