Items are the input of the build process. Items are created as child elements of the ItemGroup element. Items that share the same name are considered a collection. Item collections are addressable in the build project as @(ItemCollectionName). Item collections are primarily used as parameters in build tasks.

For example, the Compile element is a standard item. It defines the source files that are included or excluded from the build. The Include attribute specifies a file to be included in the build. The Exclude attribute, naturally, excludes files. The following code defines a Compile collection, which includes two items and excludes a third item:

<ItemGroup>
  <Compile Include="source1.cs"/>
  <Compile Include="source3.cs" Exclude="source2.cs"/>
</ItemGroup>

Properties are configuration data for the build process that represent individual values and cannot be grouped into collections. They are defined as child elements of the PropertyGroup element. Refer to properties in the project using the $(property) syntax.

<PropertyGroup>
  <ApplicationVersion>1.2.3.4</ApplicationVersion>
</PropertyGroup>

There are several reserved properties in the MSBuild environment. Table 4-4 lists the reserved properties.

Tasks are the build operations of an MSBuild project. Each task is a child element of the Target element. Tasks can accept parameters, which are attributes of a Task element. Item collections and properties, as described previously, are valid parameters to tasks. Create multiple targets to batch groups of build operations. The MSBuild tool can invoke different targets. For example, you can create targets for release versus debug builds.

Tasks are written in a managed language and are available to any MSBuild project. You can create custom tasks for MSBuild projects. All tasks must implement the ITask interface.

Table 4-5 lists the default tasks available in the MSBuild environment.

MSBuild elements and attributes are assembled in a project file. An MSBuild project can have any number of tasks, item collections, and properties. This is a general skeleton of an MSBuild project:

<?xml version="1.0" encoding="utf-8"?>
<!-- MSBuild Schema -->
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <!-- Item Collection -->
  </ItemGroup>
  <Target Name="Task1">
    <!-- Task(s) -->
  </Target>
  <PropertyGroup>
    <!-- Properties -->
  </PropertyGroup>
  <ItemGroup>
    <!-- Item Collection -->
  </ItemGroup>
  <Target Name="Task2">
    <!-- Task(s) -->
  </Target>
</Project>

Here is the syntax to execute the project from an MSBuild command line:

Msbuild switches projectfile

MSBuild command-line switches are listed in Table 4-6.

This section provides an example of a normal MSBuild project. The project contains two tasks: The first task compiles an assembly from the available source files, and the second task creates a DLL from a source file. The project then compiles the remaining source files, which need a reference to the just-built DLL. The sample MSBuild project is documented with steps. Here is the project, followed by a description of each step:

<?xml version="1.0" encoding="utf-8"?>
<!-- Step One-->
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- Step Two -->
  <ItemGroup>
    <Compile Include="source1.cs"/>
    <Compile Include="source2.cs"/>
  </ItemGroup>
  <!-- Step Three -->
  <PropertyGroup>
    <DebugType>none</DebugType>
  </PropertyGroup>
  <PropertyGroup>
    <AssemblyName>sample.exe</AssemblyName>
  </PropertyGroup>
  <!-- Step Four -->
  <Target Name="Application1">
    <Csc Sources="*.cs" OutputAssembly="$(AssemblyName)"
         DebugType="$(DebugType)"/>
  </Target>
  <!-- Step Five-->
  <Target Name="Application2">
    <Csc Sources="source3.cs" TargetType="library"/>
    <Csc Sources="@(compile)" References="source3.dll"
         OutputAssembly="$(AssemblyName)" DebugType="$(DebugType)"/>
  </Target>
</Project>

Step One sets the schema for the MSBuild schema.

Step Two creates an item collection for the Compile element. The source files source1.cs and source2.cs are named in the collection.

Step Three sets the defaults for the DebugType and AssemblyName properties.

Step Four defines target Application1, which has a single task. The task compiles the source files in the current directory. It uses both the AssemblyName and DebugType properties.

Step Five defines target Application2, which contains two tasks. The first task compiles source3.cs and places the results in a library assembly; the second task compiles the item collection and references the library assembly.

The following MSBuild command reads the sample.proj project file. The output is the donis.exe assembly. The DebugType property is assigned full and the AssemblyName property is assigned donis.exe. This overwrites the default values of those properties. Finally, MSBuild invokes the Application1 target:

C:>msbuild /p:debugtype=full,assemblyname=donis.exe sample.proj /target:application1

The following MSBuild command executes the tasks of the Application2 target:

C: >msbuild /p:debugtype=full,assemblyname=donis.exe sample.proj /target:application2

Fortunately, ClickOnce deployment is automated in Visual Studio 2008, including the creation of manifest files and configuration of Web servers. In Visual Studio 2008, developers use the Publish Wizard to set up an application for ClickOnce deployment. Right-click the project and choose Publish to start the Publish Wizard.

The Publish Wizard has several steps. The first step identifies the URL to which the application is to be published. Figure 4-46 shows the first window of the Publish Wizard.

Figure 4-46. Step 1 of the Publish Wizard

Step 2 of the Publish Wizard, shown in Figure 4-47, sets how the application is deployed.

Figure 4-47. Step 2 of the Publish Wizard

Step 3 of the wizard, shown in Figure 4-48, is the confirmation window, in which a developer can review the ClickOnce settings and confirm the deployment.

Figure 4-48. Step 3 of the Publish Wizard