给 GAC，还是不给 GAC？答案

【问题标题】：To GAC, or not to GAC?给 GAC，还是不给 GAC？
【发布时间】：2010-04-01 16:26:44
【问题描述】：

我有一个用 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 文件夹的忠实粉丝。

【问题讨论】：

他们是否必须更改 DAL 代码？
不，他们不会。我想我明白你要问这个问题了。我考虑过将它编译成它自己的 DLL。
感谢所有关于这个的 cmets。老实说，我认为这个问题没有正确答案，因为它似乎很大程度上取决于开发人员的偏好。尽管如此，我还是将投票最多的答案标记为正确答案。

标签： .net asp.net gac

【解决方案1】：

这很大程度上取决于您的特定工作组的风格偏好。我倾向于以与打包客户端应用程序相同的方式打包网站：在 bin 文件夹中包含所有必需的非 .NET 框架二进制文件，假设将它们复制到/安装到的任何机器都没有任何内容GAC。我的工作团队将我们的第三方程序集作为二进制文件签入源代码管理并标记为参考依赖项，这样每个人都可以使用相同的二进制文件在同一页面上工作，我们永远不必担心开发人员机器之间的安装差异。

GAC 可能是一种方便的节省空间的机制，但我更喜欢通过“内联”文件提供的开发人员环境之间的一致性。

【讨论】：

【解决方案2】：

过去曾参与过具有 GAC 依赖项的项目，但始终令人困惑且难以正确配置项目，导致刚开始时出现各种延迟。当您开发 DAL 的新版本时，它可能会成为一个更大的问题。当你独自一人时，这可能效果很好，但我真的会考虑垃圾箱转储，因为你有一个更大的团队。

【讨论】：

【解决方案3】：

我认为你应该给他们两个选择。

对于懒惰的人，提供 pp DLL 以及签名的 DAL DLL。对于更有经验的人允许他们构建它，只要确保他们知道他们需要 P&P 并且需要对 DLL 进行任何更改。

我总是喜欢共享库，尤其是在服务器端。对于客户，我通常喜欢打包在 bin 中。

【讨论】：