最佳实践：协作环境、Bin 目录、SVN
使用 SVN 在协作开发环境中签入 BIN 目录的最佳实践是什么？ 是否应该将项目级别的参考排除在签入之外？ 添加所有 bin 目录是否更容易？
我开发了很多 DotNetNuke 站点，似乎在多开发人员环境中，正确设置环境始终是一项艰巨的任务。
最终目标（当然）是让新开发人员从 SVN 签出主干，恢复 DNN 数据库并让这一切“工作”......
What are the best practices for checking in BIN directories in a collaborative development environment using SVN? Should project level references be excluded from checkin? Is it easier to just add all bin directories?
I develop a lot of DotNetNuke sites and it seems that in a multi-developer environment, it's always a huge task to get the environment setup correctly.
The ultimate goal (of course) is to have a new developer checkout the trunk from SVN, restore the DNN database and have it all just 'work'...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
任何预计属于 GAC 的程序集都应保留在 GAC 中。 这包括 System.web.dll 或您将在生产中部署到 GAC 的任何其他第 3 方 dll。 这意味着新的开发人员必须安装这些程序集。
所有其他第 3 方程序集应通过相对路径进行引用。 我的典型结构是：
Project.Web和Project相对引用root/References文件夹中的程序集。 这些 .dll 已被签入 subversion。
除此之外， */bin */bin/* obj 应该位于您的全局忽略路径中。
通过此设置，对程序集的所有引用要么通过 GAC（因此应该适用于所有计算机），要么相对于解决方案中的每个项目。
Any assemblies that are expected to be in the GAC should stay in the GAC. This includes System.web.dll or any other 3rd party dll that you'll deploy to the GAC in production. This means a new developer would have to install these assemblies.
All other 3rd party assemblies should be references through a relative path. My typical structure is:
Project.Web and Project reference the assemblies in the root/References folder relatively. These .dlls are checked into subversion.
Aside from that, */bin */bin/* obj should be in your global ignore path.
With this setup, all references to assemblies are either through the GAC (so should work across all computers), or relative to each project within your solution.
这是 .Net 特定问题吗？
一般来说，最佳实践是不签入从 SCM 中已有的文件自动构建的任何内容。 所有这些都理想地作为自动构建过程的一部分创建。
如果您引用的
bin目录包含第三方二进制文件，而不是项目的构建，请忽略（否决？）此建议。Is this a .Net specific question?
Generally the best practice is to not check in anything which is built automatically from files that are already in SCM. All of that is ideally created as part of your automatic build process.
If the
bindirectory you're referring to contains third-party binaries, rather than a build of your project, ignore (downvote?) this advice.Tree Surgeon 是一个很棒的工具，可以创建空的 .NET 开发树。 它经过多年的使用进行了调整，并实现了许多最佳实践。
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.
当我编写 Java 代码时，Maven 对解决这个问题有很大帮助。 我们将
pom.xml提交到scs，maven 存储库包含我们所有的依赖项。对我来说，这似乎是一个很好的方法。
Maven helps quite a lot with this problem when I'm coding Java. We commit the
pom.xmlto thescsand the maven repository contains all our dependencies.For me, that seems like a nice way to do it.
我们遵循使用供应商目录的做法，其中包含所有供应商特定的标头和二进制文件。 目标是任何人都应该能够通过检查并运行一些顶级构建脚本来构建产品。
We follow the practice of using a vendor directory which contains all vendor specific headers and binaries. The goal is that anybody should be able to build the product just by checking it out and running some top level build script.