最佳实践:协作环境、bin目录、SVN

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

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

-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相对引用根/引用文件夹中的程序集。这些.dll被检入Subversion。

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

有了这个设置,所有对程序集的引用都可以通过GAC(所以应该在所有计算机上工作),或者相对于解决方案中的每个项目。

这是一个.NET特有的问题吗?

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

如果 bin 您所指的目录包含第三方二进制文件,而不是项目的构建,忽略(downvote?)这个建议。

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

当我编写Java时,Maven对这个问题有很大帮助。我们将pom.xml提交到SCS,maven存储库包含所有依赖项。 对我来说,这似乎是个不错的方法。

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