Filtering Assigned To

Team Foundation Server work items have an assigned to field that defaults to the Valid Users Group. The problem is this group includes service accounts also.


You can easily change the list to contain just the groups you want.

Open up the work item with the Process Editor you get when you install the TFS 2010 Power Tools.

Open the field definition for the Assigned To field in the work item and switch to the Rules Tab.

Remove any rules that are there now. and add Allowed Values and Default.


Edit Allowed Value and set it to the following to get all the project administrators and Contributors along with an unassigned value. Make sure you exclude Groups.


Under Default set the value to be Unassigned.


Now you are all set all that will show up in the AssignedTo drop down is Unassigned along with Project Administrators and Contributors.

Requirements in TFS

Customers are often asking about storing requirement documents with their requirement work item. Specifically what is the best way to do this? I always tell them they have 3 options. Before we talk about that keep in mind there are third party requirement management tools out there that integrate with TFS. Therefore there is a 4th option. Which is to use that tool and have it push requirements into TFS as a work items but store the full fidelity of the requirement in the requirement management tool itself. If you don’t have such a tool here are 3 other options.


The simplest is to just attach your requirement document to the Work item using the attachments tab on the work item. The document is stored in the Database with the requirement and is easily found by others. This is difficult to version though. If you changed the requirement in another release you would have to alter the document and attach it again to another Work item so you can maintain the previous requirement as it was in the previous version.

Versioned Items

If you want to keep versions of the Requirement document you could store it in source control and create a link to it from the work item using a Versioned Item. Then you can point the Work item to a particular version of the document in source control using the Link Type Versioned Items.


The third solution is to store the document in SharePoint. Where you can easily apply workflow to it and version it. Then link it to the Work Item via a Hyperlink link type.

Along the same lines, I was recently asked what if I wanted to change my requirement work item so there was a tab on the Requirement just for Hyperlinks to SharePoint, and remove the Attachments tab so documents can’t be added to the work item.

I’m not sure I would remove the attachments tab it can be handy for many things. However it’s easily removed from the UI. Adding a Tab just for Hyperlinks is a little trickier.

I’ll explain how to do this using the process editor that comes with the TFS power tools. Then also include the XML for the control.

Open the work item type using the process editor, and go to the layout tab.

Add a new Tab under the Tab Group and name it SharePoint Documents or something appropriate.

Create a new control on that Tab and change the control type to a LinksControl

On the Control Settings property click the ellipses button to open the editor. 

In the filter section there are three fields set them like this:

  • Work Item Type Filters – Exclude - Select all Work Item Types
  • Work item Link Filters – Exclude - Select all Work Item Filter Types
  • External Link Filters – Include – Workitem Hyperlink

Might as well remove all the columns except for Title and System.Links.Comment

Once you apply this change to your Project you will have a new tab that only allows Hyperlinks to be added.

As promised here is the XML for the new Tab with Links Control

<Tab Label="SharePoint Documents">
            <Control Type="LinksControl" Label="" LabelPosition="Left">
                  <LinkColumn LinkAttribute="System.Links.Comment" />
                  <LinkColumn RefName="System.Title" />
                <WorkItemLinkFilters FilterType="exclude">
                  <Filter LinkType="Microsoft.VSTS.Common.Affects" />
                  <Filter LinkType="System.LinkTypes.Hierarchy" />
                  <Filter LinkType="System.LinkTypes.Dependency" />
                  <Filter LinkType="System.LinkTypes.Related" />
                  <Filter LinkType="Microsoft.VSTS.TestCase.SharedStepReferencedBy" />
                  <Filter LinkType="Microsoft.VSTS.Common.TestedBy" />
                <ExternalLinkFilters FilterType="include">
                  <Filter LinkType="Workitem Hyperlink" />
                <WorkItemTypeFilters FilterType="exclude">
                  <Filter WorkItemType="Bug" />
                  <Filter WorkItemType="Issue" />
                  <Filter WorkItemType="Shared Steps" />
                  <Filter WorkItemType="Task" />
                  <Filter WorkItemType="Test Case" />
                  <Filter WorkItemType="User Story" />

Testing Pictures

Cowardly Lion

The Layer Diagram

The layer Diagram in VS2010 Ultimate is a great tool for validating your applications architecture. If you already have an application and you would like to see how your team has done following your prescribed architecture. Check this out.

Open your application in Visual Studio.

Then create a new Layer Diagram using the Architecture – New Diagram menu in Visual Studio Ultimate.

By dragging over layers from the tool box create a Layer Diagram that represents the architecture of your application.

Then Drag the components from your application in the solution explorer to the appropriate layer in the diagram. You can then open the Layer Explorer to see what layer everything is assigned to. (You can drag anything from a project to a single file.) Notice the numbers in the Layer diagram representing the number of items in that layer.


You could have created dependencies in the diagram to show which layer can call which layer. Since we are pulling in an existing app we want to see if it was written following our architecture. Therefore Right click on the diagram and select Generate Dependencies.

So here is how our application came out.

Most of the dependencies are fine. However there seems to be a lot of calls directly to the Data Layer. That is not good, but happens when the architecture is not validated periodically. click on the dependencies that are incorrect and press delete to remove them. Here is the Layer diagram as we intended it.

Now right click on the diagram and select Validate Dependencies.

This will generate errors and warnings where the application does not follow the architecture. So the Dependencies generated in the previous step now generate errors in the application.

From the error list you can generate work items in TFS to get these discrepancies fixed.

The bug will contain layer diagram that generated this error and the details of the invalid dependency.

The Next Version of VS and TFS

While we have been enjoying the fantastic features made available in VS and TFS 2010, Microsoft has been busy working on the next version. The ALM story just keeps getting better and better.

Last week at Teched MS showed off a lot of the new features we can expect to see in the next release. Below is a SpeakFlow presentation with demos to help tell the story.

A SpeakFlow is a Silverlight-powered way of delivering rich, interactive content. This SpeakFlow allows you to follow the lifecycle – from development to operations and back again – and view short demonstrations of how Visual Studio vNext will help you embrace better application lifecycle management. start at the top with the  “STORYBOARDING” video and then following the circle counter-clockwise.
Tip: To go up a level after drilling in, use your mouse wheel or the UP key on your keyboard.

Click on the image below to take a look.

Support for Visual Source Safe Extended


Support for Visual Source safe 2005 was previously scheduled to end this year, however to allow customers more time to migrate away from it. Apparently MS has decided to extend mainstream support until July 10 2012 and Extended Support to July 11 2017.

How do I know this? There is a web site that tells you how long MS products are supported for.

So come on people lets get those VSS repositories converted over to TFS you will be much happier and your code will be much safer.

In case your reading this and don’t know that it’s available you have a tool right there on your machine to convert a VSS repository to TFS.

Register now for ObjectSharp @ the Movies

Join ObjectSharp and Microsoft on May 5th for a Half Day in the Cloud! Learn to provide stability and elasticity for your web based solutions as we leverage Windows Azure. Technologies including Silverlight, ASP.NET, Team Foundation Server, Visual Studio and Powershell will be in the Air as we rain data down from the Cloud. This is one summer blockbuster event that cannot be missed!

Thursday, May 5th, 2011

Registration: 8:00am - 9:00am
Presentation: 9:00am - 12:00pm

Scotiabank Theatre
259 Richmond Street West
Toronto, ON M5V 3M6

Build a Reporting Services Solution with MSBuild 4.0

I recently was tasked with setting up a build for a large solution of Reporting Services reports. The goal was to build and deploy them. The build was pretty easy although disappointing. Reporting Solution projects are not msbuild projects. You can however build the solution from the command line using devenv.exe. Which looks something like this:

devenv.exe /Build debug /out ".\Logs\SSRS.Log" ReportingServices.sln

So automating this on a build server was pretty simple. Install a copy of Visual Studio 2008 or 2005 depending on the version of your reports. (No 2010 can’t even open a reporting solution let along build it.)

In source control in the same folder as your Reporting Services Solution create a batch file with the above command. I would pass the drop location in to batch file and put the log there instead of in the source directories. So the batch file may look more like this.

mkdir %1\Logs
devenv.exe /Build debug /out "%1\Logs\SSRS.Log" reportingServices.sln

Now in your build process template drag in an invoke process activity, and populate 

ExitCode is a Variable of the type int32 that you would create in your build process.

BuildDetail.DropLocation and SourcesDirectory are variables already set up for you that hold the Drop Location you selected in your Build Definition and the Sources Directory defined by your Build Agent Working Directory.

TFS Build Invoke Process Activity

Likely the most useful tool in the list of Team Foundation Build Activities is InvokeProcess. This little Activity lets you call out to anything you want. I have found it very useful for executing a batch file that is stored with my source code to do a number of things. Invoke a PowerGen build for PowerBuilder Applications. Invoke Devenv.exe for building Reporting Services, or calling a deployment script you don’t want to rewrite at the moment.  

When I went to use this activity the first time there was not much out there as an example so I thought I would post a quick and dirty example of using the Invoke process.

Find the place in your process where you want to make the call and drag in an InvokeProcess Activity.

Next you want messages that come from the application you are calling to end up in your Build report. This is done via stdout and stderr. So drag over a WriteBuildMessage Activity and a WriteBuildError Activity into the Invoke process as seen below.

There are two variables defined stdOutput and errOutput they need to be placed in the message property of the Write Activities. I would set the Importance property on the WriteBuildMessage Activity to High. Like this:

Now for the properties of the Invoke process. It’s pretty simple really.

DisplayName: This will be exposed in the Workflow so it’s good to name it something that reads well and tells the reader what you are doing here. 

FileName: The file you want to call. For batch files I find it useful to put the file in source control with the app. Then use the SourcesDirectory variable to find it. See Below.

Arguments: What you want to pass to the called application or batch file.

Result: Your ExitCode variable. The last thing you call from the batch file or the app will generally return an exit code then you can use that to determine if you want to carry on in the build process.

EnvironmentVariables: This dictionary of <string, string> allows you to specify environment variables and their values.

OutputEncoding: You can specify the encoding that is used to read the output (StandardOutputEncoding) and error (RedirectStandardError) streams. I have only ever used the default value.

So if I wanted to call a batch file named MyBatchFile.bat and it was in source control at the root of my solution folder, and I want to pass in the Drop Location from my build definition. My InvokeProcess might look like this.

ObjectSharp At the Movies is in the Cloud


Join ObjectSharp and Microsoft on May 5th for a Half Day in the Cloud! Learn to provide stability and elasticity for your web based solutions as we leverage Windows Azure. Technologies including Silverlight, ASP.NET, Team Foundation Server, Visual Studio and Powershell will be in the Air as we rain data down from the Cloud. This is one summer blockbuster event that cannot be missed!

ATM 2011 Learn More!

2010 At The Movies

Thursday, May 5th, 2011
Registration: 8:00am - 9:00am
Presentation: 9:00am - 12:00pm

2010 At The Movies

Scotiabank Theatre
259 Richmond Street West
Toronto, ON M5V 3M6

2010 At The Movies
FREE admission