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

Question

在使用 SVN 的协作开发环境中签入 BIN 目录的最佳实践是什么？是否应该将项目级别的参考排除在签入之外？添加所有 bin 目录是不是更简单？

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

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

Answer 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 相对引用 root/References 文件夹中的程序集。这些 .dll 已被签入 subversion。

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

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

Answer 2

这是 .Net 特定问题吗？

通常，最佳实践是不要签入从 SCM 中已有的文件自动构建的任何内容。所有这些都理想地作为自动构建过程的一部分创建。

如果您引用的

bin

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

Answer 3

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

Answer 4

当我编写 Java 代码时，Maven 对解决这个问题有很大帮助。我们将

pom.xml

提交到

scs

，maven 存储库包含我们所有的依赖项。

对我来说，这似乎是一个不错的方法。

Answer 5

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