IMPORT
The final XML element we'll cover on this tour is Import, and it's the key to making your build process reuseable. It pulls in another MSBuild file. Right at the bottom of your Visual Basic and C# files, you'll see an Import tag that pulls in the "Microsoft. CSharp.targets" or "Microsoft.VisualBasic.targets" file, which is the root of the build process for these projects. Both targets files again import the "Microsoft.Common.targets" file. There's more to MSBuild syntax, which is covered in the online documentation, but this overview should give you an idea.

LOGGERS
Traditionally build processes log to the console and to log files. The information logged is fairly hard-coded: the folder that's currently building, the command lines executing, and their output, including any warnings and errors. MSBuild was designed to log in a much richer fashion. Strongly typed .NET events are fired at each step, and any number of "loggers" can subscribe to the events they want and do whatever they like with the information. Events include "ProjectStarted" and "Message", which can be emitted by a <Message> task in the build. Output from tools the build launches is logged as Message, Error or Warning events as appropriate.

The build process is abstracted from the loggers, which are chosen when the build starts. For example, a builder might simultaneously attach a console logger, several file loggers with different verbosity settings, and a logger that inserts event details in a database. MSBuild ships with a built-in console logger, which is attached by default, and a file logger, both of which have adjustable verbosity settings. Like tasks, loggers are just .NET classes and you can write your own - start by deriving from the Logger class.

How MSBuild Builds a Project
MSBuild can be invoked directly on the command line (msbuild.exe) or inside Visual Studio. Either way the build is handled by the same MSBuild engine. Here's what MSBuild does:

1.  First, any global properties are applied to the project. Global properties are special: they can't be modified except within a Target. If MSBuild is invoked from the command line, the set of global properties will be the ones passed in via the /property: command line switch. If MSBuild is invoked as part of Visual Studio, the active configuration and platform are the global properties.
2.  Starting from the beginning of the project file, MSBuild engine evaluates the properties that are defined in the project. Imported targets files are loaded and evaluated as the MSBuild engine progresses: think of them as inserted directly into the project file. If a property is defined in two or more places, the last one wins.
3.  After the properties are evaluated, MSBuild engine evaluates all the item definitions that are defined then makes a third pass to evaluate items. At every step of the evaluation, all previously evaluated property values and item values an be used.
4.  MSBuild starts to execute the entry-point targets. These targets can be specifi ed via the /target: command line switch or the default targets defi ned in the project file through the project element's DefaultTargets attribute, or else MSBuild just picks the first target Visual Studio's entry points are fixed: Build, Clean, Rebuild, or Publish.

If the condition on a target is true, MSBuild will make sure all its dependencies are executed then execute the target itself, invoking the tasks in it one by one.
5.  By using the special "MSBuild" task, a project can cause another project to build. If a project references the outputs of another, it will use the MSBuild task to make sure that project is up-todate. Once the referenced project is done building, the MSBuild engine will resume building the referencing project.

To see what's happening in the build, specify the "detailed" or "diagnostic" verbosity level. To do this from the command line, use the /verbosity: switch to toggle the amount of information displayed during the build. In Visual Studio, this can be customized in the Tools/Options menu. On the "Build and Run" node under "Project and Solutions" from the left pane, you'll see a dropdown for "MSBuild project build output verbosity."

BATCHING TASKS
MSBuild can divide item lists into different "batches" using their metadata then execute each batch one at a time. This can be confusing, but once you get used to the idea it feels natural - and powerful.

Here's an example that creates a different folder for each value of the "Culture" metadata on an item list. You'll see that the Culture metadata, referenced with the special metadata ‘%' syntax, is passed into the task: that tells MSBuild to run the task once for each unique Culture value. In this example, the task runs twice.

<ItemGroup>
    <Resource Include="Form1.en-CA.resx;Form2.en-CA.resx">
        <Culture>en-CA</Culture>
    </Resource>
    <Resource Include="Form1.en-NZ.resx">
        <Culture>en-NZ</Culture>
    </Resource>
</ItemGroup>

<Target Name="CreateCultureDirs">
        <MakeDir  Directories="%(Resource.Culture)"/>
</Target>

Here's a trick that sometimes comes in handy: to execute a task once for each item, you can use the well-known item metadata Identity, which usually has a different value for each item.

Hosting the MSBuild Engine
If you like, you can host the MSBuild engine in your application, just as Visual Studio does. By referencing the Microsoft.Build.BuildEngine assembly, you can load, edit, and build projects. Perhaps you're writing a tool for analyzing a build tree, or even a product like Visual Studio that you want to read and write MSBuild format projects.

WORKING WITH OTHER BUILD SYSTEMS
As we mentioned, not all Microsoft project types are in MSBuild format right now. In Visual Studio 2005, Visual C++ projects are in their own format, as are Visual Studio Deployment projects and ASP.NET Web site projects. Visual Studio solution fi les are still in their own format too. Of course, most of us have some of these projects, and we need to build them on the command line too.

MSBuild does its best to interoperate with them. MSBuild can read Visual Studio solution files by translating them internally into MSBuild format. When a Visual C++ project is encountered, MSBuild will try to build it with vcbuild.exe, which ships as part of Visual Studio and the .NET SDK. For ASP. NET Web site projects, MSBuild will launch a tool to pre-compile them. In both cases, MSBuild generally won't require Visual Studio installed to build them. Indeed Visual Studio Team System's Build Server feature is designed to use MSBuild to work on dedicated build machines that don't have the full Visual Studio product installed.

The interoperability isn't perfect. As you'd expect, the different formats can't work together exactly. We hope MSBuild handles them well enough for most people to get by until they are all based on MSBuild. If you don't get the results you need, the fallback is to have Visual Studio installed and build with Visual Studio's devenv.exe application on the command line.