Tuesday, September 14, 2004 3:45 PM bart

MSBUILD "avant les lettres"

The title looks promising but let me raise a warning first: what I'm going to tell you does only cover a little piece of the large MSBUILD-pie. So, what's up? Let me kick off with telling a bit about MSBUILD for the novices on this point. MSBUILD is a technology that is going to ship with future Visual Studio releases to describe the build process (and later on possibly more than just the build process) in a declarative way (i.e. by using XML). The compilation/build process then is not hosted inside Visual Studio anymore (which is today calling the different tools such as csc.exe, al.exe to do the work - or better, calling the functionality that these tools expose through different namespaces and assemblies). This system has a couple of disadvantages: when you have a project (or solution) in VS.NET you can't build it in a smooth way without using the VS.NET tools. Furthermore, the build process today is a closed operation that has little (or no) support for customization.

So, don't look at MSBUILD as a new batch processing system that just describes the steps needed to do a build. It's more than this: it's a whole vision on how to build software (automatically, manually) without needing Visual Studio (but VS will of course have a tight integration with the tools). Other tools can ship in the future that create msbuild files. And, very important, building apps can be done by using the SDK alone instead of having to rely on Visual Studio tools.

Today however, we can only simulate parts of this process by creating our own solutions. I've seen quite some people creating batch files (really, the old good DOS-inherited files with .bat extension ;-)) to automate builds. I've seen others using VB Scripting in WSH and I've seen an approach (which I've tried myself) using System.CodeDom.Compiler (in combination with for example Microsoft.CSharp) which is a bit cleaner.

Let me explain this approach (using CodeDom) first by illustrating it with a small piece of code. We're going to build a C# compiler (actually a compiler-wrapper) using C# itself (you still have to fill in a few remarks but it gives you the basic idea):

using System;
using System.CodeDom.Compiler;
using Microsoft.CSharp;

namespace Demo
  class CscCompiler
    static void Main(string[] args)
       CSharpCodeProvider csc = new CSharpCodeProvider();
       ICodeCompiler compiler = csc.CreateCompiler();
       CompilerParameters p = new CompilerParameters();
       p.OutputAssembly = ...; //replace ... with the name for the output assembly
       p.ReferencedAssemblies.Add("system.dll"); //add other references (see the /r flag of csc.exe)

       p.GenerateExecutable = false; //self-explaining I think

       compiler.CompileAssemblyFromFile(p, ...); //... should point to the input file

Pretty simple isn't it? This way, it's possible to create a build system today (the same can be done for VB.NET) and talk to the compiler from within code.

There's yet another possible approach on how to automate build processes from the command-line. That's by using .rsp files (response files) for the C# compiler (not available afaik for VB.NET). The syntax looks as follows:

csc.exe @answers.rsp ...

where the file specified after the @ symbol is the response file. Response files can be used to wrap up all of the needed command-line parameters of the csc.exe compiler for your build process. The system has a default one which eliminates the need to use /r for .NET Framework libraries (of the basic namespaces). If you've ever wondered why csc.exe-ing a file that uses System.Data (just to pick a namespace) doesn't require the /r:System.Data.dll flag, this is the answer: the CSC.rsp file is read from the framework installation folder (%windir%\Microsoft.NET\Framework\<version number>) and this file contains a series of default /r references for the compiler. The way these files are located are a different question (has to do with the location of the assemblies and the reference load mechism/process of the compiler itself). So, go on and build your own rsp files. It can safe you some work to automate build processes outside Visual Studio today (but keep your eyes opened towards the big release of MSBUILD later on).

Del.icio.us | Digg It | Technorati | Blinklist | Furl | reddit | DotNetKicks

Filed under:


# re: MSBUILD "avant les lettres"

Wednesday, July 06, 2005 8:25 PM by bart