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

使用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

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

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

---

使用此设置，对程序集的所有引用都可以通过GAC（因此应该可以在所有计算机上使用），或者与解决方案中的每个项目相关。

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

通常，最佳做法是不签入任何从SCM中已有的文件自动生成的内容。所有这些都是作为自动构建过程的一部分创建的

---

如果您所指的

bin

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

Maven在编写java代码时对解决此问题有很大帮助。我们将pom.xml提交给scs，maven存储库包含我们的所有依赖项。

---

对我来说，这似乎是一个很好的方法。

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

是一个伟大的工具，它可以创建一个空的.NET开发树。经过多年的使用，它得到了调整，实现了许多最佳实践