extending the build workflow of tfs 2010

Tfs 2010 Build – Extend the base build

Ricci Gian Maria

[email protected]://blogs.ugidotnet.org/rgmhttp://www.codewrecks.com

mailto:[email protected]

http://blogs.ugidotnet.org/rgm

Do your systems talk business? | 2

Use an MsBuild Activity to launch a MsBuild project

MsBuild Activity


MsBuild Activity Use a MSBuild Activity to call MSBuild wrapper

around a Custom MsBuild task

Create a simple msbuild project to call the MsBuildTask

Arguments are passed as properties to the MsBuild project that in turns pass them to an MsBuild Task

Insert a MsBuild Activity in the workflow, process and configure it


MsBuild Activity Use a MSBuild Activity to call MSBuild wrapper

around a MsBuild task

• Simple• Usable by people that knows MsBuild• Can reuse existing MsBuild tasks• No knowledge of Workflow foundation required• Reusable for TFS 2008

Pro

• Difficult to deal with output properties• Limited debugging experience• Cannot access the Workflow Runtime that is running the

build

Cons


MsBuild script is inserted in a subdirectory of the source control path of the project. It is a simple MsBuildFile.


The project file is a simple msbuild file, it can contain standard msbuild tasks, or custom tasks.

All custom tasks are included in the source control system and can be referenced by relative path.


Locate the point in the workflow where you want to execute the custom msbuild project, and drop an MsBuild Activity.


The most important property is the Project that contains the path to the custom MsBuild project file that needs to be executed


To pass parameter to custom action, you need to use the /property switch of MsBuild command line, all properties needed by tasks inside the MsBuild file should be passed this way.


Configure the rest of the MsBuild action, specify logFileDropLocation to specify where the logfile needs to be located, specify Targets to build, and give a UserFriendly display name to the action.


At the end of the build, the log is present in the same directory of the main MsBuild log file. In the log file you can see all the output of the custom task, in this example you can see the xml answer of twitter service.


MsBuild Activity to interact with projects

Using MsBuild activity is not only useful to run CustomTasks

MsBuild is the engine used to compile projects You can use MsBuild to deploy a project with

ClickOnce or to deploy a database project MsBuild can be run easily from command line.


Deploy a database project Locate the point where you want the deploy to take place, I placed after test run, and I deploy only if the compilation phase and test phase are both good.

The CovertWorkspaceItem permits me to specify the database project using a source control path, that will beconverted in local path.

I also created a dbProject variable used to store the output of the ConvertWorkspaceItem


To deploy a database you need to specify target Deploy, do not forget to specify a logFile to verify the outcome of the task. All the options should be specified with CommandLineArguments

"/p:TargetDatabase=NorthwindTest" + " /p:""DefaultDataPath=C:Program FilesMicrosoft SQL ServerMSSQL10.SQL2008MSSQLDATA""" + " /p:""TargetConnectionString=Data Source=10.0.0.99\SQL2008,49400%3Buser=sa%3Bpwd=Pa$$w0rd""" + " /p:DeployToDatabase=true"


As for custom MsBuild task, during the build the output file is the best way to understand what is happened during the build.


Create a Custom Code Activity

Custom Activity


Custom Activity Write a custom Workflow Activity

Create a new Code Workflow Activity

Implement all the logic inside the activity

Drop into the build workflow


Custom Activity Write a custom Workflow Activity

• Full integrated with workflow runtime• Simple Drag And Drop experience• Improved debugging and testability• Useful if you do not already have a MsBuild custom

task ready

Pro

• Require to code everything or to convert the MsBuild custom action code into an activity

• Need to know Workflow Foundation• Does not work with MsBuild and TFS 2008

Cons


The assemblies with your Custom Activities should be located in a specific path of the Source Control System.

You have only one location where to store your customization, but this is usually a good practice.


Create a custom Code Activity that does the task.


Custom activity inherits from CodeActivity, it has a couple of attributes to be used inside the build workflow, and declares all Input properties using InArgument<string> class.


Include a custom action in a workflow Create a project with the Custom Action Include a test project where you load the build

workflow (I usually create a branch of the file) Now you are able to drop the Custom Activity

inside the workflow

Alternatively you can simply edit the workflow file with an XML Editor


When you include the workflow inside a project, contained in the same solution that contains also your Custom Activity, you are able to insert the custom activity inside the workflow.


You cannot open anymore the xaml workflow, in the original BuildProcessTemplate folder. You can still edit it with an XML Editor.


Thanks to custom activity you have a better design experience, all input parameters are passed in a clear and coincise manner, you don’t need to use MsBuild command line /parameter option


Logging inside a Custom Activity Since the build is not run interactively, a good log

is the best option to understand what is gone wrong in case of an error.

Log as much information as you can, to help people identify the real cause of the failure.

Use log level with great care, so you can choose from the main workflow the verbosity of the action during the build.


With this simple method you can add a log message in the build output.

The BuildMessageImportance identify the importance of the log, it can have three value: High, Low, and Normal.


You can choose the BuildVerbosity from the Arguments of the build, with this option you can decide wich level of Logs will flow into the build log.

If you use this parameter with care, you can avoid to clutter build output with unuseful messages, but you can raise the verbosity in case of an error, to better understand what is gone wrong.


In the build log detail, each action automatically logs its name when it is executed.

If the action create a log with the aforementioned method, the message is inserted after the action, the indentation helps to understand the action the message belongs to.


Different type of log You can log not only simple messages but also

warning and errors Both of them are inserted with the

BuildInformationRecord class but they are different from a simple lot


A warning is reported in the Build Summary, inside Other Errors and Warnings section

They are more important than log messages, and they should be used to communicate messages that needs immediate user attenction


Log Messages, even with High BuildMessageImportance, are always showed like normal messages.

Warnings have a warning icon that differentiates them from standard messages even in the detailed build


When you issue a BuildError, the entire build is considered in Partially Failed State.

The error is showed in the View Summary as well in the View Log, with a red icon to identify a real error that is happened during the build.


Create a Custom Code Activity that internally uses a Custom Task

Custom Activity that wraps a Custom Task


Wrap MsBuild task in Custom Activity

Wrap MsBuild custom task in a custom Workflow Activity

Create a custom workflow activity with the same properties of the msbuild task

Inside the activity instantiate a copy of the msbuild tasks and populate its properties

Call Execute on MsBuild tasks


Wrap MsBuild task in Custom Activity Wrap MsBuild custom task in a custom Workflow

Activity

• Can use output properties• Makes easier to use complex properties• Better debugging and testability• Can access workflow runtime• MsBuild task can be still used in TFS 2008

Pro

• Need to code the wrapper• Need to setup some infrastructure to make the MsBuild task

believe that it is running inside MsBuild• Need to know WorkflowFoundation

Cons


This is an example of a Custom MsBuild Task that reduces the size of an Url with TinyUrl service.

We have a couple of problems here. The first one is how to grab the value of the output property TinedUrl and pass it back to workflow environment; the other one is how to “fool” the CustomTask that he is running inside a MsBuild environment.

Another important aspect, is how to include log messages issued by the Custom Task inside the build log, and not in a txt file in drop folder


A CustomTask interact with the MsBuild environment through an interface called IBuildEngine.

In the previous code, the call to Log.LogMessage flow into a concrete implementation of IBuildEngine.

The trick to intercept log messages is to build a custom implementation of IBuildEngine

IBuildEngine

CustomTask

Custom Activity

CustomTask

WorkflowBuildEngine

Property

Logs


The WorkflowBuildEngine class implements IBuildEngine and contains a CodeActivityContext that is used to interact with the workflow

Log functions are implemented with a simple call to Utility function seen before. With this trick all call to Log inside the Custom Activity will flow into the workflow log.


This activity inherits from CodeActivity<T> where the type argument indicates the return value

Inside the activity I create an instance of the Custom Task, populate all input properties, as well as the BuildEngine property.

Then I call the execute method and if it returns false (the custom task encounter errors during execution) I log an error, and finally I returned the value of the output property of the Custom Task


You get a better design experience, property are populated through the designer.

You can assign the value of result property to a property of the Workflow, you are able to grab output properties of Custom Msbuild Task.

Remember to deploy the dll with the custom task in the same folder as the assembly that contains custom action


All Log.LogXX calls made inside the MsBuild Custom Task are intercepted and transferred to Workflow.

Not only messaged, but also warnings issued by Custom Task are correctly identified as Warning in the build result.

With this technique you do not need to look at the text log file to understand what is gone wrong during the execution of the Custom Task.


Custom activity Instead of code something, create a new activity

composing multiple simple activity to accomplish a complex task

Es. Deploy database, instead of using directly MsBuildActivity


Using “arguments” you declare all input arguments needed by your action.

In the property windows you can set type, direction and IsRequired property, you can also specify a default value


This example shows how to create a custom action that deploy a database project using the same technique seen before.

The only difference is that all the steps are included in one action to have a better user experience during customization


Logging is easy, because you can simply use the WriteBuildMessage activity from the “Team Foundation Build Activity” list.

The log of database deployment is still done by MsBuild in the standard file located in drop folder.


Instead of using several activities, you can simply drop a single one and you can configure parameter explicitly.

Each parameter to the deploy operation is represented by a specific property, and each property can have a default value.


Compare how easily arguments are passed with a Custom Activity respect using directly the MsBuildActivity


Put the logic inside a POCO class, then build a MsBuild custom task and a Custom Activity

Move the logic into a poco class


Take the best of both world Extract the logic into a POCO class and create

wrappers

Put all your custom logic inside a POCO class

Creates a MsBuild wrapper that invoke your POCO class logic

Create a Custom Workflow activity that invoke your POCO class logic


Take the best of both world Extract the logic into a POCO class and create

wrappers

• Fully usable from all version of TFS• Simple Drag And Drop experience for workflow

foundation• Easier to test the logic into POCO class• You gain benefit from both world, MsBuild and

Workflow

Pro

• More maintenance• Needs to know Workflow Foundation and MsBuild

environment• More code required

Cons


A real scenario Create a custom build to automate the deployment of a

web app in a test server The script deploy the database project and change the

directory in IIS to point to the drop folder

DB Test

TFS

Check In

Build Server

Sync DB

Update IIS


You can obtain this from the previous example “Deploy database with Msbuild”. The only added part is another Custom Activity used to change the folder of a site using WMI to communicate with IIS

© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.

The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after

the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

extending the build workflow of tfs 2010

Technology

custom msbuild taskdo

custom msbuild project

msbuild action

custom tasks

msbuild wrapper

msbuild activityuse

msbuild script

projectsusing msbuild