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

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

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

解决方案：

预期将存在于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相对引用根目录/ References文件夹中的程序集。这些.dll被检入Subversion。

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

使用此设置，所有对程序集的引用都可以通过GAC(因此应该在所有计算机上都可以进行)，也可以相对于## 解决方案中的每个项目进行。

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

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

如果我们要引用的bin目录包含第三方二进制文件，而不是项目的内部版本，请忽略(downvote？)此建议。

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

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

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