Jeremy D. Miller continued his discussion on getting a project running from the scratch (a fine list) with a new post on keeping all your binary dependencies as part of your solution's tree in source control.
I can only agree with this statement, and it's something that's really useful. The way I usually do it is to add a top-level "references" folder to the solution that contains any pre-built assemblies we depend on for build. For example, our current project includes here several client-specific assemblies we use, Rhino Mocks, the Castle-Project assemblies for Windsor and several more.
For large projects that contain multiple solutions, I'll put the base assemblies in there as well. For example, in one large project I was part of we had a base "framework" solution that contain a bunch of reusable components that were the basis of around 5 different big sub-projects (each one having a separate code base). What we did was build the base framework and then included the output assemblies in the References folder for each of the projects that needed them. This ensured consistency because we could be sure when building the project we always used the same build of the framework we intended. If at some point we needed to update the framework for that specific project, we just checked out and updated the binary assemblies and checked everything back in after rebuilding and running all tests.
For things like NAnt and other tools, if needed, I'll create another top-level "Tools" directory containing all needed tools to work with.
All of this was particularly useful when you suddently had to fix a bug found in a production version and you had to go and check out an old version of a project from source control to do so; since you were sure that whatever you got out of source control was not only consistent, but also buildable right from the get go.
As Jeremy quite correctly points out, the whole point of this excercise is to have your solution's code base self-hosting and self-reliant. One unfortunate exception on this arises usually from Microsoft's tools and libraries, since they rarely are "xcopy - useful": they usually require explicitly installing via MSI and thus you usually cannot just include the necessary assemblies in your binary References folder (sometimes you can, and sometimes it's just not practical). The same happens for other third party controls and control suits as well. \
In such a case, you can also include the necessary MSIs and installers in a "Pre-requisites" folder and check that into source control as well.
Technorati: Source Control, Dependencies, Programming
