Login | Register   
LinkedIn
Google+
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 3

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
Advanced MSBuild: Logging
MSBuild loggers provide a way to customize the reporting of build events, messages, warnings, and errors. Loggers relay information from build events, messages, warnings, and errors to a log that can be read and interpreted easily. Loggers can display information in the console window, write to XML or a text file, or enter build data into a database. You write logger logic in a managed language project that implements the ILogger interface.

When you run MSBuild.exe from the command line, it uses the default console logger to display build event information in the console window. You can select the level of detail that you want the logger to report by using the /verbosity command line option.

The default console logger accepts additional parameters that can modify the output to the console window. These parameters are specified with the /consoleloggerparameters switch on the command line. If you are using a custom logger, you may want to hide the information displayed from the default console logger. Use the /noconsolelogger switch on the command line to disable the default console logger.

 
Figure 8. Msbuild with Logger Option: This sample logger output shows a "Detailed" level of verbosity.
For custom loggers, use the /logger switch at the MSBuild command line to specify the logger location. As an example, Listing 2 contains the code for a complete custom logger in C#:

The following command line builds the project with the same custom logger, but with a Verbosity level of Detailed (see Figure 8).

MSBuild /nologo /noconsolelogger /logger:SimpleLogger.dll /verbosity:Detailed

Advanced MSBuild: Task Batching
MSBuild has the ability to divide item collections into different categories, or batches, based on item metadata, and run a target or task one time with each batch.

Task batching simplifies project files by providing a way to divide item collections into different batches, letting you pass each batched collection to a task separately. This means that a project file needs to have the task and its attributes declared only once, even though that task may be run several times.

You control task batching by using the %(ItemMetaDataName) syntax in one of the task attributes. The following example splits the TestExample item collection into batches based on the Color item metadata value, and passes each batch to the MyTestTask task separately.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ItemGroup> <TestExample Include="TestItem1"> <Color>Blue</Color> </TestExample> <TestExample Include="TestItem2"> <Color>Red</Color> </TestExample> </ItemGroup> <Target Name="RunMyTestTask"> <MyTestTask Sources = "@(TestExample)" Output = "%(Color)\MyTestFile.txt"/> </Target> </Project>

Here's another example showing a Target element that contains an Outputs attribute with the %(ItemMetaDataName) notation. MSBuild divides the TestExample item collection into batches based on the Color item metadata, and analyzes the timestamps of the output files for each batch. During the build, if the outputs from a batch are not up-to-date, it runs the target; otherwise, it skips that target.



<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ItemGroup> <TestExample Include=" TestItem1"> <Color>Blue</Color> </TestExample> <TestExample Include=" TestItem2"> <Color>Red</Color> </TestExample> </ItemGroup> <Target Name="RunMyTestTask" Inputs="@(Example)" Outputs="%(Color)\MyTestFile.txt"> <MyTask Sources = "@(TestExample)" Output = "%(Color)\MyTestFile.txt"/> </Target> </Project>

Advanced MSBuild: Transforms
A transform is a one-to-one conversion of one item collection into another. In addition to letting a project convert item collections, transforms allow a target to identify a direct mapping between its inputs and outputs.

The syntax for transforms is similar to that for batches. All transform modifiers must be in the format %(ItemMetaDataName). You can use any item metadata as a transform modifier, including the well-known item metadata assigned to every item upon creation.

The following example shows an MSBuild project file using transforms. This example assumes a single .xsd file in the c:\sub0\sub1\sub2\sub3 directory, and a working directory of c:\sub0.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ItemGroup> <Schema Include="sub1\**\*.xsd"/> </ItemGroup> <Target Name="Messages"> <Message Text="rootdir: @(schema->'%(rootdir)')"/> <Message Text="fullpath: @(schema->'%(fullpath)')"/> <Message Text="rootdir + directory + filename + extension: @(schema- >'%(rootdir)%(directory)%(filename)%(extension)')"/> <Message Text="identity: @(schema->'%(identity)')"/> <Message Text="filename: @(schema->'%(filename)')"/> <Message Text="directory: @(schema->'%(directory)')"/> <Message Text="relativedir: @(schema->'%(relativedir)')"/> <Message Text="extension: @(schema->'%(extension)')"/> </Target> </Project>

The preceding example produces the following output.

rootdir: C:\ fullpath: C:\xmake\sub1\sub2\sub3\myfile.xsd rootdir + directory + filename + extension: C:\xmake\sub1\sub2\sub3\myfile.xsd identity: sub1\sub2\sub3\myfile.xsd filename: myfile directory: xmake\sub1\sub2\sub3\ relativedir: sub1\sub2\sub3\ extension: .xsd



Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap