Compiling: verb, to put together or compose from materials gathered from several sources.

Compiling software is easy, it is not the same thing as building software. A build process for software requires development like any other feature. Having a build is not just running MSBuild on a solution file. It means being able to reliably reproduce the build, controlling the environment, running tests and post-build analysis tools, and constraining both the input source and dependent libraries.


A few weeks ago I published NuGet packages for version 1.11.924.348.

I also managed to get protobuf-csharp-port on board. I absolutely live by protobuffers.

Finally I recently published a complete protobuf services rpc layer build on the RpcLibrary and protobuf-csharp-port. Of course much of the code there could be used with any raw transport like WCF, TCP, Named Pipes, etc so check it out. This library is also available on NuGet:

If you haven’t tried NuGet you should look at it. If you manage an open source library you really need to get published there. It has allowed me to publish projects that have dependencies without the need to check those dependencies into source control. This reduces the burden on source control, allows for smaller archives, and makes it easier to upgrade dependencies. So trash the binaries from your source control and get started with NuGet.


I couldn’t have said it better myself. This is an old topic for Jay and I have to credit him for bringing continuous integration into my own life many many years ago. Back in November he wrote a post about builds “Building Software Is Easy“. He captures the main point, it’s all too often ignored by development in favor of what is believed to be simple solutions.

These ‘simple’ solutions often involve generation of master ‘solution’ files in VS.Net and are horrible to maintain. Projects fall off radar as soon as they are removed, some never get added in the first place. Inter-project dependencies can also become issues that have to be carefully hand-crafted at times between projects. All this speaks nothing about deployment, configuration issues, testing, version control, and build-time dependencies. To say it in one sentence: “These ‘simple’ solutions fall short in every way”.

Ask yourself the following:

  • Do you know exactly (version and all) what prerequisites are used to build your software?
  • Do you know all the options that are configured for all your released software projects?
  • Can you be certain you will be able to reproduce the build a year from now, how about two or three years out?
  • Can any machine create a build of your software?
  • Do you know what components need to be rebuilt when an interface changes?

I’m not suggesting you write a massive hierarchy of makefiles or one giant NAnt script. This is a problem that can be solved. What it requires is development effort, time, and dedication.

The comment on the post linked above strikes me as more funny, Julian Simpson writes:

My new theory is:

If it’s available from an IDE, developers will take it on. Hence, you can convince Java developers to have a go at an Ant build because there’s usually IDE support. NAnt? Nope, there’s no native support in Visual Studio.

I find it hard to get .NET developers working on the build. Java developers will approach it. I don’t think they’ll refactor build files unless there’s a plugin.

She is probably right here. It’s not fun work, it’s not challenging, it’s not glamorous work, it’s just work.

I’ve seen these issues many different times and solved them many different ways, some worked well, others did not. Recently we are using some C# to crawl the projects and load them with the Microsoft.Build API and enforce the configurations that way. Seems to work well for us in manipulating all the little settings needed correctly and consistently build. We use another tool I wrote some time ago to actually do the build. Yes we again crawl the entire directory for C# Projects, topo-sort the dependencies, and invoke the build programmatically. Of course you could just as easily output a NAnt file or some other script to run the build once you know what to build and in what order.

Regardless of your solution, you will have to put some development time into it if you want the build to solve problems … or … you may be happy with your build being a problem?