Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Automated Builds - how to do it?

How are people managing automated builds in the dotNet world?  We would like to leverage the nice automatic dependency checking and stuff we get in the project and solution browser, but how to manage the differences between debug and release builds?

i.e. When building Assembly A that depends on Assembly B, you want to make sure that A-debug links to B-debug, and A-release links to B-release.

Are Makefiles the answer, or is there something I haven't found yet?

Also: is there a way to run builds on machines that are not logged in?  We've found that we need to run compiles on a console that has been logged in.  The Scheduled-tasks tries to start the build, but it seems to sit and hang in the background.

Christian Mogensen
Thursday, September 19, 2002

We built our own build tool that does dependency tracing to optimize the build order.

I believe NANT however is an attempt to do this in a publicly available way that you should check out.

Chris Kinsman
Thursday, September 19, 2002

Check out

It supports .NET.  We use it here.

Michael H. Pryor
Thursday, September 19, 2002

We've completely replaced the build tools in MSDEV with a modified version of the perl-based build system called 'cons'.  I don't know if we can make it play well with .NET or not (it works with MSDEV 6), and that's one of the reasons we're a little reluctant to just jump ship completely to move to .NET.

I've always thought MS completely ignored the "build" problem in MSDEV, because whenever I had a project of any complexity, I would have to blow things away and rebuild the entire thing from scratch at least once a day, "just to be sure".  I encountered all kinds of situations where a PCH file wouldn't be recompiled when it needed to be, or when a LIB file was updated and the executable dependent upon it didn't rebuild (and yes, the projects were dependent).  I kept hoping that new releases would fix these rather basic bugs, but they never did.

Also, there is no way to, say, specify the executable or include paths or defines for all projects in one place: I have to get carpal tunnel modifying all 400 project files, or I risk breaking everything with a perl script that does it through the "back door" of the DSP file.

I now know that MS doesn't use MSDEV internally for any large scale projects: Office and Windows itself are built using home-grown internal tools, based loosely on nmake, and they don't use source safe for version control either.  They consider MSDEV to be a "toy", meant for projects with only a few developers.  [I know this information first hand from MS employees who are friends of mine, not from internet rumors.]

So, I figured, if the people who built it know that it's not good enough for them to use for their big projects, then I know it's not good enough for my big projects.

The only down sides of a custom solution are that 1) you have to maintain it and 2) it has to be made to work with new versions of the development environment, so it slows your adoption of the new environment.

I wish MS would learn the lesson that they have to get the basics down cold before moving on to the snazzy UI and glitzy features.  Dependencies should be set in stone, and should always build whenever they need to, and never more often than they need to.  Central modification of global build parameters should be possible, and even simple.  Automatic builds shouldn't require any UI (which is probably why your scheduled builds require that someone is logged in), and should be easy to manage.

Sorry I can't help with your questions directly, but at least you can weigh the alternatives you find a little better.


Greg Spencer
Thursday, September 19, 2002

I would highly recommend reading the following article on msdn:

Thursday, September 19, 2002

Doesn't VS.NET handle the dependencies for you?

What's wrong with just devenv whatever.sln /build release?  I've got a small system going (about 35 projects), and it works fine for me (just wish it would update web references automatically).

Michael Giagnocavo
Thursday, September 19, 2002

"(just wish it would update web references automatically)." -- Don't we all ;-)

I've had no problems with the command line devenv working out the dependencies for me for both debug and release versions.

As far as the web references go, what I did was set up the solution on the build server as if it were a development box, made sure everything compiles ok, and saved the SolutionName.suo file into some seperate folder.  Then when I get the latest version of the source files from VSS, I replace the suo file with the one I saved off, which makes the solution use the same IIS virtual directory the website/webservices were initially setup to use.  The script then copies in all of the new web files to the underlying directory the IIS virtual directory points to (eg: c:\InetPub\wwwroot\MyWebSite).

Thursday, September 19, 2002

Check out Nant ( You might find it useful.

Dody Gunawinata
Friday, September 20, 2002

A side comment on the utter badness of Web Projects...  Don't use them.  Instead, just build a c# library project and add .aspx files to it.  You'll find that when you add a .aspx file, the project build directory shifts to /bin.  Also, if you add a code-behind .cs file to the project, and then add a CodeBehind="MyController.cs" directive to your .aspx page, they'll be tied together exactly like web projects.

I've found this to work extremely well, and it saves me from having to dealt with the inflexibility of Web Projects.

Ben Lowery
Saturday, September 28, 2002

*  Recent Topics

*  Fog Creek Home