最佳实践：协作环境、Bin 目录、SVN答案

【问题标题】：Best Practice: Collaborative Environment, Bin Directory, SVN最佳实践：协作环境、Bin 目录、SVN
【发布时间】：2010-09-05 05:49:19
【问题描述】：

在使用 SVN 的协作开发环境中签入 BIN 目录的最佳做法是什么？是否应该从签入中排除项目级别的引用？添加所有 bin 目录是否更容易？

我开发了很多 DotNetNuke 网站，似乎在多开发人员环境中，正确设置环境始终是一项艰巨的任务。

最终目标（当然）是让新开发人员从 SVN 中检出主干，恢复 DNN 数据库并让这一切“正常工作”...

【问题讨论】：

标签： svn collaboration

【解决方案1】：

任何预期在 GAC 中的程序集都应留在 GAC 中。这包括 System.web.dll 或您将在生产中部署到 GAC 的任何其他第 3 方 dll。这意味着新开发人员必须安装这些程序集。

所有其他第 3 方程序集应通过相对路径引用。我的典型结构是：

-Project
--Project.sln
--References
---StructureMap.dll
---NUnit.dll
---System.Web.Mvc.dll
--Project.Web
---Project.Web.Proj
---Project.Web.Proj files
--Project
---Project.Proj
---Project.Proj files

Project.Web 和 Project 相对引用根/References 文件夹中的程序集。这些 .dll 被检入 subversion。

除此之外，*/bin */bin/* obj 应该在你的全局忽略路径中。

使用此设置，对程序集的所有引用要么通过 GAC（因此应该适用于所有计算机），要么与解决方案中的每个项目相关。

【讨论】：

【解决方案2】：

这是一个 .Net 特定的问题吗？

一般来说，最好的做法是不要签入从 SCM 中已有的文件自动构建的任何内容。理想情况下，所有这些都是作为自动构建过程的一部分创建的。

如果您所指的 bin 目录包含第三方二进制文件，而不是您的项目的构建，请忽略（否决？）此建议。

【讨论】：

【解决方案3】：

Tree Surgeon 是一个很棒的工具，它可以创建一个空的 .NET 开发树。经过多年的使用，它已经过调整并实施了许多最佳实践。

【讨论】：

【解决方案4】：

当我编写 java 代码时，Maven 对解决这个问题有很大帮助。我们将 pom.xml 提交到 scs，maven 存储库包含我们所有的依赖项。对我来说，这似乎是一种不错的方式。

【讨论】：

【解决方案5】：

我们遵循使用包含所有供应商特定标头和二进制文件的供应商目录的做法。目标是任何人都应该能够通过检查并运行一些顶级构建脚本来构建产品。

【讨论】：