Connecting to TFS from any version of Visual Studio

I've written a couple of blog posts on this subject before and thought it would  be nice to consolidate them into one big post now that Visual Studio 2013 is about to be released. There are 3 major things to consider when connecting to TFS from an older version of Visual Studio.
  • The version of TFS you want to connect to
  • The version of Visual Studio you're connecting from
  • The version of Windows you're running
In this blog post:
  1. Connecting to Team foundation Server 2013 or Visual Studio Online (formerly known as Team Foundation Service).
  2. Connecting to Team foundation Server 2012.
  3. Connecting to Team foundation Server 2010.
  4. Configuring the MSSCCI provider for Visual Studio
  5. Connecting from Visual Studio 2005, 2008 or the MSSCCI provider
Since writing this post, Microsoft has produced an updated piece of documentation (which is already behind in some aspects) that describes most of the client/server combinations. One thing it adds which I haven't described, is the list of features that are available depending on your version of Visual Studio/TFS.

If you're having issues connecting after updating, it might be required to clear your local client cache to clear up certain issues like this one. Either the official way or the hard way.

If you also want to install the Team Foundation Server Power tools to match your Visual Studio/TFS version, check out this separate post.

Update: Updated download links to the final version of Team Explorer 2013.
Update (13-11-2013): Updated download links to the final version of Visual Studio 2012 Update 4.
Update (25-11-2013): Added information on client cache and feature docs.
Update (6-1-2014): Added update for VS2010 for Windows 8 and Visual Studio 2012
Update (21-1-2014): Added update 1 for Visual Studio 2013
Update (25-8-2014): Added update 3 for Visual Studio 2013


Building a .NET application using the GitUpgradeTemplate.xaml

Today I received a request which I first found strange. A team that migrated to Git, but still wanted to use their TFS 2008 era TFSBuild.proj. After seeing the investment made in that build file, I understood :).

So we though to simply use the GitUpgradeTemplate.xaml which is provided with TFS 2013 and be done with it. But you'll see that Team Build will kick off the build and will download your TFSBuild.proj as you'd expect, but it doesn't download your sources.

Your TFSBuild.proj needs to be updated with a few properties to make it work. The minimal project file is listed below:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
  <!-- Do not edit this -->
  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />


    <!-- Team Foundation Build Version - DO NOT CHANGE -->


    <!-- Set this property to true for Git build. -->


In your Build Definition make sure you're using the (rather unfamiliar) vstfs:///Git/VersionedItem/{TeamProject}/{Repository}/{Branch}/{Folder-Containing-TFSBuild.proj} as your Configuration FolderPath.


Codelens features and Visual Studio versions [Updated for 2013.3ctp1]

Update: Visual Studio 2013.3 CTP 1 Adds support for Git repositories!

If you're as happy with the new CodeLens features in Visual Studio 2013 ultimate as I am, you've probably found out that some of the features rely on server side features. This means that some Code Lenses only work when you are connected to the latest version of Team Foundation Server (2013). 

Even Visual Studio Online doesn't (yet) support Code Lens. The background processing it introduces on the number of Visual Studio Online accounts that are currently active on the service is not something that should be taken lightly. Given the tremendous value of Code Lens, I expect the server dependent lenses to be enabled in the months to come, there is a UserVoice suggestion you can track for this item.

Another area where certain Code Lens features are not yet available is when you're using a Git repository. There is an open UserVoice suggestion for this and again, given the popularity of Code Lens, I expect support to be added in the future. Since with Git the whole commit history is available on your local system, it will probably even work when you're not connected to the remote TFS repository.

CodeLens is currently only supported when editing C# and VB.NET. C++ (managed and unmanaged), Javascript, TypeScript and F# or any other file format are currently not supported.

LensTeam Foundation Server versionVisual Studio Online 3rd Party
≤2010 2012 2013
Test Status**yesyesyesyesyesyesyes
Tested By**yesyesyesyesyesyesyes
Authorsnonoyes*yes (u3)noyes (u3)Git (u3)
Changesnonoyes*yes (u3)noyes (u3)Git (u3)
Bugs update 1nonoyes*yes (u3)noyes (u3)no
Work Items update 1nonoyes*yes (u3)noyes (u3)no
Code Reviews update 1nonoyes*nononono
Code Health add-onyesyesyesyesyesyesyes
Incoming Changes update 2yesyesyesnononono
Intellitrace update 2???????

* Works only when connected to your Team foundation Server.
** Supports MsTest, XUnit (requires latest adapter version) and NUnit.

If you have an idea for a new Code Lens, please submit your suggestion here.

I will update this table when new Lenses appear or when new Lenses are enabled on another Server, Source Control Repository or on Visual Studio Online.


Controlling whether CodeLens runs

Don't get me wrong, I just *LOVE* CodeLens, but I've found a few times where I want to control it's server jobs.

A few scenario's where I don't need CodeLens running for my Project:

  • The project is an archive and isn't actively used
  • None of the developers on the team have an MSDN Ultimate license
  • You're upgrading a massive TFS server and want to control which Project Collections are processed first.
I didn't actually know that there was an option to control Code Lens indexing until today, thanks to Mathew Aniyan.

To activate or deactivate the indexing at a Project Collection Level, you can use the TFSConfig CodeIndex command, as outlined here. You can get finer granularity by adding Ignore paths to the list.

To turn off for the whole collection use: 

tfsConfig codeindex /collectionName:DefaultCollection /setIndexing:off

To turn off for a specific team project use:

tfsConfig codeindex /collectionName:DefaultCollection /ignoreList:add $/ProjectName/*

This will allow you to reduce the amount of processing required after an upgrade by excluding old data and it can improve the performance a little should you have a TFS server which has been sized tightly.

Even though "tfsconfig codeindex /?" doesn't really explain this, one can use a wildcard at the start or end of the path:

Command: codeindex
Adding to or removing from the ignore list requires a valid path to be specified.
Wildcards ('*') are allowed as the first and/or last characters of the path.

Work item customization doesn't get reflected in Web Access (2012 and 2013)

In our company we have quite a few custom process templates for TFS, most of these have been around for quite some time and have been updated as new versions have come along. Recently I was asked by a number of people why their changes made to the Form Layout don't get reflected in TFS 2013 Web Access, and after taking them though all of the things to check (IIS Reset of the AT, clear work item cache etc), they still failed to show up.

So I started digging. First thing we found is that Web Access can get cranky if Custom Work item Controls are missing. Visual Studio will happily render a TextBox or DropdownBox so that you get some working UI, Web Access behaves slightly different; it just hides the whole control from the form. So if you're using any custom controls, make sure that they're installed on both the Web Access server and inside the version of Visual Studio you're using to change the process template. They should be listed and enabled on the Admin page:

There's a very funny 'bug' in the Power Tools Process template editor, it will not tell you that you're missing a control. It will simply show FieldControl in the UI, since the PreferredType isn't available from the Work Item Form Designer. Very annoying, so it took some actual XML digging to find items like these.

And then the second thing we ran into, is that many of our old work item definitions used to have more than one tags. One for Windows, one for Web. There's a number of very picky rules to keep in mind here and in general I feel that it's much easier to just have both use the same layout. Most the templates were created long before any of these rules were documented in blogs, causing all kinds of funny things to happen. Going back to a single layout makes it all a lot easier to manage.

A thing to look out for when using the Power tools is that again it doesn't show you everything. When you open a WIT that has multiple layouts, the Power Tools designer will only show you the *first* one. It doesn't even tell you that there are others.

Just a few lessons learned :S.


Book Review: Resharper Essentials - Or: Find your way around Reharper's Shortcuts

I received an ebook copy from Packt Publishing for an honest review, So here we go :).

I've been a long time, on and off user of Resharper. But it has taken me a long time to learn most of its features. Even today I still find little gems I never kew existed, it's like Visual Studio itself, which has so many features I've never even seen before.

This book quickly takes you through the most important feature area's of Resharper and teaches you the most important shortcuts. Ctrl-T, Ctrl-R, Ctrl-U, Alt-Enter, Alt-` and (Ctrl-)Alt-Ins. With those few key presses and an idea what they do you'r probably able to unlock all the hidden potentials of Resharper by paying attention to what is shown on your screen. Without those you might not even know what Resharper can do for you. The book showed me a few thing I didn't even know existed :).


Ask a developer for confirmation in a TFS checkin policy

A TFS checkin policy can normally only be dismissed by overriding the policy. There is no way to selectively allow a user to override one, but not another policy. And there is no way to interact with the user from the Check-in dialog using custom UI other than the message, you can't add your own check box or text box.

One of the policies I recently wrote warns the developer that he might be doing something stupid. We want our developers to be able to dismiss this warning, but we don't want him to override the work item attachment or the comment policy.

So we decided to add a way for the developer to dismiss the warning by double clicking the message.

Edward Thompson confirmed on StackOverflow that interacting with the user on the Evaluate method to be avoided. But the documentation mentions another event, the Activate method, which is called when the user interacts directly with the warning.

This is ideal for this situation. By double clicking the warning, we trigger the Activate method, show a warning and upon dismissal of the dialog save the result.

Now when the conditions for the policy changes, we reset the result and the policy will trigger again.

In order to allow a user to dismiss the policy, we added a configuration option to the policy which will allow this:

A sample UserOverridePolicy can be found on StackOverflow and our Multiple Branches policy implements this strategy as well.

I might even take this as far as allowing any policy to be nested in a generic UserDismissablePolicy in the future, similar to how the Custom Path Policy works.

Source: StackOverflow