TFS Build Web.config Transformation

With Visual Studio, we are able to create different build configurations with the Configuration Manager. This allows us to create different web.config files for a particular build target like Stage, Prod. The idea behind this is that each target configuration contains the correct application settings for that target environment.

When we build our projects on Visual Studio, we notice that the web.config file is transformed to contain the changes that are needed for the build target. When we use TFS Team Build, this does not happen by default.  An approach that we can take to address this is as follows:

Add a target directive only on the web project definition

For this step, we need to edit the .csproj file and add the following XML entries:

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />

<Target Name="AfterBuild" Condition="'$(IsTFSBuild)' != ''"> 

<Message Text="'Message After Build: TFSBuild Status $(IsTFSBuild) - $(OutDir)\_PublishedWebsites\$(TargetName) '" />

  <TransformXml Condition="Exists('$(OutDir)\_PublishedWebsites\$(TargetName)')"

       Source="Web.config"

       Transform="Web.$(Configuration).config"

       Destination="$(OutDir)\_PublishedWebsites\$(TargetName)\Web.config"

/>

Element Name	Description
UsingTask	This element allows the MSBuild process to know in what assembly to find the TrasnformXml task. We need to note that the path is the one on the Build Server not a personal work station.
Target	The target is the action that runs the transformation process. We want this to be done AfterBuild has completed, and we only want this done when the IsTFSBuild argument is not empty. We add this argument to the TFS build definition.
Message	The message element helps us make a log entry, so that we can validate if this action is getting executed.
TransformXml	With this directive, we are executing a transformation task and merging the web.config file with another config file that is associated to the build target. For example for a release build, the $(Configuration) is set to “Release”. The result is merged and copied on the _publishedWebsites folder

*Note this can also be done as part of the build definition, but web.config is only applicable to web projects.

Save your file and unit test the change using the MSBuild application from the Visual Studio command shell. The command should look like this:

msbuild webproject.csproj /p:Configuration=Release /p:IsTFSBuild=True > out.log

On our desktop the OutDir is set to the Bin folder, so we can change the folder paths to read like this:

<TransformXml Condition="Exists('$(OutDir')"

       Source="Web.config"

       Transform Web.$(Configuration).config "

       Destination="$(OutDir)\Web.config"

/>

A merged web.config file should be copied to the Bin folder. Make sure to not include two target elements with the same name (AfterBuild). The last element always override the one that was declared before it.

Add a MSBuild Argument to the build definition

Now that the project file has been checked-in, we can test this on Team Build. First we need to add the IsTFSBuild argument to the build definition. This is done on Visual Studio. Add the parameter in the MSBuild Argument textbox as shown below:

Now, we can queue a build and take a look at the _PublishedWebSites folder. The web.config file should be merged with the configuration from the build target.  In case this did not happen, we can look at the build log file. We can look for the AfterBuild tag and find the message that was added to the project file. If this is not visible in the log file, we need to make sure that there are no typos on the changes and arguments that we are using.

Key Benefits

This process is a key component for the delivery a build and deployment automation process.

Management of configuration files for multiple environments.

With Visual Studio, we are able to create different build configurations with the Configuration Manager. This allows us to create different...

Read Article →

Request a code review with Visual Studio 2012 Premium

Before any code is check-in, a developer can request a code review using Visual Studio. The steps for a code review request and response are as follows:

Send a review request:  (developer)

Do not check-in your code

• On Team Explorer Home, click on Request Code Review

o   Enter the name of the reviewer

o   Enter the following information

§  Task name

§  Area Path

§  Description about the change (Same as you would use for a check-in)

o   Click on Submit request

This creates a Code review request task and a shelve-set which is used by the reviewer to look at the code changes.

Suspend work while waiting on response (developer)

While waiting for a code review response, the developer can suspend the ongoing work and move on to another task. This can be done as follows:

• On Team Explorer Home In progress work items & changes

o   Select Suspend & Shelve

o   Press Suspend

This creates a shelve-set and the developer can move on to a different task. Once the review is complete, the developer will be able to select the suspended work and resume work based on the feedback from the reviewer.

Response to a review request: (reviewer)

• On Team Explorer Home, My Work

o   Click on  Code Reviews and  Requests

o   Open the pending reviews

This shows all the files that have been modified. The reviewer can now do the following:

• Do a code compare with the previous version
• Add comments in the areas where a change was made
• Set the status of the review request according to the comments
• Press Send and Finish

This closes the review request task and creates another code review response task for the developer to read the comments and resume work.

Only after the code review has passed, the developer should be able to check-in the code and update the task status. 

Before any code is check-in, a developer can request a code review using Visual Studio. The steps for a code review request and response ar...

Read Article →

TFS – How to Record Support Hours on an Iteration

In project management, there is always a need to record how much work is being done to troubleshoot and/or identify issues for a particular release.  To address this, we could set up a team project with the following settings:

Area and Iteration Path:
Create an area path specifically for support issues. For example, the area path could read the following:

Area Path	Description
Support\Stage	Use this for the staging environment
Support\Production	Use this for the production environment

This allows us to track supporting tasks done in either the staging or production environment.

The iteration path should be set to your software iteration. For example, if in stage you are running version 2.13.0, and you need to create a support task to troubleshoot something in stage. You set the area path to stage and the iteration to version 2.13.0. The same can be applied when a task needs to be created on a production release. This allows us to track the number of tasks in each environment and for each release/iteration

Task Detail:

When you create a task, the task should be created with this additional information:

Property	Value	Description
Discipline	Analysis	This depends on the template you are using on TFS. You may create another entry that reads Support.
Type	Corrective or Mitigation	On stage you may use Corrective to correct problems before production. On production , you can use Mitigation because you need to minimize the impact of the problem
(Details tab)  Schedule Estimate	hours	The estimated hours
(Details tab)  Schedule Remaining work	hours	The work still remaining. This is important to update because a tasks may not be completed the same day, but you need to report the number of hours left.
(Details tab)  Completed  work	hours	The hours completed in the tasks

 It is important to add the completed work and remaining work to the correct Area and iteration path. This would be the only way that the reports can accurately show how much support effort is being done and in what iteration. This can lead to a better understanding of the development process and identify possible issues.

I hope this is useful.

og-bit.com

In project management, there is always a need to record how much work is being done to troubleshoot and/or identify issues for a particular ...

Read Article →

Resolve MSB4064: The "Retries" parameter is not supported by the "Copy" task – Team Build

When building Visual Studio 2010 projects on TFS 2008, you may get this error:

MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets(132,11): error MSB4064: The "Retries" parameter is not supported by the "Copy" task. Verify the parameter exists on the task, and it is a settable public instance property.

MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets(130,5): error MSB4063: The "Copy" task could not be initialized with its input parameters.

The item to notice is that Visual Studio 2010 projects by default use the MSBuild V10.0 targets, and the target definitions are updated for TFS 2010 build projects not TFS 2008. A simple way to address this is to add a condition on the project file to use the Visual Studio 2008 build targets instead when the build is not done with Visual Studio. This is done by editing the Visual Studio project file and updating the following entry:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

To the following:

<Import Condition="'$(IsDesktopBuild)' == 'true'" Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

<Import Condition="'$(IsDesktopBuild)' == 'false'" Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />

The IsDesktopBuild variable is true when the build is done on Visual Studio. When is false, it is a build done over the command line. For this case, we tell the project to use the v9.0 targets instead.

After making this change, you may now be getting this error:

error MSB4131: The "Reason" parameter is not supported by the "GetBuildProperties" task. Verify the parameter exists on the task, and it is a gettable public instance property.

You can add a property to the SolutionToBuild node as follows:( modify the MSBuild project file):

<SolutionToBuild Include=...>
<Properties>ProjectToolsVersion=3.5</Properties>
<Targets></Targets>
</SolutionToBuild>

I hope it helps

CodeProject
og-bit.com

When building Visual Studio 2010 projects on TFS 2008, you may get this error: MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Micros...

Read Article →

Customize the Build Number in Team Build

If you have used TFS team build, you know that MSBuild creates a default label and build number/name with the following format:

Build Definition Name_YYYYMMDD_#

Where the # is an incremental number for the date. This format does not really provide any information about the version your are building. Nevertheless,  The build number can be customized using the BuildNumberOverrideTarget. There are different approaches to achieve this.  In this instance, we will take a very simple approach that allow us to add the current product version to the build number without having to use a custom task which requires the deployment of a assembly on the build machine. The one item to always keep in mind is that the build number must be unique.

Open your TFs build project  and add the following property group:

<PropertyGroup>

    <VersionMajor>1</VersionMajor>

    <VersionMinor>0</VersionMinor>

    <VersionService>0</VersionService>

    <VersionBuild>1</VersionBuild>

</PropertyGroup>

We just added a group of variables that indicate that the product we want to build has this version 1.0.0.1. You can change this to match your standard and your product version.  Now add the target override as follows:

<Target Name="BuildNumberOverrideTarget">

<Message Text="Build number before [$(BuildNumber)]" />

<PropertyGroup>

<BuildNumber>$(BuildNumber) [$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)]</BuildNumber>

</PropertyGroup>

<Message Text="Build number after [$(BuildNumber)]" />

</Target>

With this override, we are basically indicating that we want to append our version number to the TFS build number. We decided to keep the TFS build number  to continue to provide a unique label/number to the build. The messages in the override log the build number before and after the change.  If you check in your changes and queue a build, you will see that the build number has changed to this new format:

Build Definition Name_YYYYMMDD_# [MAJOR.MINOR.SERVICE.BUILD]

You will now be able to easily see the version associated to the  build. When you are ready to build a new version, you will need to modify the property group.  You should also know that if you try to build during the same day, you will probably get a non-unique build number error. This is because the build number that was generated was replaced by our custom build number, and the build process uses the "Build Definition Name_YYYYMMDD_#+1" to increment the build for the same date. To address this, you can add a parameter and append it to the build number as follows:

The build label parameter should be added to the MSBuild command-line arguments as follows:

/p:BuildLabel=001
The custom build task should address this limitation, but this is part of a different blog entry.

I hope this is helpful.

<Target Name="BuildNumberOverrideTarget">

<Message Text="Build number before [$(BuildNumber)]" />

<PropertyGroup>

<BuildNumber>$(BuildNumber)$(BuildLabel) [$(VersionMajor).$(VersionMinor).$(VersionService).$(VersionBuild)]</BuildNumber>

</PropertyGroup>

<Message Text="Build number after [$(BuildNumber)]" />

</Target>

CodeProject
og-bit.com

If you have used TFS team build, you know that MSBuild creates a default label and build number/name with the following format: Build Def...

Read Article →

How to Deploy Files in Different Servers with Team Build

I use Team Build to automate the build and deployment of my projects.  In the build project, there are settings that allow us to configure the build directory and drop location of the files. The build directory is a path in the build machine, and this does not really change. The drop location is a path where you want the files to be copied after a successful build.  Depending on your development environment, you may want these files to be copied to different servers. For example, there may be a development, staging and production location.  For our process, we keep  a copy of the build in the drop location, and from this location , we copy to the other servers. This allows us to recover previous builds.

Team Build uses MSBuild to perform the build process. MSBuild allows us to pass input parameters which can be used to run a conditional statement and determine the drop location dynamically. When I queue a new build, I add a parameter in the MSBuild command-line arguments (See Queue New Build under TFS Explorer). This parameter has this format:

/p:DeployTo=develop   (/p = command switch)

The parameter name and value is just a key/value pair which you can reference in the build script much like you would use parameters in a XSLT file.  The /p is a MSBuild command switch that denotes properties.  The TFS build project file is actually a XSLT file, so we can leverage the use of the Choose conditional statement to determine where to copy the files.  

<Choose>  

    <When Condition=" '$(DeployTo)'=='stage' ">

      <PropertyGroup>

        <DeployPath>\\stageServer\drop</DeployPath>

      </PropertyGroup>

    </When>

    <When Condition=" '$(DeployTo)'=='production' ">

      <PropertyGroup>

        <DeployPath>\\prodServer\drop</DeployPath>

      </PropertyGroup>

    </When>

    <Otherwise>

      <PropertyGroup>

        <DeployPath>\\devServer\drop</DeployPath>

      </PropertyGroup>

    </Otherwise>

  </Choose>

This script basically checks the value of the parameter DeployTo and creates a variable named DeployPath. If no parameter is provided, it defaults to the development environment. You can also add additional variables which you can use to set other properties like build quality. Do make sure to replace the path with something relevant to your environment. We can now create a Target (group of tasks) and determine where to copy the files.

<Target Name="AfterDropBuild" >

<Message Text="Copying Files to: $(DeployPath)" ></Message>

<!--Define New Deployment Files To Be Copied  USE **\* to get all subfolders-->

<ItemGroup>           

   <Content Include="$(DropLocation)\$(BuildNumber)\Release\myproduct\**\*"

</ItemGroup> 

 <!--Task: Copy all the files and subfolders to the path defined by DeployPath-->

 <Copy SourceFiles="@(Content)" DestinationFolder="$(DeployPath)\%(RecursiveDir)"       ContinueOnError="false"></Copy>

 </Target>

We can now check-in the project file and queue a new build. After the build is successful, we can take a look at the folders in the other server and validate that the files were copied successfully.  If the files are not in the new location, take a look at the build log (drop location folder) and look for the"Copying Files To:" message that we added in the new target. The message should displayed the path that was selected. This is an approach to troubleshoot and see what is taking place with the build script.

Thanks for reading.

CodeProject
og-bit.com

I use Team Build to automate the build and deployment of my projects.   In the build project, there are settings that allow us to configure ...

Read Article →