Question

I’m in the process of establishing some new source control best practices for my organization, so I’ve been immersing myself in things like TreeSurgeon for the past few days.

One thing I see a lot is that it’s a best practice to include your references in your source control tree, but in a seperate directory (lib/ in tree surgeon) rather than directly with your code as they naturally appear in ASP.NET projects.

I know a few reasons why it’s bad to source control them directly in the bin folder, but I want to understand the big picture including how you get those references back into, say, an ASP.NET project after you pull down code from source control on a fresh machine.

Thanks in advance!

Brian

Answer 1

You want your external dependencies in a separate folder for several reasons:

• you have clear understanding of what is included in that particular external dependency
• you can add non-build related things like site links, documentation, samples and others without polluting your project
• you can share that dependency between multiple projects
• you don’t want to mix build artefacts with source, as it makes it unclear what is owned by you/your team and what is not
• you want to have explicit steps that bring the external dependencies during build to ensure you have control over what is in the final package
• branching sources will create multiple copies of your dependencies if they are mixed there as well
• lesser chance of some rookie accidentally checking in another version of a file and messing your external dependencies, thus destabilizing your project

To answer your second question:

We usually have a copy of the external dependency in a separate folder, but still under a source control. All project references point to that folder using relative paths. Thus, when people enlist on new machine, they get a full set of sources plus external dependencies ready for building the product.

Also, our build has an additional step that produces clean drop folder outside of the source tree. This is our deployment copy and it contains all the build artefacts and copy of all sources like .aspx that are needed for the final product to work. This enforces people to really think what needs to be included in the final product.