Purpose

When we have a multi-solution software product, how do we manage the build process?

Proceedings

Here's what went down...

Continuous Integration

• For small teams, this is critical to have to reduce friction
  • When you check in, it will checkout your source tree, rebuild your software, run your tests, and let you know what happened
  • Look at system tray for icon that says if the build is good or bad
  • TFS has issues with merging files after rename / moves, this will help reduce that friction as well
• Suggested products:
  • TeamCity
    • free professional version available
    • free hosting for open source projects available from CodeBetter.com (details)
  • CruiseControl (.NET)
    • free
    • details?
  • Hudson
    • free
    • details?
  • Team Foundation Server (TFS)
    • If you are implementing TFS, you might as well embrace the whole TFS stack (builds included)

Build Notes

• Roger Knapp (http://csharptest.net/) has written a program that is pretty slick:
  • It will walk the source tree and replace all project references with file references
  • It will then determine the correct build order, then invoke msbuild programmatically to build everything
  • All the outputs are redirected to common "bin" and "obj" folders
    • this way, all the binaries can wiped out in one shot
    • no fighting with visual studio's locking mechanism on bin / obj folders (and vshost files)
  • It can also do style checks on projects
    • make sure that folder structure matches project namespace
    • make sure that all files that are in the project file are in source control
  • If there are problems with the project, the Continuous Integration build will fail and will yell at the developer
  • It will also do a sanity check on all the DLLs and EXEs to make sure that they were built after the build started
  • If a project references NUnit, it will treat it as a test project and run it through NUnit
  • The program is "csbuild" and he is trying to get it to a point where he can release it as open source
  • Convention based: adding projects doesn't require any extra overhead tasks, just check it into source control
• Garo Yeriazarian (http://garoyeri.blogspot.com) uses NAnt to manage his builds
  • Have a "sterilize" target (invoked as "nant s") that will wipe out all the bin / obj folders in one shot
  • Build script in each folder (app.build) that will build invoke the build script in the sub folder
    • Each leaf node will build itself, then its parent node will copy all the result files (stripping out common stuff) into the parent node's bin folder
    • At the end, you have a bin folder that has overlaid all the build results
  • Pain Points:
    • Need to copy / paste boilerplate build script chunks for a new project / folder set
    • Takes forever to build because of all the file copying that is done manually
    • NAnt is invoking msbuild, makes it slower
• What about hiring a "Build Developer"?
  • Developers should be responsible for the build
  • Don't have a dedicated build person, make it a team responsibility
  • Have a developer spend some time setting up the build system
• The Build is unloved.
  • It's not usually considered until too late in the development process
  • Need to address this to help with Continous Integration and to keep the team's sanity when the project is starting up (or even during the project)

Fun with MSBuild

• When invoking MSBuild programmatically, be very aware of what version of MSBuild you are calling
  • Need to set up app.config file in your calling app to ensure that MSBuild is called from the right SDK (2.0 vs. 3.5) and uses the right compilers
  • There ARE differences between MSBuild and CSC (and probably VBC) between the 2.0 and 3.5 SDKs
  • When turning off warnings, if you turn off a warning that is in C# 3 compiler but doesn't exist in the C# 2 compiler, it is a compilation error
  • Create separate AppDomain to pass right settings to the MSBuild
• Dealing with 32-bit / 64-bit builds
  • You can use the /p:name=value command line parameter to adjust anything that appears in a .sln file
  • /p:platform=x86 or x64
  • To differentiate between 32-bit and 64-bit DLLs and EXEs:
    • Use the "Configuration" property of AssemblyInfo files
    • Use a Macro expansion (search / replace)
    • This will add an entry into the right-click Properties of a DLL or EXE, you can say "32-bit" or "64-bit" or add any other messages

Neat Trick with Assembly Resolver

• Roger Knapp (http://csharptest.net/) shared this tidbit:
  • Dealing with same app deployed to different servers
  • Each server could have a different version of the app
  • Smart Client type software needed to communicate with the server app
  • Run the client app, then pick the server
  • Hook into the Assembly Resolver, then when assemblies are requested, download gzipped assemblies from the right server (and the right version), decompress them and load them directly in memory (never hits the disk)
  • Ooooohs and Aaaaahs heard around the table

Talking about Installers

• WiX (Windows Installer XML)
  • open source, XML based installer building tool
  • Use build script to automate installer generation
  • TortoiseSVN's source code has a nice scheme for setting versions in the installer
  • WiX is a very low-level interface to MSI, you NEED to learn how MSI works and what it expects before being able to really use WiX
    • This information is available on MSDN in the Windows Installer section
  • Use WixEdit to help you learn how WiX does certain things in the XML files
    • Tweak the installer in WixEdit, see how it changes the XML, repeat as needed
• WISE
  • Looks like they were acquired by Symantec
  • Not sure, but I think it does NOT build MSI files
• NSIS
  • Initially from Nullsoft, the makers of WinAMP
  • Script-based, doesn't build MSI files
• InstallShield
  • The original, infamous installer builder!
  • Builds MSI files
  • Supposedly user friend, but I have never used it