关于协作:最佳实践:协作环境,Bin目录,SVN

关于协作:最佳实践:协作环境,Bin目录,SVN

Best Practice: Collaborative Environment, Bin Directory, SVN

使用SVN在协作开发环境中检入BIN目录的最佳实践是什么? 是否应将项目级别的引用从检入中排除? 仅添加所有bin目录会更容易吗?

我开发了许多DotNetNuke网站,在多开发人员环境中,正确地进行环境设置始终是一项艰巨的任务。

最终目标(当然)是让新开发人员从SVN中检出主干,还原DNN数据库,并使其全部"正常工作"。


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

所有其他第三方程序集都应通过相对路径作为引用。我的典型结构是:

1
2
3
4
5
6
7
8
9
10
11
12
-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(因此应该在所有计算机上都可以进行),或者相对于解决方案中的每个项目。


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


这是一个.Net特定问题吗?

通常,最佳实践是不检入从SCM中已经存在的文件自动生成的任何内容。理想情况下,所有这些都是作为自动构建过程的一部分创建的。

如果您要引用的bin目录包含第三方二进制文件,而不是项目的内部版本,请忽略(否决?)此建议。


当我编码Java时,Maven可以在这个问题上提供很多帮助。我们将pom.xml提交到scs,并且maven存储库包含我们所有的依赖项。
对我而言,这似乎是一种不错的方法。


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


推荐阅读