给GAC，还是不给GAC？
我有一个用 ASP.NET 3.5 编写的数据访问层 (DAL)，并使用 Microsoft 模式和模式。实践库（以下简称P＆P）以完成其数据访问。我安装了 P&P，它驻留在我的 GAC 中，因此，从逻辑上讲，我的 DAL 在 GAC 中引用它。因此，P&P 库永远不会被拉到我的 DAL 的 bin 文件夹中。
我在至少五个（甚至更多，但我懒得去数）不同的网站中使用了这个 DAL 项目。这一切对我来说效果很好，因为我是唯一在这些网站上工作的开发人员。
但是，现在我有其他开发人员将在其中一些网站上工作。
问题：如果开发人员从我们的代码存储库中提取 DAL 项目，如果他们没有安装 P&P 库，则不会为他们构建该项目。
我的问题：我应该期望开发人员安装 P&P 库，还是应该将它们转储到 bin 文件夹中并完成它？
我意识到将它们转储到 bin 文件夹中可能是解决该问题的最简单方法，但如果我可以在 GAC 中引用它们，我从来都不是 bin 文件夹的忠实粉丝。
I have a data access layer (DAL) that is written in ASP.NET 3.5 and uses the Microsoft patterns & practices libraries (hereafter referred to as P&P) in order to accomplish its data access. I installed P&P and it resides in my GAC, so, logically, my DAL references it in the GAC. Therefore, the P&P libraries are never pulled down to the bin folder of my DAL.
I use this DAL project in at least five (more than that even, but I'm too lazy to try to count them all) different websites. And this has all worked just fine for me because I'm the only developer who works on these websites.
But, now I have other developers who are going to work on some of these websites.
The problem: if a developer pulls the DAL project down from our code repository, it won't build for them if they don't have the P&P libraries installed.
My question: should I expect the developers to install the P&P libraries, or should I just dump them in the bin folder and be done with it?
I realize that dumping them into the bin folder is probably the easiest way to deal with the problem, but I've never been a big fan of the bin folder if I can reference them in the GAC instead.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这很大程度上是您特定工作组的风格偏好。我倾向于采用与打包客户端应用程序相同的方式打包网站：将所有必需的非 .NET 框架二进制文件放在 bin 文件夹中，并假设将它们复制到/安装到的任何计算机上都不会包含任何内容GAC。我的团队将我们的第三方程序集作为二进制文件签入源代码管理，并标记为引用依赖项，以便每个人都使用相同的二进制文件在同一页面上工作，并且我们永远不必担心开发人员计算机之间的安装差异。
GAC 可能是一种方便的节省空间的机制，但我更喜欢通过“内联”文件提供的开发环境之间的一致性。
This is largely stylistic preference for your particular workgroup. I tend to favor packaging websites the same way I package client applications: with all required non-.NET-framework binary files in the bin folder, working with the assumption that any machine that they are copied to/installed to will not have anything in the GAC. My team at work keeps our third-party assemblies checked into source control as binary files and tagged as reference dependencies so that everyone works on the same page with the same binaries and we never have to worry about installation differences between developers' machines.
The GAC may be a convenient space-saving mechanism, but I prefer the consistency between developer environments provided by "inlining" the files.
过去曾参与过具有 GAC 依赖项的项目，但正确配置项目总是令人困惑且困难，导致刚开始时出现各种延迟。当您开发新版本的 DAL 时，它可能会成为一个更大的问题。当你独自一人时，这可能很有效，但既然你有一个更大的团队，我真的会考虑垃圾箱转储。
Having worked on projects with GAC dependancies in the past, Its always been confusing and hard to configure projects correctly, causing all kinds of delays just getting started. It can become a bigger problem as you develop new versions of the DAL. This may have worked well when you where solo but I would really consider the bin dump now that you have a larger team.
我认为你应该让他们选择两者都做。
对于懒惰的人，提供 pp DLL 以及签名的 DAL DLL。对于更有经验的人来说，允许他们构建它，只需确保他们知道他们需要 P&P，并且对 DLL 的任何更改都需要 gacced。
我总是喜欢对共享库进行 gac'ed，尤其是在服务器端。对于客户来说，我通常喜欢打包在垃圾箱中。
I think you should give them the option to do both.
For the lazy ones provide the pp DLLs as well as a signed DAL DLL. For the more experienced allow them to build it, just make sure they know that they need P&P and any changes to the DLL will need to be gacced.
I always favor shared libraries to be gac'ed especially on the server side. For clients i generally like to package in bin.