是将 dll 注册到 GAC 还是从 ASP.NET 中的 bin 文件夹引用它们更好
如果答案是“视情况而定”，您能否提供一个简短的解释？
and if the answer is "it depends", could you provide a short explanation why ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
GAC 旨在包含在多个应用程序之间共享的程序集。 如果是这种情况，您应该对程序集进行强命名并向 GAC 注册。
如果不是，请将程序集保留为私有程序集并将其作为项目/dll 引用进行引用。
PS：没有真正从您的问题的 bin 文件夹部分获得参考 - 这是哪个 bin 文件夹？
GAC is meant to contain assemblies that are shared across multiple applications. If that is the case, you should strong-name the assembly and register it with the GAC.
If not, keep the assembly as a private assembly and reference it as a project/dll reference.
PS: Didn't really get the reference from bin folder part of your question - which bin folder is this?
冒着遭到否决的风险，我将公然反对大众意见，并表示 GAC 只能作为最后的手段（我能想到的一个例子是，当您使用 biztalk 时，它不会给您提供任何帮助）每个应用程序都有一个 bin 文件夹）。
GAC 最初似乎是在多个应用程序之间共享文件的好方法。 但是，当您想要更新这些应用程序之一时会发生什么？ 您要么必须冒破坏服务器上使用它的所有应用程序的风险，要么最终在 GAC 中得到多个版本。 GAC 中的多个版本并不比与各个应用程序打包在一起的不同版本更好，事实上我想说这更令人困惑。
当您运行网络场时，每台服务器最终都会有一个 GAC，因此如果使用 GAC，将应用程序部署到添加到场的新服务器会变得更加复杂。 您还失去了在服务器上拥有单个程序集副本的优势。
但现在暂时忘记多服务器问题，假设您有一个服务器，其中有 10 个应用程序都使用同一个程序集。 您发现此程序集存在一个仅影响其中两个应用程序的问题。 您是否更新了所有 10 个程序集，这意味着您必须测试所有 10 个程序集，并且您可能会破坏几个其他正常工作的应用程序？ 或者您只是更新损坏的应用程序的程序集，并在下一个开发周期中更新其他应用程序的程序集？ 如果您更喜欢后一种方法，那么我认为应该避免使用 GAC。
At the risk of drawing downvotes I'm going to fly in the face of popular opinion and say that the GAC should only be used as a last resort (one example I can think of is when you are using biztalk which doesn't give you a bin folder for each application).
The GAC initially seems like a nice way of sharing files between multiple applications. But what happens when you want to update one of these applications? You either have to risk breaking all the apps on the server that make use of it or end up with multiple versions in the GAC. Multiple versions in the GAC is no better than different versions packaged with the individual apps, in fact I'd say it's more confusing.
When you are running a web farm you end up with one GAC per server so deployment of an app to a new server added to the farm is made more complicated if the GAC is used. You also lose the advantage of having a single copy of an assembly on your server.
But forgetting about the multiple servers issue for now, let's say you have a server with 10 apps all making use of the same assembly. You identify a problem with this assembly that only affects two of the apps. Do you update the assembly for all 10 meaning you will have to test all 10 and you might possible break several otherwise working applications? Or do you just update the assembly for the broken applications and update it for the others during the next development cycle? If you prefer the latter approach then I'd say the GAC should be avoided.
值得记住的是，默认情况下，.Net 将从 GAC 加载匹配的程序集，而不是从本地应用程序文件夹加载匹配的程序集。
此外，如果程序集经过强名称签名，则从 GAC 加载它的性能会更高。 这是因为为了首先进入 GAC，需要检查强名称，这意味着您的应用程序在加载时不需要再次执行此操作。 如果从本地文件夹加载强命名程序集，则每次都会检查其强名称（不会花很长时间，但都会加起来）。 您只能将强名称签名的程序集安装到 GAC 中，并且需要管理员权限才能执行此操作。
It is worth remembering that by default, .Net will load a matching assembly from the GAC over one from the local app folder.
In addition, if the assembly is strong name signed, then it is more performant to load it from the GAC. This is because in order to get into the GAC in the first place, the strong name was checked, which means your app doesn't need to do it again when it loads it. If you load a strong named assembly from a local folder, then it will have its strong name checked each time (doesn't take long, but it all adds up). You can only install strong name signed assemblies into the GAC and you'll need admin privilege to do so.