Dela via

MSBuild: The New Build System for Visual Studio 2005 and Longhorn

  • Artikel

MSBuild is the new build system in Visual Studio 2005. It has been built from the ground up in managed code, with scalability, performance and extensibility as core goals.

When designing MSBuild, the development team had several different customer audiences that they kept in mind:

  • The Developer - someone who writes and compiles code regularly;
  • The Build Developer - someone who implements the processes for the build environment;
  • The Build Lab Tech - the person responsible for kicking off and managing the build process, making sure that builds don't break and fixing them as necessary. Note that this person may well not have Visual Studio on their machine.
  • The Build Lab Manager - who needs to track progress of the project and the build success/fail status. This individual would also probably not be a VS user.

MSBuild is actually built into the operating system, rather than the development environment. This means you can build Visual Studio projects without VS installed; all you need is Windows (and .NET Framework 2.0 until Longhorn).

MSBuild is driven by project files, which are created either by Visual Studio (automatically) or by hand by a developer. These are XML files that describe the build process elements (targets: build, clean, rebuild etc. that each contain constituent tasks) and inputs (items and properties). The project file is ultimately fed into the MSBuild engine, which in turn then generates the output.

The XML input to MSBuild is of course strongly-typed; the schema ships with VS 2005 Beta 1 and is called msbuild.xsd: if you include the namespace definition in Visual Studio when editing with its inbuilt XML editor, you'll get full Intellisense when working with MSBuild project files.

You can write the entire build process from scratch, if you like: here's a sample build project that compiles a C# application:

 <?xml version="1.0" encoding="utf-8" ?>
<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
   <PropertyGroup>
      <OutputPath>Bin\</OutputPath>
      <AssemblyName>MSBuildSample</AssemblyName>
   </PropertyGroup>
  
   <ItemGroup>
      <Compile Include="MSBuildSample.cs"></Compile>
      <Reference Include="System.dll"></Reference>
   </ItemGroup>
 
<Target Name="Build">
   <MakeDir Directories="$(OutputPath)"
            Condition="!Exists('$(OutputPath)')" />
   <Csc Sources="@(Compile)"
        References="@(Reference)"
        OutputAssembly="$(OutputPath)$(AssemblyName).exe" />
   </Target>
</Project>

To make the process simpler, MSBuild reuses elements of the build process through the use of .targets files, which define a compile target which is the override for any defaults. For example, Microsoft.CSharp.targets defines how to build C# applications with MSBuild; a similar file exists for J# and VB in the .NET Framework 2.0 directory (as specified in the LIBPATH environment variable).

Comments

  • Anonymous
    July 18, 2004
    The comment has been removed
  • Anonymous
    July 19, 2004
    Your post hints that this might be possible by using .target files - is it possible to customise build rules so that (say) C++ files also get linted as part of the compile step?

    Would there be any way of differentiating between files it's possible to lint (standard C++) and those where it's not really practical (e.g. Managed C++ and presumably C++/CLI initially)? Currently we're using different file extensions to make this differentiation, but it might be useful if we could say something along the lines of "apply this rule in this folder; apply that rule in that folder".

    I've read quite a bit about MS Build but no-one (that I have seen) has quite covered that area.
  • Anonymous
    July 20, 2004
    The comment has been removed
  • Anonymous
    July 20, 2004
    Brilliant Kieran, that's just what I wanted to hear. Thanks!
  • Anonymous
    July 20, 2004
    Neat, they finally stole ant
  • Anonymous
    July 29, 2004
    It will be interesting to see what happens to NAnt when MSBuild hits the streets.
  • Anonymous
    August 15, 2004
    It will be forced to improve and innovate to remain in use - I can't wait.
  • Anonymous
    March 22, 2006
    Ha! Just when I was in the middle of converting all of my old non-vs (N)makefiles to Ant!