- | rssFeed | My book on MSBuild and Team Build | Archives and Categories Thursday, May 09, 2013

Book published and now in stock!

I’m happy to say that my Supplement to Inside the Microsoft Build Engine book (co-author William Bartholomew) has now been published. In fact it’s already in stock and ready to be shipped by Amazon.com.

This book is a small addition (118 pages) to the previous book, Inside the Microsoft Build Engine 2nd edition. It has a small price too, MSRP is $12.99 but it’s selling on Amazon.com for $8.99! In this book we cover the updates to MSBuild, Team Build and Web Publishing in Visual Studio 2012. The foreword was written by Scott Hanselman, and you can read the entire foreword online.

Check out how thin the supplement is in comparison to the 2nd edition #ThinIsIn.

945231_10103483509401051_968543011_n

 

If you already own the 2nd edition then you’ll love this update.

 

Table of Contents

Chapter 1: What's new in MSBuild

  1. Visual Studio project compatibility between 2010 and 2012
  2. Out of Process Tasks
  3. NuGet
  4. XML Updates with SlowCheetah
  5. Cookbook
Chapter 2: What's new in Team Build 2012
  1. Installation
  2. Team Foundation Service
  3. User interface (UI) enhancements
  4. Visual Studio Test Runner
  5. Pausing build definitions
  6. Batching
  7. Logging
  8. Windows Workflow Foundation 4.5
  9. Cookbook
Chapter 3: What's new in Web Publishing
  1. Overview of the new Publish Web Dialog
  2. Building web packages
  3. Publish profiles
  4. Database publishing support
  5. Profile-specific web.config transforms
  6. Cookbook

 

The book has been available in e-book form for a few weeks. Just long enough for us to get our first review. It was 5 stars :).

image

 

Please let us know what you think of this book!

 

You can download all the samples and learn more at msbuildbook.com.

 

Sayed Ibrahim Hashimi | http://msbuildbook.com | @SayedIHashimi

msbuild | MSDeploy | Team Build | web | Web Publishing Pipeline Thursday, May 09, 2013 6:33:20 AM (GMT Daylight Time, UTC+01:00)  #     | 
Tuesday, July 07, 2009

Free MSBuild / Team Build Training

I am now offering FREE MSBuild training / Team Build training. Here is the deal. For those who do not know me I am the lead author for Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build, co-author for Deploying .NET Applications: Learning MSBuild and ClickOnce and have written several related articles.

I am beginning a new program where I will personally come out to your site and provide your team (from as little as 1 or as many as 10) 8 hours of free MSBuild / Team Build training. Here are the conditions; the training will be performed on a Saturday and you will have to cover the cost of airfare, hotel and meals for the weekend. You will also need to purchase X number of copies of my book where X is the number of people being trained. The book will be used throughout the session. Also you would have to provide the facilities where the training would take place. This will be a personalized training session. Ahead of time you tell me what topics you want to be trained on, I will create the specific training materials and then train you on that. If your team is 100% new to MSBuild I can save them countless hours of learning and pain on their own. If you already have a knowledgeable group then I can take them to the next level by covering advanced topics and best practices. I want to be clear on this, you will not be paying me any fee for the training and I will personally be delivering the training.

I am making a very limited number of slots available for this extremely rare special training, so if you are interested you should contact me very soon, because this will not be available for long. Send me an email [sayed DOT hashimi AT gmail DOT com] stating a bit about your organization, where the training would take place, what weekends are good (at least 4), how many people you want to be trained, and the specific topics that you would like to cover.

Looking forward to hearing from you guys!

Sayed Ibrahim Hashimi

msbuild | Team Build | training Tuesday, July 07, 2009 4:49:08 AM (GMT Daylight Time, UTC+01:00)  #     | 
Saturday, January 17, 2009

Inside the Microsoft Build Engine: Published and In stock!

My new book Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build has been published and is now in stock at amazon.com. This book contains 12 chapters, 9 of which are dedicated to MSBuild and the remaining three are Team Build. Two of the MSBuild chapters are dedicated to examples in a cook book fashion, there is one such chapter for the Team Build. This book is the only book that contains this type of coverage of MSBuild. From the begining of the book the MSBuild team was involved, they reviewed every MSBuild chapter and provided invaluable insight. Here is the table of contents for the book:
Chapter 1 : MSBuild Quick Start
Chapter 2 : MSBuild Deep Dive, Part 1
Chapter 3 : MSBuild Deep Dive, Part 2
Chapter 4 : Custom Tasks
Chapter 5 : Custom Loggers
Chapter 6 : Batching and Incremental Builds
Chapter 7 : External Tools
Chapter 8 : Practical Applications, Part 1
Chapter 9 : Practical Applications, Part 2
Chapter 10 : Team Build Quick Start
Chapter 11 : Team Build Deep Dive
Chapter 12 : Team Build Cookbook
App A : New Features in M Build 3.5
App B : MSBuild Common Properties and Items
App C : New Features in Visual Studio Team System 2010 Team Build

If you are interested in learning MSBuild from scratch, or looking to become a MSBuild expert then this book will help you. If you do get a copy please post a review on amazon.com.

Sayed Ibrahim Hashimi
msbuild | Team Build Saturday, January 17, 2009 4:05:26 AM (GMT Standard Time, UTC+00:00)  #     | 
Monday, November 10, 2008

Team Build - Creating Delta Builds

Out of the box Team Build does not support Delta Builds. Thomas Janssen has a detailed post Realizing Delta Builds with VSTS Team Build for Delta Deployments which describes how this can be achieved. I have not had the opportunity to try this myself, but the blog post looks very through and informative. You can also download his DeltaBuild.targets file from his blog. I have the following comments relating to this; perhaps he will upgrade this file to reflect these comments.

This guidance is appropriate for target files which are designed to be consumed by others.

Don't override targets like AfterCompileSolution

Don't override targets like AfterCompileSolution. Instead extend the CompileSolutionDependsOn property in the manner:

<PropertyGroup>

<CompileSolutionDependsOn>

$(CompileSolutionDependsOn);

DeltaAfterCompileSolution

</CompileSolutionDependsOn>

</PropertyGroup>

This is because some consumers of this file may have already defined the AfterCompileSolution target. In which case one of them will be overridden.

Notice that I named the new target DeltaAfterCompileSolution. It is a best practice to prefix your targets with a value that should be unique. This will minimize the chances of your targets colliding with those defined by others. For example this could have been named MyAfterCompileSolution, but I bet there are a bunch of these already defined.

DependsOnTargets should always be taken from a property

You should define the DependsOnTargets value inside of a property, just like the MSFT targets files do. For example your DeltaAfterCompileSolution (after being renamed) would look like this:

<PropertyGroup>

<DeltaAfterCompileSolution>

$(DeltaAfterCompileSolution);

SafeCleanBuildResult;

GetLatestVersion;

CollectIncrementalBuildResult;

CreateDeltaBuildResult

</DeltaAfterCompileSolution>

</PropertyGroup>

<Target Name="DeltaAfterCompileSolution"

DependsOnTargets="$(DeltaAfterCompileSolution)">

</Target>

This is because you want users to be able to extend this process similar to how users extend the built-in build process. Without this they may need to modify your file, which is ill-advised because you may make a new release at some point.
Also notice the usage of the $(DeltaAfterCompileSolution) in the declaration of the DeltaAfterCompileSolution property. This is to
preserve any previous values that the user may have defined.

 

On a side note, if you are looking for more detailed information regarding Team Build, there will be three chapters of my new book Inside the Microsoft® Build Engine: Mastering MSBuild and Team Build which will be published in January 2009. Sample chapters will be available at that link shortly.

Thanks,

Sayed Ibrahim Hashimi

Team Build | Team Build | Visual Studio 2008 Monday, November 10, 2008 4:43:46 AM (GMT Standard Time, UTC+00:00)  #     | 

Team Build - Creating Delta Builds

Out of the box Team Build does not support Delta Builds. Thomas Janssen has a detailed post Realizing Delta Builds with VSTS Team Build for Delta Deployments which describes how this can be achieved. I have not had the opportunity to try this myself, but the blog post looks very through and informative. You can also download his DeltaBuild.targets file from his blog. I have the following comments relating to this; perhaps he will upgrade this file to reflect these comments.

This guidance is appropriate for target files which are designed to be consumed by others.

Don't override targets like AfterCompileSolution

Don't override targets like AfterCompileSolution. Instead extend the CompileSolutionDependsOn property in the manner:

<PropertyGroup>

<CompileSolutionDependsOn>

$(CompileSolutionDependsOn);

DeltaAfterCompileSolution

</CompileSolutionDependsOn>

</PropertyGroup>

This is because some consumers of this file may have already defined the AfterCompileSolution target. In which case one of them will be overridden.

Notice that I named the new target DeltaAfterCompileSolution. It is a best practice to prefix your targets with a value that should be unique. This will minimize the chances of your targets colliding with those defined by others. For example this could have been named MyAfterCompileSolution, but I bet there are a bunch of these already defined.

DependsOnTargets should always be taken from a property

You should define the DependsOnTargets value inside of a property, just like the MSFT targets files do. For example your DeltaAfterCompileSolution (after being renamed) would look like this:

<PropertyGroup>

<DeltaAfterCompileSolution>

$(DeltaAfterCompileSolution);

SafeCleanBuildResult;

GetLatestVersion;

CollectIncrementalBuildResult;

CreateDeltaBuildResult

</DeltaAfterCompileSolution>

</PropertyGroup>

<Target Name="DeltaAfterCompileSolution"

DependsOnTargets="$(DeltaAfterCompileSolution)">

</Target>

This is because you want users to be able to extend this process similar to how users extend the built-in build process. Without this they may need to modify your file, which is ill-advised because you may make a new release at some point.
Also notice the usage of the $(DeltaAfterCompileSolution) in the declaration of the DeltaAfterCompileSolution property. This is to
preserve any previous values that the user may have defined.

 

On a side note, if you are looking for more detailed information regarding Team Build, there will be three chapters of my new book Inside the Microsoft® Build Engine: Mastering MSBuild and Team Build which will be published in January 2009. Sample chapters will be available at that link shortly.

Thanks,

Sayed Ibrahim Hashimi

Team Build | Team Build | Visual Studio 2008 Monday, November 10, 2008 4:43:46 AM (GMT Standard Time, UTC+00:00)  #     | 
Friday, June 27, 2008

MSBuild Conditions on Targets

This post is related to my  previous post MSBuild RE: Enforcing the Build Agent in a Team Build which is a response on the post by Michael Ruminer at http://manicprogrammer.com/cs/blogs/michaelruminer/archive/2008/06/19/enforcing-the-build-agent-in-a-team-build.aspx.

Basically every MSBuild element can contain a Condtions attribute. You can read more at MSBuild Conditions. So even targets can have conditions attached to them! Despite the fact that you can do this, you should not. I recommend that you do not use conditions on targets. Conditions on targets seem straight forward but after you take a closer look they are more complicated. We can take a look at some of the items that come to mind here.

Conditions on targets and DependsOnTargets don’t play well

Take a look at this simple project file

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="2.0"
         xmlns="
http://schemas.microsoft.com/developer/msbuild/2003"
         DefaultTargets="Demo">

  <PropertyGroup>
    <AllowTarget>true</AllowTarget>
  </PropertyGroup>

  <Target Name="SupressTarget">
    <CreateProperty Value="false">
      <Output PropertyName="AllowTarget" TaskParameter="Value"/>
    </CreateProperty>
    <Message Text=" ==== SupressTarget ==== " Importance="high"/>
    <Message Text="AllowTarget: $(AllowTarget)"/>
  </Target>
 
 
  <Target Name="Demo" Condition="'$(AllowTarget)'=='true'"
          DependsOnTargets="SupressTarget">
    <Message Text=" ===== Demo ===== " Importance="high" />

    <Message Text="AllowTarget: $(AllowTarget)"/>
  </Target>
 
</Project>

In this project the main target is Demo and it depends on a target SupressTarget which actually disables the Demo target based on its condition. If you execute the command msbuild /t:Demo you get the results shown below.

Most users would expect that the target SupressTarget target would execute which sets the AllowTarget value to false, and then the Demo target is skipped. But what is happening here is that by the time DependsOnTargets is evaluated the condition has already been evaluated and has passed! The even more interesting thing here is if you execute msbuild /t:SupressTarget;Demo the results are shown below.

 

So this time it was skipped, because SupressTarget was called before the Demo target was invoked so the condition evaluated to false.

 

Conditions and target batching doesn’t work well either

If you are batching a target and you want to execute the target for some batches but not others, this cannot be achieved with target conditions, for a few reasons but the simplest is: Either a target is or is not defined. When the target is going to be executed for the first time the condition is evaluated. If the condition is true it will exist, otherwise it will not.

I thought of some other issues but they are not coming to me at this time, but I think this is enough to deter you from using target dependencies. Instead of target dependencies you should take a look at other way of achieving the same results.

 

Sayed Ibrahim Hashimi

msbuild | Team Build | TFS Friday, June 27, 2008 7:28:35 AM (GMT Daylight Time, UTC+01:00)  #     | 
Wednesday, April 05, 2006

Team Build + MSBuild Properties

If you are using Team Foundation Server as your SCM tool, I hope you're taking advantage of using the Team Build tool to create re-producable public builds for your projects. Very cool, and very useful, especially for those Enterprise applications. As you use Team Build you'll need to make changes to how your build process is executed. You can make the customizations in the TFSBuild.proj file. This is the file that will drive your team build. In this file there are many properties declared that are generated by the New Build Type Creation Wizard. These properties are contained in the first PropertyGroup element in that file. Some of these properties include; Description, DropLocation,BuildDirectoryPath,... which are used internally by Team Build to setup the build. Of course Team Build uses MSBuild to actually execute the build, but some things need to happen before/after MSBuild gets involved. For instance creating the Build report, which require those values. In the ideal world you'd expect for those values to be gathered using the MSBuild Object Model, but this is not the case. Team Build is extracting those values as they are declared.
There has been a few posts about this particular problem on the MSBuild MSDN Forum. Those posts are at:
Post: Property Evaluation Order (beta 3)
Properties in properties
In the post Property Evaluation Order (beta 3) I provide a workaround for most situations, but its not always perfect. Here it is for you to see:

It seems like Team build is not using the msbuild object model to get those evaluated properties, but instead are simply extracting the text value from those property declarations.

I tried to overwirte it in different places in the project file as well, with no luck. It always took the first declaration. I'm guessing that the property is not able to be overwritten because it is passed in as a command line parameter to msbuild.exe by team build. But there is a workaround that solves some of the issues. In your TFSBuild.proj file, modify the DropLocation to one that doesn't use any properties and insert the following towards the bottom:

  <PropertyGroup>

    <RootProjectFolder>ProjectX</RootProjectFolder>

 

    <DropBuildDependsOn>

      FixDropLocation;

      $(DropBuildDependsOn);

    </DropBuildDependsOn>

  </PropertyGroup>

 

  <Target Name="FixDropLocation">

    <CreateProperty Value="$(DropLocation)\$(RootProjectFolder)">

      <Output TaskParameter="Value" PropertyName="DropLocation"/>

    </CreateProperty>

    <Message Text="Drop loc: $(DropLocation)" Importance="high"/>

  </Target>

This prepends the FixDropLocation to the DropBuildDependsOn list of targets, so it will be executed before the DropBuild target. This cause your project drop files to be dropped in the location tat you want. This is able to overwrite the DropLocation property becuase we are using the CreateProperty task to overwrite this instead of the normal property declaration.

This is not however a perfect solution, because your build log will always be located in the DropLocation that was originally declared (the one w/o the property embedded within it). And in the Team build type history the drop location will also have this location as well. But it does place the files where you want them :)

Unfortunately it looks like the DropLocation that is given to TFS is happening outside the scope of MSBuild so I'm not sure you have a lot of options. You can't even pass this as a command line parameter to the tfsbuild.exe utility either. Let me know if this  is not clear.


Sayed Ibrahim Hashimi


msbuild | Team Build | TFS | Visual Studio Wednesday, April 05, 2006 8:09:52 AM (GMT Daylight Time, UTC+01:00)  #     | 
Sunday, January 01, 2006

TFS Build Error

Lately I've been using Team Foundation Server (TFS) for my source control and Team Build to perfom builds on a dedicated machine. Everything was working pretty good until the other night, I created a new team project and added some projects to the source control. Following this I created a new Team Build and tried to execute it, but I received an error, TF42053: The build machine is not configured to build for server..." I received this error when I tried to invoke Team Builds that were previously building correctly as well, not just on the new project. The image of the dialog box is shown below (click for larget image).

As instructed I opened up the TFSBuildService.exe config file which is at %Program Files%/Microsoft Visual Studio 8/Common7/IDE/PrivateAssemblies/TFSBuildService.exe.config, I opened up that file and located the AllowedTeamServer key element. Originally it looked like:

<add key="AllowedTeamServer" value="" />

By the way my TFS setup is on a single tier, so the application and data tier are both on the same machine, and that is also the machine that I was trying to run the build on. So I changed the value to:

<add key="AllowedTeamServer" value="MACHINE_NAME"/>

Then I restarted the service and invoked the team build again, and all was fine. I'm not sure why I was able to build previously but not now. The only things I can think of a few changes to the envrionment:
  1) a minor hardware change (I disconnected a removable hard drive from that machine)
  2) the IP address of that machine changed
  3) machine was restarted a few times
  4) new team project with its source control
So I'm not quite sure why I received this error, but I'm glad it was an easy fix. Now I can continue working on my project.

Sayed Ibrahim Hashimi

Team Build | TFS | Visual Studio Sunday, January 01, 2006 6:03:08 PM (GMT Standard Time, UTC+00:00)  #     |