ASP.NET 2.0 上 bin 文件夹中的强命名程序集
我知道不要将强命名程序集放入 ASP.NET 早期版本的 bin 文件夹中。我记得这引起了问题，但我不记得具体是什么问题。有谁知道这是否仍然适用于 ASP.NET 2.0？是否有任何理由不将强命名程序集放入 ASP.NET 2.0 或更高版本上的 bin 文件夹中？
I know not to put strongly named assemblies into the bin folder on early versions of ASP.NET. I remember this caused problems, but I don't remember specifically what problems. Does anyone know if this still applies to ASP.NET 2.0? Is there any reason not to put strongly named assemblies into the bin folder on ASP.NET 2.0 or later versions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您描述的问题已在.NET 2.0 上修复，因此您无需再担心它。
但请注意，如果您将强名称程序集放入
bin文件夹中，并且 GAC 中存在具有相同强名称的程序集，则 GAC 中的程序集将被加载。The problem you describe was fixed on .NET 2.0, so you don't need to worry about it anymore.
However, beware that if you put a strong-named assembly in the
binfolder, and an assembly with the same strong name exists in the GAC, then the assembly in the GAC will get loaded.这应该没有问题。我在开发/测试过程中已经做过几次，我什至有一个当前正在运行的站点，该站点在 bin 文件夹中具有强命名的程序集，没有任何问题。
程序集的强命名是有原因的（显然），因此您应该有充分的理由将它们放入 bin 文件夹中。
There should be no problems with this. I've done it a few times during development/testing and I even have a site currently running that has strongly named assemblies in the bin folder with no issues.
Assemblies are strongly named for a reason (obviously) so you should have a good reason to drop them in the bin folder.
我没有遇到过将强命名程序集放入垃圾箱的问题。我遇到过一些强命名程序集和版本控制冲突的互操作问题，但这些问题是由于开发人员将旧版本的 ComPlus 应用程序库编译到解决方案中而不是当前或较新的版本而引起的。
I have not experienced problems with strong named assemblies being put into the bin. I have experienced some Interop problems with strong named assemblies and versioning conflicts, but those were caused by developers compiling older versions of an ComPlus application library into the solution instead of the current or newer version.