Posts Tagged ‘automating software build process’

[MSBuild] Customized tasks – MSBuild Extension Pack

(source: help – MSBuild Extension Pack)

Get started:

  1. Download and install at download MSBuild Extension Pack
    (keep all as default settings)
  2. At the beginning of your build script, add the following line:
    <Import Project=”$(MSBuildExtensionsPath)\ExtensionPack\MSBuild.ExtensionPack.tasks”/>
  3. After that, you can start using the MSBuild Exgtension Pack ‘s tasks.

Intellisense in Visual Studio :


[MSBuild] Reserved Metadatas

Identity The value that was specifi ed in the Include attribute of the item after it was evaluated.
FullPath Full path of the fi le.
Rootdir The root directory to which the file belongs.
Filename The name of the file, not including the extension.
Extension The extension of the file, including the ‘.’.
RelativeDir The path to the file relative to the current working directory.
Directory Directory of the item, without the root directory.
RecursiveDir This is the part of the directory path that is replaced by the first ** of the Include declaration. If no ** is present, then this value is empty.
ModifiedTime The last time the file was modifi ed.
CreatedTime The time the file was created.
AccessedTime The last time the file was accessed.

[MSBuild] Reserved Properties

The following table describes the MSBuild reserved properties.

Property Description
MSBuildProjectDirectory The absolute path of the directory where the project file is located, for example, C:\MyCompany\MyProduct.
MSBuildProjectFile The complete file name of the project file, including the file name extension, for example, MyApp.proj.
MSBuildProjectExtension The file name extension of the project file, including the period, for example, .proj.
MSBuildProjectFullPath The absolute path and complete file name of the project file, for example, C:\MyCompany\MyProduct\MyApp.proj.
MSBuildProjectName The file name of the project file without the file name extension, for example, MyApp.
MSBuildBinPath The absolute path of the directory where the MSBuild binaries that are currently being used are located, for example, C:\Windows\Microsoft.Net\Framework\v2.0. This property is useful if you need to refer to files in the MSBuild directory.
MSBuildProjectDefaultTargets The complete list of targets specified in the DefaultTargets attribute of the Project element. For example, the following Project element would have an MSBuildDefaultTargets property value of A;B;C.

<Project DefaultTargets=”A;B;C” >

MSBuildExtensionsPath The MSBuild folder under the Program Files directory. This location is a useful place to put custom target files. For example, your targets files could be installed at \Program Files\MSBuild\MyFiles\Northwind.targets and then imported in project files with the following XML.

<Import Project=”$(MSBuildExtensionsPath)\MyFiles\Northwind.targets”/>

MSBuildStartupDirectory The absolute path of the directory where MSBuild is invoked.

This allows you to go to any point in a project tree and build everything below that point without having to create “dirs.proj”-type files in every directory. Instead, you have only a single project, like this example called c:\traversal.proj:


<Project …>












Then at any point in the tree you would type:


msbuild c:\traversal.proj

Exercises for automating build system


  1. Print ‘Hello’
  2. Print ‘Hello <name>’ with <name> is passed as parameter.
  3. Create a target Hello which say “Hello <name>” which name is a property.
    Write a target that 1) define <name> value, then 2) to call target Hello.
  4. Copy1 file from src folder to dest folder.
  5. Copy many files from src folder to dest folder (keeping the hierarchy structure).
  6. (search and replace files by filename)
    Find all files in folder srcDir whose names are all searchFile.txt (recursively), and replace them by a given file named replaceFile.txt. All the replaced files are put in a backup folder named backupDir (keeping the files ‘s hierarchy). If no backup folder is specified, proceed search & replace without back-up.

    (rollback search & replace)
    Find all files in folder backupDir whose names are all searchFile.txt and copy them to the srcDir folder (keeping the heirarchy of the files).

  7. For each file extension in src folder, print the files having that extension.
  8. Copy files from src folder to dest folder. Put the files into sub folders whose name are the file extensions.
    For example, given that in the src folder there are only two extensions .txt and .xml. Then, the files will be copied into txt and xml folders which are sub folder of dest folder.

Learn MSBuild

Get started

MSBuild + tutorial – Tìm với Google -> Is there a good tutorial on MSBuild scripts? – Stack Overflow ->Automating the build with MSBuild – Coding Cockerel

Notes about MSBuild

  1. You can overwrite a global property (property which is a direct child of <project>) only after the target (which containing the overwritting task ) completes its execution. See an example here [MSBuild] Overwrite global property. « Nam Gi VU ‘s Blog .
  2. We can pass input parameter when calling a target by using MSBuild. See an example here [MSBuild] Passing input parameters when calling a Target « Nam Gi VU ‘s Blog.
  3. You cannot have loop directly! You can have “loop” through batching feature.
  4. You can have nested loops using batching (for loop) and <MSBuild … > task (the task named MSBuild). See a sample here [MSBuild] Nested loops in MSBuild « Nam Gi VU ‘s Blog
  5. Normally, @(Item) is translated as a concatenation of the identity metadata of the elements in the item list Item – these values are delimitated by comma ‘,’  .
    We can customize this by @(item->’…%(metaData)…’, ‘delim’ )
  6. When defining the item using ItemGroup, e.g. <itemName Include=”value” />, the itemName is also sometimes called itemType.
  7. Immediate halt the build script using <Error … />.
  8. Use @(item->’%(metaData)’) to access metadata of an item.
  9. Use %(item.metaData) to create loops in MSBuild (called batching).
    Note that it is different between
    looping a task (by passing %(item.metaData) to task’s parameters)
    and looping a target (by passing %(item.metaData) to Output parameter of the target).
  10. Properties are NOT case-sensitive.
  11. (for properties declared right after <Project> level, NOT the ones declared inside <Target>)
    Static properties are ALL loaded before any target is executed no matter where their locations are in the build script (a property may declared at the bottom of the file but still be loaded first).
  12. There are 3 types of expression evaluating in MSBuild: the $(property), the @(item), and the %(item.metaData)
  13. Passing MSBuild properties through command-line using /p:property=value
  14. Targeting Specific .NET Frameworks with MSBuild (setting by the property ToolsVersion of element Project). E.g: <Project Name=”CompileCS” xmlns=”http://schemas&#8230;. ToolsVersion=”3.5″>
    We can set tool-version using commandline property /tv:<version> or /toolsversion:<version>

FALSE knowledge of book “Inside the MS Build Engine using MSBuild …”

  1. Access metadata of an item using @(itemName >’%(innerElement)’)
    -> It mus be @(itemName->‘%(innerElement)’)
  2. Command-line properties can not be overwritten if redefined using CreateProperty.
    -> Should not use CreateProperty, use <PropertyGroup> instead (.Net 3.0)

What is so special about MSBuild over NAnt

1. MSBuild is part of the .NET Framework runtime, so there are no additional dependencies to install. Moreover, since it’s part of .NET Framework, Microsoft will officially develop it in the future – hardly one would support for NAnt as strong as Microsoft for MSBuild!
2. MSBuild is (for 95% of .NET projects) the same technology and process that Visual Studio uses to compile projects. This means that you get the same experience from outside of the IDE as you do from inside.
3. In my experience porting an existing NAnt based build system to MSBuild, the resulting MSBuild script is actually more flexible, simpler to understand, and easier to refactor.

Difference between NAnt vs MSBuild

From Pensieve: Differences between NAnt and MSBuil they said:

1. NAnt has functions. MSBuild really has no such thing. MSBuild is infinately extensible via Tasks, but there aren’t that many tasks as compared with NAnt functions. I think this is a sign of maturity in NAnt. Since MSBuild’s programmers had NAnt to look at, we do have to wonder why they excluded some things but we can guess that dev timelines ran out.

2. NAnt has a few fileset types with specialized attributes. All file references in MSBuild are contained in ItemGroup blocks. However, with ItemMetadata providing infinite extensibility to each Item in an ItemGroup, the specialized attributes are not required.

3. In the main, the NAnt schema tends to be attribute centric, while MSbuild favors elements with text content. The NAnt schema also favors lowercase names, while MSBuild favors an initial capital.

4. NAnt allows fileset groups to be included inside a target. MSBuild Targets may only reference ItemGroups specified as children of the Project element.

5. MSBuild seems to be missing the notion of a basedir. This basedir attribute is very helpful in NAnt. MSBuild only has the project root as basedir, and can use PATH variables. Again, I think the maturity of NAnt shows in this oversite. Obviously, you can define a Property with an appropriate base directory Uri and append it to every path in an ItemGroup. You could probably also make use of ItemMetaData if you were writing a custom Task.

6. Property references in NAnt are denoted by ${}, while MSBuild uses $(). What is this, C# versus VB? You also cannot use ‘.’ characters in your property names in MSBuild, though it is legal in NAnt.

7. MSBuild references Items in an ItemGroup with the syntax @(ItemName). NAnt references filesets by id utilizing a refid attribute without decoration.

8. There are 72 built-in tasks in NAnt. There are 35 in MSBuild, however most of the common tasks related to .net use are in there. They both include an Exec(exec) task for calling out to the system. They both allow you to write your own to extend the functionality of the build. So, if it can be done in code, you can run it from either one.

9. Both allow conditions to be placed on nearly every element to determine if the build should include the enclosing item. However, NAnt uses both an ‘if’ and ‘unless’ approach, where MSBuild just simply has ‘Condition’ that supports ‘!’ (not); ‘And’; and ‘Or’. Here the MSBuild approach seems more streamlined.

10. MSBuild Projects can have multiple default targets, and also has an InitialTarget which can be run before other targets for prepatory steps. Utilizing ‘depends’/’DependsOnTargets’ attributes you could craft your own workflow in either program. Similar to the Default, you can have multiple targets specified in the DependsOnTargets attribute which is an interesting enahancement over NAnt.

11. A subtle difference in the CSC Task is that in NAnt, the warnings to ignore are elements which each have a condition. In MSBuild, warnings are a single attribute which contains a semi-colon delimeted list. In NAnt, you could conditionally ignore some warnings on some builds based on criteria. No such thing would be possible in MSBuild.

the MSBuild.Community.Tasks.xsd can be found in C:\Program Files\MSBuild\MSBuildCommunityTasks

Learn NAnt

In case you don’t get used with NAnt, you may need to read 1) NAnt Help and 2) Building and Deploying Using NAnt – CodeProject which leads to 3) Jean-Paul S. Boodhoo’s Blog – NAnt Starter Series (a detailed tutorial) and 4) NaNT .build file Intellisense (a cool Visual Studio intellisense feature).