Feeds:
Posts
Comments

Archive for the ‘automating software build process’ Category

Exercises:

  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.

Read Full Post »

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

Read Full Post »

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).

Read Full Post »

« Newer Posts