Question

在使用SVN的协作开发环境中检入BIN目录的最佳做法是什么？项目级参考是否应该从签入中排除？是否更容易添加所有bin目录？

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

最终的目标（当然）是让一个新的开发人员从SVN检出中继，恢复DNN数据库并让它完全“工作”......

Answer 1

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

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

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

Answer 2

这是.Net特定的问题吗？

通常，最佳做法是不检查从SCM中已存在的文件自动构建的任何内容。所有这些都是理想的创建过程，作为自动构建过程的一部分。

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

Answer 3

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

Answer 4

当我编写java时，Maven对这个问题的帮助很大。我们将pom.xml提交给scs，maven存储库包含我们所有的依赖项。对我而言，这似乎是一种很好的方式。

Answer 5

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

最佳实践：协同环境，Bin目录，SVN

5 个答案: