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

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

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

最终目标(当然)是让一个新的开发人员从SVN中检出干线,恢复DNN数据库,并将其全部“工作”......

0
额外 编辑
意见: 2

5 答案

预计在GAC中的任何程序集都应留在GAC中。这包括您将在生产环境中部署到GAC的System.web.dll或任何其他第三方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被检入颠覆。

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

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

0
额外

当我编码java时,Maven对这个问题有很大的帮助。我们将pom.xml提交给scs,并且maven存储库包含我们所有的依赖关系。 对我来说,这似乎是一个很好的方式来做到这一点。

0
额外

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

0
额外

这是一个.Net的具体问题吗?

一般来说,最好的做法是不要检查任何从已经在SCM中的文件自动构建的东西。所有这些都是您的自动构建过程的一部分。

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

0
额外

Tree Surgeon is a great tool which creates an empty .NET development tree. It has been tweaked over years of use and implements lots of best practices.

0
额外