在使用 SVN 的协作开发环境中签入 BIN 目录的最佳实践是什么?是否应该从签入中排除项目级别的引用?添加所有 bin 目录更容易吗?
我开发了很多 DotNetNuke 站点,似乎在多开发人员环境中,正确设置环境始终是一项艰巨的任务。
最终目标(当然)是让新的开发人员从 SVN 签出主干,恢复 DNN 数据库并让这一切都“正常工作”......
在使用 SVN 的协作开发环境中签入 BIN 目录的最佳实践是什么?是否应该从签入中排除项目级别的引用?添加所有 bin 目录更容易吗?
我开发了很多 DotNetNuke 站点,似乎在多开发人员环境中,正确设置环境始终是一项艰巨的任务。
最终目标(当然)是让新的开发人员从 SVN 签出主干,恢复 DNN 数据库并让这一切都“正常工作”......
任何预期在 GAC 中的程序集都应留在 GAC 中。这包括 System.web.dll 或您将在生产中部署到 GAC 的任何其他第 3 方 dll。这意味着新开发人员必须安装这些程序集。
所有其他第 3 方程序集应通过相对路径进行引用。我的典型结构是:
-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
您所指的目录包含第三方二进制文件,而不是您的项目的构建,请忽略(否决?)此建议。
Tree Surgeon是一个很棒的工具,它可以创建一个空的 .NET 开发树。经过多年的使用,它已经过调整,并实施了许多最佳实践。
当我编写 Java 代码时,Maven 对解决这个问题有很大帮助。我们将 pom.xml 提交到 scs,maven 存储库包含我们所有的依赖项。对我来说,这似乎是一个不错的方法。
我们遵循使用包含所有供应商特定标头和二进制文件的供应商目录的做法。目标是任何人都应该能够通过检查并运行一些顶级构建脚本来构建产品。