Fog Creek Software
Discussion Board




Building a build process....

I've started using NAnt to script the build for a fairly large C# web application that we've written. The end result is to be able to use a tool such as CruiseControl.NET for continuous integration.

Our application makes use of a number of external DLLS (both managed and unmanaged). Currently, our NAnt script simply references the physical location of those DLL's in order to build our application.

For example, our app uses a 3'rd party Rich Text edit control. All the devs have this installed locally, so referencing this file in the build script isn't a problem when we are building on a developer's machine.

Obviously, that isn't a good solution in the long run and isn't going to work once we move the build process to a dedicated machine.

Here's my question: How to handle 3'rd party DLL's like this in my build process? Do I:

1. Add the DLL's to SourceSafe and tell NAnt to grab these DLL's along with the source code before compilation?

2. Manually copy the DLL's to the build server and just hard code the reference to the DLL in my build script?

3. Something else?

How do other people handle 3'rd party DLLs in an automated build process?

Mark Hoffman
Monday, August 04, 2003

3rd party DLLs should be in source control.

As a general rule of thumb: try to put everything required to build your product in source control, and only back off on the things that are way, way too impractical.

Makes it much easier to deploy new versions to all your developers too.

Gustavo W.
Monday, August 04, 2003

Yes ... source control is not just for source ...

Ideally you should even put the tools and compilers you need to kick off a build into source control.  This way, not only is everyone using the same version of the compiler, but getting a build is as simple as a checkout and then a build.

Alyosha`
Monday, August 04, 2003

You should also put the source code control system you use into source code control, so you always have a copy around that you can restore in case the original copy stops working.

Mister Fancypants
Monday, August 04, 2003

The general theory is to not rely on anything being
installed on the build machine to run a build.
Sync everything needed for the build. This saves
a lot of configuration headaches down the line.

valraven
Monday, August 04, 2003

in source control.

James Ladd
Monday, August 04, 2003

>>>
Ideally you should even put the tools and compilers you need to kick off a build into source control.
<<<
I've always agreed with this. However now that a compiler is (frequently) and IDE with all sorts of regitry entries set up by an install process, it's not clear to me how to do this.

Anyone doing it with VC++6 or similar??

sgf
Monday, August 04, 2003

I use the microsoft compiler for our win32 builds
and gcc for cross compilation. You just have to
figure out the magik combination of files and
environment variables that need to be set.
Both compiler environments are synced for
every build.

valraven
Monday, August 04, 2003

>> I've always agreed with this. However now that a
>> compiler is (frequently) and IDE with all sorts of regitry
>> entries set up by an install process, it's not clear to me
>> how to do this.
>>
>> Anyone doing it with VC++6 or similar??

There is a trade-off here.  Our build script doesn't invoke the IDE (VS.Net), but does invoke the compiler.  Rather than investing the time putting everything under source control and setting up the scripts we make installing VS.Net a prerequiste.

The build script must then be run from a command prompt with the VS.Net environment setup.

I think this is a valid trade off of practicality versus portability.

On a related note: for 3rd party libraries we check the binaries into the CVS repository and the matching source code as a zip file. 

For example, we use the Apache Xerces-C++ XML parser, but we don't want developers having to build it all the time (or even having to wait for the compiler to check the dependencies to see if it should be built). 

-
Tuesday, August 05, 2003

sgf: I've worked in a place where the compiler was cl.exe (Visual C++ 6.0's compiler).  As far as I know there's no issues with checking in the "C:\Program Files\Microsoft Visual Studio\VC98\Bin" directory into source control (other than licensing issues) ...

Alyosha`
Tuesday, August 05, 2003

We just simply have a list of instructions about what goes on to a developers machine including the controls you need. We store the "setup.exe" for the controls on a shared networked drive and put the "unlock" keys in the instructions. (The document does live under source control)
Keeping the document upto date doesn't seem to be a problem as we tend to reformat / reinstall a developers machine once every three months or so, and errors and omissions get caught at that point. The whole thing is just over 2 pages and consists of 13 stages.

Peter Ibbotson
Tuesday, August 05, 2003

Thanks everyone for the replies.

I was heavily leaning towards putting the DLLs into Source Safe and this just confirms it.

Mark Hoffman
Tuesday, August 05, 2003

*  Recent Topics

*  Fog Creek Home