Taking Team Foundation Service for a quick spin


Having just watched Brian Keller’s talk at //Build online I decided to give the new Team Foundation Service offering a spin. It’s free for teams of up to five users and whilst in preview also free for larger teams. No confirmed pricing plans yet so let’s hope MS don’t go silly if they really want to complete with the likes of GitHub and AppHarbor.

Setup is an absolute breeze having just created an account with my Live ID I was able to create a Team Project and start creating tasks in seconds. Make sure you pick your org name carefully as it cannot be changed at a later date. It also forms part of your URL so company name will be the obvious choice over a specific project name.

Hooking into Visual Studio 2012 is equally easy using the Team Explorer dialog to add a new server you just enter your URL http://xyz.visualstudio.com and you’ll be prompted for Live ID and you’re up and running. I just tried creating a task, pushing it to Outlook (2013) and following the link to view online and all went well. Having been through the pain of setting up an on-premise TFS environment including the SharePoint, SQL Reporting and Build Controllers this is a real step forward for smaller teams and I’ll definitely be digging in a lot more.

In an upcoming post I’ll be taking a closer look at the Azure Continuous Deployment Build Definition and comparing this with the new Continuous Deployment offering for GitHub and CodePlex integration introduced to Azure Websites recently.

If you want to try out any of the new Azure features head over to the Azure Website and sign up for the 10 free Azure Websites offering. Alternatively, if you’re a Microsoft Partner you can sign up for Cloud Essentials for your Azure access and whilst you’re there why not get on board with CRM 2011 Online and Office 365 partner access.


Changing the scope of the AssignedTo field in TFS 2010 Work Items


This post is related to changes for Team Foundation Server 2010 but a similar process can also be followed for TFS 2008.

For so long I’ve been meaning to sort out the list of names that appear in the AssignedTo dropdown list when creating work items. This evening I’ve been making some changes to our work item Status workflow following some positive feedback from the QA team and so finally got around to fixing this.

By default it will show all of the Active Directory users that have access to the project. That unfortunately includes all of the system administrators and service accounts, TFS related or otherwise that will be imposed upon you through group policy.

What we need is the ability to restrict this list to only those people pertinent to the project. At the simplest level that would be those people within the TFS Project Contributors group. In a future post I’ll look at filtering this list further based on additional attributes of the work item. For example, subsequent to setting the status to Triaged, you may only want to assign to members of the development team. For now let’s keep it simple.

I’m going to assume you’re comfortable with the TFS Power Tools (available as an Extension in VS 2010) as it’s through the Process Editor available in this extension that we’ll be making our change.

You have a couple of choices here. You can either edit the Work Item Template against a Process Template or as I’m doing directly for now, against the WIT for an existing project.

Select the Work Item Type from the appropriate project in the dialog that pops up and you’ll be presented with the Work Item Editor screen thus:

Double click Assigned To and select the Rules tab on the dialog

You won’t have ALLOWEDVALUES in your list. It’s the setup of this rule that filters the list of displayed names.

Click New and enter the name of the TFS group you want to restrict the list to.

In our case I’m restricting to the Contributors group for the current project. Note the highlighted [project] should be as is and not substituted for your own project name.

Close down all the dialogs and save the template (either import if you exported or just save). If you did this against an existing project go in and create a Work Item of the modified type and hopefully you’ll see a much cleaner list. If your AD is setup correctly it’ll pull in Full Name otherwise you’ll get just the login name.

I hope this is of some use and please don’t be afraid to get stuck into modifying your process templates and work items. Whilst it’s always a good idea to start with the OOB template never be afraid to modify it to suit your own needs. Especially if in our case it helps in getting some real usage out of TFS


You can restrict the names that appear in the AssignedTo list by adding an ALLOWEDVALUES rule to the attribute within the Work Item Template.

Delete orphaned branches in TFS 2010


I recently found myself in a situation in our TFS Source Control where I wanted to convert a main folder into a branch. However I was presented with an error message telling me that I couldn’t do this as a branch already existed below this folder. It turns out that a branch had previously been created incorrectly and then subsequently deleted. However, if you delete a branch its relationship remains and prevents you from branching its current parent.

I found the following blog post provided me with the answer. But more usefully it showed me the ‘show deleted items’ checkbox that gives you a much better historical view IMO of the Source Control structure. Maybe this should be the default view with the option to turn it off rather than on?

Hierarchical Work items


I tweeted recently about my wish for hierarchical work items on the TFS check-in dialog within Visual Studio and was somewhat surprised at the number of responses in agreement I received. Hierarchical workitems have been one of the most hyped features of TFS 2010 (and rightly so as they’re awesome for better support of the planning effort) but the lack of their presence on the check-in dialog presents a little too much friction for the development team at the moment in my opinion. Whilst we can filter and search using custom queries I’d still like to see this become a feature in an upcoming service pack as despite the huge number of extensibility points into TFS, access to this dialog isn’t available.

Finally, over the last few months I seem to have become both the custodian and evangelist of our TFS proposition. I can really see the benefit in process improvement TFS offers. The tooling should enable not dictate your process and I believe TFS 2010 provides that. If I could just drag enough key players along kicking and screaming, I have the Development Manager and one key PM on board so far so watch this space for more updates on how I get on riding the TFS train.

Abandoned Blogs


If a place existed where blogs could go when feeling neglected, I’d say mine would have been there for quite some time!

Having been really busy over the last 9 months building a new .NET solution I’ve now returned to TFS to perform some “housekeeping” in preperation of our next project. Actually when I say housekeeping it’s a little more serious than that; I’ve actually built us a whole new TFS Server as the last one had to remain in a Workgroup due to the lack of an AD in our environment. As you can probably imagine being in a Workgroup proved to be quite a pain at times especially with Build Server and SPS. But hey, we’re on the road to recovery so I’ll be posting more TFS findings and pains on here over time.

TFS Check Out & Get Latest Version


Over the last few days the guys in our team have started getting conflicts when checking back into source control despite exclusive check-out being set on all projects. It would seem that after doing some research, exclusive check-out in TFS no longer means exclusive or more accurately exclusive to the latest version.

Consider the following scenario…

Bob checks out file A
Bob makes changes to file A and checks back in.
Alice has the version of file A on her machine prior to Bob’s changes.
Alice checks out file A

Under VSS this would have brought the latest version of the file from the server to Alice’s machine and checked it out to her.

Under TFS Alice will receive check-out rights to the file preventing anyone else from changing it. All is well so far, however the file that Alice is now editing is NOT the latest version from the server with Bob’s changes, but the version she held prior to check-out. When Alice attempts to check the file back in she is informed of a conflict with the version on the server.

So what’s happened? Simple, TFS checks out the file BUT DOES NOT GET THE LATEST VERSION FROM THE SERVER leaving Alice to edit the “old” version.

At first we assumed this was a bug but it turns out this is by design. Microsoft has implemented this approach to prevent the local build for Alice from potentially being broken by changes applied by Bob. Now the importance of not breaking the local build for Microsoft may be important given the scale of the projects they work on, but for us and I believe the majority of the development community this is not the case. The time required to resolve changes is ridiculous and for some reason TFS disables the merge option on the dialog box leaving you to do it manually whilst trying to figure out what the implications are; usually dire on any large code changes.

Now this approach is a reasonable option should it suit your development topology but the biggest mistake made by Microsoft is not giving you the option of turning this off!

So how do you get around this issue? There are two options…

Option 1

  1. In Team Explorer disable multiple check-out on ALL projects
  2. In VS2005 Source Control options, change from Silent Check Out to DO Nothing. This means you have to manually check-out all files.
  3. Before checking out do a Get Latest. This makes the whole check-out process a more conscious exercise but still relies on the developer to be disciplined and we all know that ain’t going to happen.

Option 2 (Our solution)

As above except we have written a macro to perform the Get Latest and Check Out as one operation. This doesn’t resolve the issue entirely but does minimise as best as possible the chances of this happening.

If like us you’re not happy with this setup then I’m afraid you’re going to have to wait for Orcas before it’ll be changed (and it will as Microsoft has admitted they’ll be changing it).

I hope this information has proven useful and would welcome comments on any better solutions or whether you believe the approach taken within TFS currently is a good idea.