TFS11 Shelving

If you are like me and a fan of Shelving in TFS you are going to love TFS11.

Here are some new features for Shelving that have me excited about the next release.

Merge

Instead of a copy, unshelve is now a merge. You can take those changes and Merge them in with your current local changes. Also this means that on a Gated Check in the Shelveset is merged with the main base of code prior to the private build.

Work items

In the new Team Explorer you can select work items that are In progress. So that when you check in the changes the changeset is associated to the work item.

If you Shelve this work to do something else the Work item is stored with the Shelveset. When you Unshelve to work on it you will get the work item also.

Switch

Select a shelveset while you have work in progress. Notice the Switch command below. This allows you to take your In Progress work and swap it out with a Shelevest.

TFS Work Item History Compare

 

I had a customer that was looking for a way to see the history of a work item in an easier to compare format then the work item itself.  I searched for such a tool, didn’t find one, so I wrote this.

I uploaded it to CodePlex in case anyone would like to use it or extend it. If you just want to try it out you can download the latest version from CodePlex.

The app is pretty simple. Simply run GetHistory.exe select the server and projects you want to query and hit connect.

On the main form below, the Project drop down will be populated with the list of projects you selected from the connection screen.

Enter a Work Item ID from that project and hit enter or click Get History.

The grid will fill with each revision of the work item. If the data in a field is different than the previous revision it will be displayed in red.

Other Options

Go to the Fields to Ignore tab to select work item fields you don’t care to see. Some are obviously pointless and should be turned off by default. (ie: Rev, ID, Area ID, Iteration ID, History, Work Item Type)

Connect to TFS: Use this button to switch to another server or collection or add or remove a project from the drop down.

Clear:  Clears the form of the last retrieved work item data.

Export to Excel: Do I really need to tell you what this does?

I hope someone out there finds it useful.

AlignIT - Manager Tech Talk

Tomorrow Barry Gervin and I will be interviewed on AlignIT with Ruth Morton and Jonathan Rozenblit.

We will be discussing the Pros and Cons of upgrading to the next version of VS and TFS. Affectionately known as vNext or Dev11.

Feb 29th MS announced the release of Windows 8 Customer Preview and Visual Studio 11 Beta.

Looking forward to the discussions. Watch for it on AlignIT

O# at the movies is back

I remember the first ever event we did in a theater. It was all about Whidbey, remember that? Then the next year Nick Van Exan our student and part time graphics guy created a movie poster to promote the event. I think it was Barry Gervin as Dr. Evil, very funny stuff.

The tradition continues.

ObjectSharp is pleased to present it's 2012 "At The Movies" event!

At this 3-hour live morning event at the Scotiabank Theatre, on Tues 1 May 9-12 noon, you will see and hear about Microsoft's new developer tools for 2012:

Metro (Win 8 + Mobile)
VS 2012
TFS 2012 + Test Manager 2012

...from ObjectSharp's MS MVPs: Dave Lloyd, Bruce Johnson, Barry Gervin, Colin Bowern, Deb Forsyth and Atley Hunter

PLUS:  your admission includes:

Coffee + Popcorn + Soft Drinks

AND ...  multiple draws for Microsoft and Telerik cool stuff!

What does it cost?

General Admission is $25 (or register by Friday April 14 and pay just $15)!

Register Online Now!

What if I have questions?

e-mail us at ATM@objectsharp.com
or call: 416-649-3690 (ext 0)

Editing a Build Process

If you want to edit your build process and utilize some of the custom activities in the  Community TFS Build Extensions. You may be finding it tough to drag the activity into your Workflow. Or Intellisense may not be working like you saw in that demo. Below are the steps to help you create a project to store your custom build processes and easily edit them.

First Download the Community TFS Build Extensions and copy them into a folder in source control. I like to put them in a folder under the BuildProcessTemplates folder created from your Process Template, called Custom Activities.

For example: $/ObjectSharp Projects/BuildProcessTemplates/CustomActivities

You need to make sure the build server knows where to find these so Change the Build Controller property Version control path to custom assemblies to this location in source control. You can get to it by right clicking on the Builds node in Team Explorer and selecting Manage Build Controllers. Select the Controller and click the properties button.

Make a copy of the Build Process Template that you want to edit and make sure it’s in the BuildProcessTemplates folder under source control.

  • Add the Custom activities to your toolbox.

in Visual Studio select Tools | Choose Toolbox Items… from the main menu.

On the System.Activities Components tab browse for the TFSBuildExtentions.Activities.dll and add it.

  • Create a new Class Library Project

Delete the Class1.cs that gets created.

Add the following references to the project:

From the .Net tab on the Add Reference dialog:
Microsoft.TeamFoundation
Microsoft.TeamFoundation.Build.Client
Microsoft.TeamFoundation.VersionControl.Client
Microsoft.TeamFoundation.VersionControl.Common
System.Activities

From C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies
Microsoft.TeamFoundation.Build.Workflow.dll
Microsoft.TeamFoundation.TestImpact.BuildIntegration.dll
From where ever you installed it on your machine
TFSBuildExtensions.Activities

  • Add the Build Process Template to the project.

Right click on the project and select Add | Existing Item… from the context menu.
Navigate to the build process template you want to edit 
Click on the arrow next to the add button to select Add As Link

Now you can work on your build process in place from within a project so you have all the references you need to drag activities in and have the benefit of intelitrace.

Creating a Custom Link Tab for your TFS Work Item

Each work item in TFS contains an All Links Tab where you can see all the links to this work item grouped by relationship type.

There are other tabs that just show specific links like Implementation, Change Requests, Test Cases. These tabs are filtered to only show certain types of relationships and the work items that can have this relationship.

It’s very easy to create your own Tab that shows specific links and the work item types that you want the user to include.

As an example lets create a Review Tab on the Requirement work item in the CMMI Process Template so we can see the Design Reviews associated to this requirement.

Open up the CMMI process template using the Process Template editor that comes with the TFS Powertools.

Lets create a custom link type to be used for Reviews. From the Process Editor select Methodology | Work Item Tracking | Link Types and click the new Button. Fill in the New Link type to represent a  Reviewed By/Reviews relationship.

Save the Link Type and open the Requirement Work Item type editor.

In the Layout tab right click on the TabGroup node and select New Tab Page from the context Menu. You can right click on that new tab page and select Move Up or Move Down to change it’s order in the Tab control.

Change the Label on the New Tab Page to Reviewed By.

Right click on the Tab Page – Reviewed By and select New Control. Fill in the Control property grid with label, name and type information.

Now select the Control Settings field and click on the button in that field with the ellipses.

From here you can control the links that can be added and viewed with this control.

There are three filters that can be applied.

Work Item Type Filters: Allows you to select the type of work items the can be selected. You can choose to Include All work item types or Include/Exclude a subset of them. For our example we will select Include and check the Review Work item Type.

Work Item Link Filters: Allow you to force a specific work item link type. You can include/exclude all or include/exclude a subset. For our example we’ll Include the new Reviewed By link type we created.

External Link Filters: These are for the non work item links. You can include or Exclude the following external link types.

Fixed in Changeset
Result Attachment
Source Code File
Test Result
Workitem Hyperlink

See my blog entry on Requirements in TFS for an example on using the External Links.

For our example we will set this to Exclude All this way none of the external links will be allowed.

You can also select what columns you would like to show in the list of related work items. I’ll add Called By and Called Date to the selected Columns.

Now with a project created from this process template the Requirement will have a Reviewed By tab that allows users to add Reviews with the link type Reviewed By.

 

Metro Toronto User Group February 2012

 

Come out to the Metro Toronto User Group on February 15th. Colin Bowern and I will be showing you how to customize your build process with TFS 2010 and use MS Deploy to automate your web app deployment.

Customizing the TFS Build process and automatically deploying your web app.

When: Wednesday February 15, 2012 at 6:00pm

Where: KPMG, 333 Bay Street, 46th Floor, Toronto

See you there.

Create a Master Build that calls other Builds

Have you ever wanted to have a build that kicks off a bunch of other builds. I recently had such a need, we wanted to have independent build definitions for a bunch of apps. However when you are responsible for deployment you just want to run a bunch of builds at once. If every app is a .net application it’s easy to create one build that builds all the apps.

However in this instance we have two different build process’s. One for .net apps and one for VB6 COM applications. So we created a master build that can kick off multiple build definitions each having a different build process.

First thing is to strip down the Default build Process to it’s bare minimum. Here is what the Build Process looks like.

If you are familiar with the default build process you will recognize the first few items.

The ForEach is the new part. I will explain that in a minute. First we need a new Argument to the build process that will hold the build definitions you want to queue.

Name – BuildDefinitions
Direction – In
Type – String[ ] (Array of Strings)

and a new Variable for the output.

Name – BuildRetVal
Type – IQueuedBuild
Scope– RunOnAgent

You will need to get the Community TFS Build Extensions from Codeplex. If you don’t know how to get started using these, there is plenty of help on that subject here.

To Queue up a bunch of builds drag in a ForEach and iterate over the BuildDefinitions parameter you added.

Inside the ForEach drop in a QueueBuild from the community TFS Build Extensions.

Here is how you fill in the paramaters of the QueueBuild Activity.

Build Controller - BuildDetail.BuildController
BuildDefinition - BuildDetail.BuildServer.GetBuildDefinition(BuildDetail.TeamProject, item)
BuildServer - BuildDetail.BuildServer
Priority - Microsoft.TeamFoundation.Build.Client.QueuePriority.Normal
Process Parameters - Microsoft.TeamFoundation.Build.Workflow.WorkflowHelpers.SerializeProcessParameters(New Dictionary(Of String, Object) From {{"AgentSettings", AgentSettings}, {"Verbosity", Verbosity}})
Result - BuildRetVal

In my example I pass the Agent settings and verbosity through to the called definition. That way I can control them from the master build. In our case we wanted each child build to run on the same agent as the master build so we can accomplish that by passing in the AgentSettings to override those defined in the build definition.

We also passed in the Drop Location and used it in the child so that the child builds each dropped their binaries under the master builds drop folder. Again a choice we made for our situation.

Once you have the process we can define a build definition for the master build. Add all the Build Definition Names you want and the Master build will kick them all off for you. It should look like this.

Set the AssemblyFileVersion to match the build number

If you are not sure why you need to set the AssemblyFileVersion and AssemblyVersion read this first.

First thing to do is to change the build number format to include the version number of a build Major.Minor.Build.Revision.

Something like this $(BuildDefinitionName_{Major}.{Minor}.$(DayOfYear)$(Rev:.r) will usually do the trick. The Build number could also be a date $(Date:MMdd)

The above build number format will will result in a build number similar to: Calculator.Main.QA_5.3.321.1

For the Major and Minor numbers create two string arguments in your Build process one for each.

Find the Invoke For Reason activity named “Update Build Number for Triggered Builds” in your build process and add an Assign activity right before the Update Build Number activity. This will include your Major and Minor build numbers in the Build Number Format.

Assign activity
To:
BuildNumberFormat
Value: String.Format(BuildNumberFormat, Major, Minor)

Now we want to put the version number from the build into the AssemblyInfo.cs file in our projects so the assemblies have the same version number as the build.

There are 3 build activities we can use to get the job done.

We will need the following variables defined:

  1. FileVersion as string
  2. FilesToVersion as IEnumerable<String>

Then add these four activities into a sequence right after initialize Workspace.

  1. 1. Extract the Version Number from the Build Number
  2. Assign activity (From the Primitives group in your Workflow tool box)
  3. To: FileVersion
  4. Value: BuildDetail.BuildNumber.Substring(BuildDetail.BuildNumber.IndexOf("_") + 1)

2. Get all the AssemblyInfo.cs files
FindMatchingFiles activity (from the Team Foundation Build Activities in your Workflow tool box)
Match Pattern: String.Format("{0}\**\Assemblyinfo.cs", SourcesDirectory)
Result: FilesToVersion

  1. 3. Change the AssemblyFileVersion
    File activity (from the TFS Build Extensions project)
  2. Action: Replace
  3. Fail Build on Error: True
  4. Files: FilesToVersion
  5. Regex Pattern: "AssemblyFileVersion\(""(.*)""\)"
  6. Replacement: String.Format("AssemblyFileVersion(""{0}"")", FileVersion)
4. Change the AssemblyVersion

File activity (from the TFS Build Extensions project)
Action: Replace
Fail Build on Error: True
Files: FilesToVersion
Regex Pattern: "AssemblyVersion\(""(.*)""\)"
Replacement: String.Format("AssemblyVersion(""{0}.{1}.0.0"")", Major,Minor)

When you queue a build set the Major and Minor numbers on the build definition and let the build process do the rest.

The result will be an AssemblyFileVersion that looks like 5.3.321.1 and an AssemblyVersion that looks like 5.3.0.0

The TFS Build Extensions has a TFSVersion Activity that is great and helps to simplify this. However it currently has a problem with a BuildNumberFormat that is different from the default. When that gets fixed i will repost how to do this using TFSVersion.

Test Case Customization

The Test Case Work item has a tab that lists Tested Requirements or User Stories (depending on the canned process template CMMI or Agile) that this Test Case tests.

When a bug is found you should write a test case so everyone knows how to validate that Bug once it’s fixed. Therefore why have a tab that just shows Tested Requirements/User Stories.

Lets use the Agile template as an example. The Tested User Stories tab will only allow you to add User Stories. Even though you could add a Bug with the tests relationship under All Links if you wanted.

It’s very easy to change this tabs behaviour to allow for Bugs also. Here’s how.

Open up the Test Case in the WIT editor that comes with the TFS 2010 Power Tools. Under the Layout tab find the TabGroup > TabPage – Tested User Stories > Control – User Stories tested by this Test Case and select it.

Select the Control Settings property and click on the ellipsis button. Leave Work Item Type Filters as Include. However in the drop down list to the right of that change it to also include Bug, then click OK,

Now change the Label from User Stories tested by this Test Case to something more appropriate like Tested by this Test Case.

Then switch focus to the Tab Page and change it’s label to something more appropriate  like Tested User Stories and Bugs or just Tests.

Save the work item type.

You should now be able to select Bug as a work item type tested by this test case.