Best Practice: Collaborative Environment, Bin Directory, SVN

Question

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'...

Answer 1

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
--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 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.

Answer 2

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 bin directory you're referring to contains third-party binaries, rather than a build of your project, ignore (downvote?) this advice.

Answer 3

rictic: In ASP.NET, the /bin directory contains compiled (binary) libraries. Often, this is third Party stuff, hence it can't or shouldn't be automatically built from source.

Answer 4

@Michael I disagree with you. Any 3rd party dll should be placed in a separate "references" folder, and references relatively. Specifically to avoid having to include the /bin folder into your source control.

Answer 5

Maven helps quite a lot with this problem when I'm coding java. We commit the pom.xml to the scs and the maven repository contains all our dependencies. For me that seems like a nice way to do it.

Answer 6

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.

Answer 7

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.