How do I manage dependencies for automated builds on my build server?

Question

I'm trying to implement continuous integration into our day to day workings. In our team, we're moving from just building our code in Visual Studio on our workstations and deploying, to using MSBuild.exe and automating on our build server (which is Jenkins) without the use of Visual Studio.

We have external dependencies to references such as Automap in our projects. Because the automap (for example) dll isn't on the build server, the msbuild execution fails, for obvious reasons. There are other dll's which I need to be part of the build, I'm just using automap as an example.

So what's the best way to get any dependencies onto the build server as part of the automated build? I've seen references to using a 'lib' folder, but I don't really understand where I should be putting it (in my project, filesystem, SVN ...?), and how the build server will get to it. I've also read that NuGet can do something with dependencies, but my build server isn't connected to the internet, and I don't understand how I can get my build to pull a NuGet package I may have created, and how it works together.

Edit: I'm using subversion and we cannot use TeamCity as we would have to buy it and there's zero chance of funding.

Answer 1

We run SVN + CCNet. We have an SVN repository for 3rd-party libraries that looks like that:

/foo/foo-1.2.3
/foo/foo-1.4.0
/bar/bar-1.0.0

That is, one directory for each library with subdirectories for each available version.

One rule is that the directories must contain the original libraries - ie you unzip and commit, no modifications allowed.

When you need a library in your project, you add a lib-directory and fill it with links (svn:externals) to the libraries from the 3rd-party repository. Important here is that you do not include the version number in the local directory name. If you need foo-1.4.0, the svn:externals link on your lib directory would look like that:

foo https://svn-server/3rdparty/foo/foo-1.4.0

ie it ends up in /lib/foo. That way upgrading the version becomes much easier because all you have to do is change the svn:externals link to point to the new version, and (as long as the file names didn't change) all projects will automatically get it and be compilable.

As for NuGet.. more trouble than it's worth, but opinions differ :)

Hope that helps

Answer 2

I like stmax's solution, but it may be a little too much work for you at this point.

The simplest thing to do is to create a lib directory in your repository and add all third-party assemblies to that directory. Update all your projects to reference third-party assemblies from this lib directory . Check everything in. When the build server wakes up to do the next build, it will pull the latest changes, which will include the new lib directory and the project reference changes. Green build!

Answer 3

You should read NuGet in details, as it allows you to set up your internal package repository,

http://weblogs.asp.net/jgalloway/archive/2011/02/02/downloading-a-local-nuget-repository-with-powershell.aspx

Answer 4

Your first goal should be to have CI running, regardless of how elegant your system is. The "lib directory" option is often easiest when building your system. You check the binaries into Subversion. It's ugly, but it gets you started and your build levels will be reproducible, which is a must. After this is working, research and pick the external dependency versioning system that fits your needs (likely Nuget).

As a side note, check in detail that a free deployment of TeamCity won't work for you. Last I checked you had to have a large number of coordinated projects or a large number of build agents to require a license.