Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Master Complex Builds with MSBuild  : Page 4

As your projects grow more complicated, you'll need a build system to keep track of build results—and MSBuild is up to the task.


advertisement
MSBuild and Visual Studio Integration
Visual Studio 2005 and 2008 can host MSBuild to load and build managed projects. Because MSBuild is responsible for the project, you can use almost any project in the MSBuild format successfully in Visual Studio, even if the project was authored by a different tool and has a customized build process.

Visual Studio does not have a language-neutral MSBuild based project system. MSBuild.exe recognizes any project file name extension matching the pattern *Proj. However, Visual Studio recognizes only a subset of these project file name extensions, which determine the language-specific project system that will load the project.

For example, the Visual C# project system loads .csproj files—but Visual Studio is not able to load an .xxproj file. A project file for source files in an arbitrary language must use the same extension as Visual Basic, Visual C#, or Visual J# project files to be loaded in Visual Studio.

Clicking the Build command in Visual Studio executes the default target in the project. Often, this target is also named Build. Choosing the Rebuild or Clean command will attempt to execute a target of the same name in the project. Clicking Publish will execute a target named PublishOnly in the project.

Configurations are represented in MSBuild projects by properties grouped in a PropertyGroup element that contains a Condition attribute. To successfully extract this list, the conditions must have a format similar to the following:

Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' " Condition=" '$(Configuration)' == 'Release' " Condition=" '$(Something)|$(Configuration)|$(SomethingElse)' == 'xxx|Debug|yyy' "

Visual Studio looks at the conditions on PropertyGroup, ItemGroup, Import, Property, and Item elements for this purpose.

For example, adding the following to your project file will add the custom type JScript to this menu for all projects that import it:

<ItemGroup> <AvailableItemName Include="JScript"/> </ItemGroup>

When possible, Visual Studio will attempt to use the in-process versions of the Visual Basic or Visual C# compilers for increased performance; however, for this to work correctly, the following conditions must be met:

  • In a target of the project, there must be a task named Csc (for Visual C# projects) or Vbc (for Visual Basic projects)
  • The UseHostCompilerIfAvailable parameter of the task must be set to true.
  • Only supported parameter values must be specified. All parameters specified on the task are supported by the in-process compiler, but some parameter values are unsupported.
The following Csc task parameter values are not supported by the Visual C# in-process compiler:

  • NoConfig: false and empty values are unsupported.
  • ResponseFiles: non-empty values are unsupported.
  • AdditionalLibPaths: non-empty values are unsupported.
  • AddModules: non-empty values are unsupported.
  • CodePage: non-zero values are unsupported.
  • GenerateFullPaths: true is unsupported.
  • LinkResources: non-empty values are unsupported.
If these conditions are not met, the project will compile using the command line compiler instead of the in-process compiler.

When you're working inside Visual Studio, it controls the solution file and project build ordering. When building a solution from the command line, msbuild.exe parses the solution file and orders the project builds. In both cases the projects are built individually, in dependency order, and project-to-project references are not traversed. In contrast, when you build individual projects with msbuild.exe, project-to-project references are traversed.

When building inside Visual Studio, the property $(BuildingInsideVisualStudio) is set to true. You can use this value in your project or .targets files to cause the build to behave differently.

Visual Studio recognizes certain property names and values. For example, the following property in a project will cause "Windows Application" to appear in the Application Type box in the Project Designer:



<OutputType>WinExe</OutputType>

Items defined in the project with arbitrary item collection names are by default displayed in the Solution Explorer under their project node. To hide an item from display, set the Visible metadata to false. For example, the following item will participate in the build process but Solution Explorer will not display it:

<ItemGroup> <IntermediateFile Include="cache.temp"> <Visible>false</Visible> </IntermediateFile> </ItemGroup>

Items declared in files imported into the project are not displayed by default. Items created during the build process are never displayed in Solution Explorer.

You'll find several sample MSBuild projects in the downloadable code that will help you understand MSBuild's functionality better.



Tapas Pal is a Microsoft Platform technical professional with Tata Consultancy Services, India. He has with seven years of experience, holds Microsoft certifications in .NET 1.1 and .NET 2.0.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap