Working with binary dependencies

We have a reasonably complex build pipeline, using TeamCity & NuGet. This is a generally a Good Thing, but there are occasions when it becomes tempting to go back to having one big solution.

The main problem is the length of the feedback loop: you check some code in, wait for a build, and some tests, and some more tests. Then it triggers another build, and some tests, and some more tests.

And eventually the change arrives at the place you need it. Assuming you didn’t make any dumb mistakes, there’s no network issues, etc etc.

This can sap productivity, especially once you start perusing the internets :)

The alternative is to copy the dlls from one source tree, to another. An arduous process, and easy to get wrong. So script it:

function ripple([string] $project, [string] $source, [string] $target) {
  $targetNugget = gci "$target\packages" -r -i "$project.*" | Where {$_.psIsContainer -eq $true} | Sort-Object -Descending | Select-Object -First 1
  gci "$source\$project\bin\*" -r -i "$project.*" | foreach { cp -v $_ "$targetNugget\lib\net40" }
}

Usage:

$packages = "Project1", "Project2"
foreach ($p in $packages) { ripple $p "C:\code\Solution1\src" "C:\code\Solution2\src" }

This will copy the build artifacts for Project1 (i.e. bin\*\Project1.*) in Solution1, to the highest Project1 nuget package in Solution2 (e.g packages\Project1.3.1.0.456).

(In case it’s not obvious, the name is an homage to the tool being developed for the same purpose by the FubuMVC team)

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s