GAC，还是GAC？

Question

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

Answer 1

这主要是针对您的特定工作组的风格偏好。 我倾向于像打包客户端应用程序一样支持打包网站：在bin文件夹中使用所有必需的非.NET框架二进制文件，假设他们被复制到/安装到的任何计算机都没有任何内容GAC。 我的团队在工作时将我们的第三方程序集作为二进制文件检入源代码控制并标记为引用依赖项，以便每个人都使用相同的二进制文件在同一页面上工作，我们永远不必担心开发人员机器之间的安装差异。

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

Answer 2

过去曾参与过GAC项目的项目，它总是令人困惑，很难正确配置项目，导致各种延迟刚刚开始。 当您开发新版本的DAL时，它可能会成为一个更大的问题。 当你在哪里独奏时，这可能效果很好，但是我现在真的会考虑bin dump，因为你有一个更大的团队。

Answer 3

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

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

我总是喜欢共享库，特别是在服务器端。 对于客户我通常喜欢打包。