LightWeight Charting in TFS 2013

One of the most interesting aspect of TFS is the great ability to give you all the statistics you need about your project thanks to the integration with SQL Analysis Services. The ability to do complex report based on TFS Cube is really exceptional, but it somewhat complicated for small teams, that needs much more simpler data.

The solution has always been loading the result of a certain query in Excel and then create some Excel Chart to have a visual representation of Query Result Data. This approach is really useful and simple, but people really need something that can be shared in a much more simpler way. Latest TF Service update and TFS 2013 RC introduces a new functionality in the Web Access called LightWeight Charting that permits you to do simple charts from the web interface.

That feature is really visible, and you can access it from the web interface of a result of a query


Figure 1: Charts link in query result permits you to access new Charting functionality

To create a new graph you can simply press the New Chart button in the Chart area, and simply choose the field you want to use for grouping and what you want for values, Ex, you want the count of Backlog Item subdivided by Area Path, to have an immediate visual clue of the length of the backlog of two different teams of a project.


Figure 2: Creating chart is really simple.

Once the Chart is created it is saved and it will be always visible in the chart part of the query. Actually it permits only to use the Count of Work Items as Values, but we expect in future release to being able to do other operations, as summing up values of certain columns.

Charts supports basic Pivot tables, Es: you can create a table to show you number of work item for each member group subdivided by Area Path.


Figure 3: A simple pivot Table

Once chart are saved they are always visible in the chart pane of the query, remember that actually you cannot create chart for Tree or Direct Link query types, and you can only use flat queries.


Figure 4: Saved chart will appear on the chart tab.

Remember that this feature is still at preview level, so you can expect more feature to come in future sprint releases.

Happy TF Service.

Gian Maria.

Manage Symbol server on Azure (or on-premise) VM and TF Service

One of the coolest capabilities of Team Foundation Server Build is the ability to automatically manage a symbol server. Suppose this scenario: you have a library and you want to distribute to all people in your organization, with the ability to being able to debug code in the dll and to identify the code that build each version of this dll. If you have TF Service you can use a VM in azure, but the overall process is really similar if you want to have a build on-premise.

  • Enable the File and storage service Server Role (to enable sharing)
  • Enable the Web server role
  • Install Team Foundation Server express Update 3

Once everything is in place you can simply create a local folder and share in read / write, my machine is called TfsSymbolServer so the folder will be \\tfssymbolserver\symbols


Figure 1: Share a folder in Read / write mode

Now you should simply configure Team Foundation Server express build server to connect to your TF Service account. The express version is free and you can install on your VM with few clicks. The necessary steps are identical if you are installing the Build Server on-premise.


Figure 2: Build controller and agent correctly configured for my TF Service account

Now you should create a TFS Build to release your library and automatically publish symbols on previous network share. In the Build Defaults choose your new Build Controller you’ve installed in the VM and ask to copy the Build Output to the server


Figure 3: Configure the build defaults

In the Build Process you can now simply choose the item you want to publish (with all desired configurations), and choose to index sources, specifying the network share you created in the Virtual Machine. That network share is not visible outside that VM, but since the build controller and the share are on the same machine, you will have no problem during the build. Even if the machine is on azure and it is not connected to any VPN, the build will succeed because the publish symbol share is local.

 If everything is on-premise, you can clearly use any network share that is visible from the machine with the Build Agents.

Another interesting aspect of the build, is the use of a different build process template used to version assembly and taken from the TFS Versioning library on codeplex. That build process is used to give to the assemblies a unique FileAssemblyVersion, where you usually specify Major and Minor, and the template will add the date as julian and the incremental number of the build. You have plenty of documentation if you download from the project site []


Figure 4: Build process, index the source and use TfsVersioning to version assemblies

Now that everything is in place you can fire a build an verify in the Virtual Machine that the Symbols directory have symbols file in it.


Figure 5: Symbols files are correctly published in the local share

If the VM with the Build Agent is on-premise, you have nothing to do, because people will have access to the same network share used by the build Agent, but if the VM is on Azure, people are not able to see network share.

To share symbols with the team, the simplest solution is creating a site in IIS that points to symbols directory and enable the directory browsing. An alternative approach is creating a Vpn from the Azure VM and your local directory, but IIS is simpler to setup and to manage and it is my preferred solution.


Figure 6: Symbol server is now publishing the symbol directory to the web with IIS

I’ve chosen port 27000 to bind the site, so I needed to both open the local firewall in Windows Server and adding an endpoint in the Virtual Machine Endpoints from the Azure Web Portal. You should now verify that you are able to connect to that site from your local machines of your organization


Figure 7: Symbol server is now exposed in Http

Now you can simply configure Visual Studio to access that symbol server and to enable symbol server support during debugging.


Figure 8: Your symbol server is now configured in Visual Studio


Figure 9: General configuration for the Debugging in Visual Studio to enable source server support

Now you can simply tell to all members of your teams, interested in using this library, that it is published through standard TFS Builds. You can give to people the address of the Drop Location (it is a zip stored in Azure Blob) for stable builds and this is everything you need to do to distribute your Dll. You can put in place more complex scenario, Es distributing with Nuget or in Source Control, but the important aspect is that the dll has a specific number that identifies it, and it has symbol server support.


Figure 10: People can download the library as a zip directly from the build.

The technique used to distribute the Dll is not important, what is important is that, once you create a project and reference that dll, you are able to drill down with F11 in the methods of the dll, and Visual Studio will connect to the Symbol Server, check the version of the file, and will download the correct version directly from TFS.


Figure 11: When you press F11 Visual Studio correctly download the correct version from TFS

If you look at the complete file location of Figure 11, you can notice the number 1046 preceding file name. If you wonder what it means, it is the changeset id of the version of the file that was included in the dll you are using.


Figure 12: MyLogLibrary.cs latest modification was done in Changeset 1046

This means that Visual Studio not only downloads automatically the file from TFS to enable debugging the library, but it always grab the exact version used to compile the dll.

Thanks to TFS Versioning tool you are also able to tell the exact version of the dll you are using, and you can find the build used to create that dll.


Figure 13: File Version Number helps you identify date and build number used to produce the dll

Symbol server is not useful only to distribute library; you should always use, especially to create binaries that will get distributed and installed, because thanks of the source server support you will be able to debug them or to effectively use Intellitrace in production.

Remember also not to delete builds associated to published dll, or to choose not to delete information from Symbol Server.

If you are not using Symbol Server to distribute your software you are losing a big piece of TFS.

Gian Maria.

Windows 8.1 preview is available, how can I Build with TFS?

Now that Windows 8.1 preview is available, people start to think how they could compile W8.1 solutions with TFS. If you use TF Service you need only to enable a new Build Controller in preview, that is enabled to build 8.1 solutions.


Figure 1: Enable the Windows 8.1 Preview Build controller on your TF Service account to build Windows 8.1 applications

It is simple and easy. Now you should only assign the right controller when creating build definition.

Gian Maria

Visual Studio Tools for Git, a primer

If you installed Update 2 CTP 4 (now it has go-live and supports upgrade to RTM) you should also install the Visual Studio Tools for Git that permits to work with Git repository directly from a Team Explorer extension. You can work with GitHub or whatever Git hosting you like and surely you can work with TF Service Git based Team Project. Once you have a Team Project based on Git you can simply to to the Source tab, and grab the url of the repository.


Figure 1: How to find the url of the Git repository from web interface

You can now copy the url, of you can simply compose id based on this scheme: Once you have a link to the project you can use Visual Studio tools for Git to clone it into a local repository. From Figure 1 you can see a couple of interesting links: the first one link directly to the setting page to setup alternate credentials (you will need it if you plan to work with standard git tooling, like command line) to enable access from all the tools that have no idea how to autenticate to TF Service with federation. The second link is a simple link to an help page that explain how to clone a Git Repository.

If you plan to use Visual Studio integration, you can simply connect to the team project with the new Connect icon and once connected it will prompt you with a simple link to clone the repository


Figure 2: Once connected to the Team Project VS lead you to clone the repository.

Now that the repository is cloned correctly you can create a new solution, or open existing one if you cloned a non-empty repository and you start working as you were working with standard TFS Source control. If you modify a file Visual Studio will inform you with standard icon for modified filed


Figure 3: Source control integration will show you modified file as usual even if the repository is git

If you go to the home page of Team Explorer you should see a different UI, reflecting the fact that the repository is Git and not standard TFS VCS. Pressing Changes link you are presented with the list of modified files ready to be committed.


Figure 4: Changes bring you to an equivalent of the standard pending-changes window

This will open a standard UI that shows all modified files, untracked file (files that are in folder, but not added to source control), you can simply type a comment and press Commit.


Figure 5: Standard VS UI to commit changes to local repository

If you press the link Commit from the Team Explorer Home (Figure 4), the UI will show all local commit that are not synchronized to the remote repository.


Figure 6: Local commits that needs to be pushed to central repository

Now you need to pay lot of attention to the user associated to the commit, as you can see in Figure 6, commit is made by user alkampfergit and my profile picture is missing. This happens because I already installed Msysgit and configured it to access my github repositories. To verify your current configuration you can simply open a Git Bash (you need to install Msys git), and issue a

git config –global –list

You should keep care of a couple of settings: and, in my system they correspond to my profile in github, because I’ve already installed and configured git, Visual Studio is actually using those credentials and this is not so good. You can fix this going to settings from the home of Team Explorer and choose to change git settings


Figure 7: Git settings in Visual Studio

Now the problem is that VS will overwrite your global settings, and this can be a problem if you still work with github repositories, where I want to use Github username. The obvious solution is, configuring global settings with the user you use in most of your projects, and change locally for all other repositories. To do this, simply open a Git Bash on the folder where you cloned your TF Service Git project and change settings locally

git config–local alkampfer

git config –local

Now you can do another commit, to verify that this time the user is correct.


Figure 8: Using correct user will show your profile picture.

Once you are ready to move all your changes to TF Service, you can simply press the Push button (Figure 8) to push all of your changes to TF Service. Now you can go to Web Interface to verify that your commits are correctly pushed to the server


Figure 9: Your commits were correctly pushed to the server

As you can see from Figure 9, first commit has no picture image, because it is associated to my github user. This can puzzle the inexperienced git user, because some people complain for this behavior because, after all, to push to TF Service git repository I need to use my TF Service credentials, so why git is using credentials from config instead of authentication ones? The answer is simple, in a distributed source control, the identity is used to push, but I can push commits that originated in another repository of another developer. This is clear if you go to the commits page of the web interface and have a look at commit detail.


Figure 10: Commit details

From the details you can see that there are three pieces of information, the user that authored and commited is taken from git config, and push operation carry the credential used to connect to the repository. Suppose this scenario, you have your project in TF Service Git repository, cloned in your machine and ask to another developer, that has no access to TF Service account, to contribute on a feature. He will clone from your local repository, helps you to create the feature, commits to your repository (with his username and email) and then his commits will be pushed by you bach to TF Service, but clearly his commits are not associated to any TF User.

Always remember, whenever you clone a git repository, to configure locally username and email if it is different from the standard one you configured in global git configuration. Your repository will be clearer.

Gian  Maria.

Remove git-tf tracked branch after a move from standard TF Service project to Git enabled project

In a previous post called “Move a TFService source contorl to TF Service Git based Team Project” I explained how to simple move sources from a standard TF Service project to another one based on Git. Now after a push if I issue a log I got this.


Figure 1: Origin_tfs/tfs branch in my log?

It seems that there is a remote branch called origin_tfs/tfs but it does not get listed in the list of remote branches from the Web Ui, this because that branch was related to git-tf operations.


Figure 2: Remotes/origin_tfs/tfs branch showed by a branch –a command

Since that branch is not needed I want to remove it, so I first issue a simple git branch -r to understand the list of remote-tracking branches. Now I can simply decide to delete the remote-tracking branch because I do not need it anymore


Figure 3: Deleting the remote tracking branch.

Gian Maria.