Tweaking the TFS Web Access Client

Recently Microsoft released a great usability tweak to the Web Access Client on Visual Studio Online. It allows users to use the rich text editor in full screen mode. This allows users to utilize the most out of their big screens and allows users to have a better editing and reading experience for large text fields, especially when combining images and text. More of these new features can be read here: Work item Improvements

While these features are to be expected to be in the next on premise TFS release, you may like to have similar functionality in your on-premise TFS right now!

Let me start with a disclaimer: The customization’s in this post are not supported by Microsoft. These changes can break any updates and will be undone by any update installations to your TFS environment. 

For all of you accepting this disclaimer the following adjustments will allow you to use the most of your available screen size.

When you currently open a work item from the task board (or most other locations) you will see the following behavior. As the red arrows indicate, there is allot of space available at the edges and the rich text fields do not utilize the space available.

Default Work Item Experience

The steps below guide you to change the default behavior.

1. Download the FullDialog.css from my DropBox. FullDialog.css or

The CSS changes to UI Dialog to be positioned 45px from the top, and to utilize 98% of the available width. For the height it will use 85% of the View Port. Caution this may / will not work on ‘old’ browsers.

Work Item Experience CSS

2. Add the FullDialog.css file to the following directory on your TFS server.

%ProgramFiles%\Microsoft Team Foundation Server 12.0\Application Tier\Web Services\_static\tfs\12\App_Themes\Default\

3. Open the Main.Master file

%ProgramFiles%\Microsoft Team Foundation Server 12.0\Application Tier\Web Services\_views\Shared\Main.Master

4. Add the following line to the indicated location

<link href=”<%:Url.Themed(“FullDialog.css”) %>” type=”text/css” rel=”stylesheet” />

Changes to Main.Master Page
The marked line indicates the location to add the custom CSS file.

5. Execute an IISReset from the commandline. (Mind your step when doing this in a production environment!)

6. Test results! You’re workitem experience is now almost fullscreen and you’re rich text fields will utilize much more space.

Full Screen Work Item Experience
Full Screen Work Item Experience

Additional options, TFS has two UI settings modes available; Default and High contrast. If you do not wish to adjust the Default behavior for all your users you might want to implement this in the High Contrast profile only. This way you provide your users with a choice. These settings can be reached through your User Profile page.

TFS User Profile UI Settings

Post a TFS Team Room Message from Visual Studio Release Management

This is Part 3 in the series on Release Management + PowerShell + TFS TeamRoom API. In this post I am going to utilize the PowerShell Enabled TFS Team Room API logic from a Release Template in Visual Studio Release Management.

I will not cover a ‘usual’ flow that will release an application based on a Team Foundation Server build, if you like more information on this please check out my post covering that here: Release Management with InRelease

Or you can check out my Curation on Release Management here: Getting Started with Release Mangement

In Part 2 of this series I figured out all the PowerShell commands needed to post a message to the Team Room. Now let’s advance.

Visual Studio Release Management allows for creating custom tools. To create a Tool a Custom PowerShell Script can be used, so let’s make a script that can post the message. You can use the PowerShell ISE Editor to create this script.

A little clarification on the script. It has two parameters, TeamRoomMessage and TeamRoomName. I choose not to pass all the TFS configuration to the script, but if you want you can 🙂

After declaring the parameters, the module (Wrapper to the Team Room API) is imported. Then variables are set and the call to the Team Room is made passing the received parameters.


Creating the tool in Visual Studio Release Management is fairly easy. Most important part is adding the PowerShell script as a resource. On the Execution section we specify that the tool is a PowerShell command.

Our script needs two parameters and those need to be passed as arguments to the script. Mind that the parameters are qouted otherwise spaces in the message might break the script.


Having created the tool we need to create an Action to be able to add this to the Release Template. The creation of the Action is quite similar to the creation of the tool.


Having the Tool and the Action ready we can continue to create a very simple Release Path to post a message. The Release Path is using an existing stage (Development) and an existing environment (Development Environment). Acceptance and validation are both set to be automatic. This way no manual actions are required.


Now that we have a Release Path available, we need to create a Release Template. On the Deployment Sequence we drag our target server. Next in to Toolbox we browse to the Custom Section. In the section we can find our Custom Action. Drag this action to the Server surface. It lists the two parameters that our action needs, which now can be provided.


After saving, on the top menu there is the possibility to create a “New Release”, provide it a unique name and our Release Template is pre-selected.


Let go and start the release! After starting the release you will see the Release Progress. As acceptance was set to be automatic, that step is automatically passed. Next the Deploy step is executed, status is Pending.


After a little waiting (posting the message doesn’t take that long) this will transfer to Done.


For the Deploy step there are details available. You can review these by clicking the ‘…’ button. The Deployment Log screen will be shown.


Through the View Log button we can see the log that is created during our ‘Add TeamRoomMessage’ action. The log message contains the output generated in our PowerShell Script. As we can see below it says our message is successfully posted!


The only place to find out if that’s true is to head over to our Team Room and see for our self! As expected the message is there!


As mentioned in the previous posts I promised to all the source code required for this complete series. You can download the source for this here: Release Management –

Please note that this code was written for demo purposes only and is not intended to run on your production environment.

If you have any questions or remarks please feel free to leave a comment or contact me on twitter @jaspergilhuis

Hidden Gems in TFS – Part 12 – Link to Versioned Item

This post is and addition to René van Osnabrugge’s great series of Hidden Gems in TFS. An overview of these Gems can be found at his blog “The Road to ALM” here:

Just last week he showed me something that made me smile. His first response was “this has been around since… (I think we mentioned TFS 2005!!)

So what was it? We were talking on our Product Backlog, when he asked “Didn’t you create a document for that?” I replied “Yes I did!, it’s in source control, the path is in the workitem description”, something like $\Team Project\Folder\Folder\Document.docx.

He looked at me quite surprised and said “Did you know you can link to a Version Controled Item if you want?!”

Hidden Gem 12 - Link to Versioned Item


I thought it was worth a little post 🙂

Guess I will link to Version Controlled Item from now!

Encapsulate Team Room API calls with a PowerShell Commandlet

This post is Part 2 in the three part series on Release Management + PowerShell + TFS TeamRoom APIIn this second post I am going to “PowerShell enable” the TeamRoomService API I created in part 1.

Because i am fairly new to PowerShelll, finding a way to achieve this took few searches and some reading on MSDN. Luckily there is more than enough on it! A good starter is here:

I decided to build from the PSCmdLet functionality while I wanted to preserve properties (remember the TFSURL, TFS UserName and TFS Password for the service?) between possible multiple TeamRoom calls. This saves typing verbose parameters over and over again. To preserve the settings we need to utilize the session state and are therefor required inheriting from the PSCmdLet class.

I decided to create a custom baseclass (PSCmdletBase) to be able to use in the actual Command Lets (Add, Find, Get, Remove). The base class checks if the required parameters are supplied.


Now let’s go create the CommandLet for posting a message. The class will inherit from the PSCmdLetbase. It has two mandatory properties defined. One for the message the other for the Team Room name.


The main method is quite simple, because the TeamRoomService previously created contains all the logic. Below an instance is created, the properties are provided, and the PostMessage method is called.


Having this compiled into a DLL we are ready to get to use it from the PowerShell commandline. Again this took some reading, I started on this page Browsing a little further I came across this page It shows us that we can import a .DLL as a module. Let give that a try.

First open a PowerShell Command window (running as Administrator). Mind that executing command from the PowerShell Console might require additional execution permissions. Please Read about them here

For my demo purposes I set my PowerShell to Unrestricted mode.


Now let’s provide the command to import the module. If all goes well (no visual feedback) its successful. Note I am importing directly from my project output directory.


Now we should be able to call the CommandLet’s “Add-TeamRoomMessage” method. There are several ways of calling it. Remember that we first need to set the required variables!  (I intentionally *** my password, it will be typed in plain text).


Now we are ready to use the CommandLet. We pass the TeamRoom and Message parameters to the command directly and hit enter.


We receive feedback hat we succesfully posted the message with ID 1242.

Now let’s browse to the TeamRoom to see our message! Yes, there it is!


This wraps up part two of this series! In the next and last part of this series we will dive into Visual Studio Release Management to allow us to post the message from there!

Note: The source code will be posted as a complete download with the next post so you get a full working solution.

Utilize the TFS Team Room REST API

Here we go, part 1 of the announced series on Release Management + PowerShell + TFS TeamRoom API!

Based on the publicly available information in Brian Harry’s post on the Team Rooms API ( I decided that I wanted to add messages from Release Management to a particular Team Room.

Disclaimer: The Team Room API is subject to change, this might therefor not work in the future, and this code is just intended for demo purposes, so if you reuse it is at your own risk.

To get started I wanted a quick and easy way to be calling the Team Room API for this I created a service application to encapsulate the Team Room API calls. I had to figure out what the suggested route was to actually talk to the REST API. Popular REST frameworks, encapsulating the actual JSON plumbing, seem to be RestSharp ( and NewtonSoft JSON ( Both can be included in your solution as NuGet packages.

Wanting to post a message I needed a TeamRoomService. This service needs a method, LoadTeamRooms(). This method uses the RestClient Object to call the Team Room API. While using the API the Team Project needs to enable Alternate Credentials. See the following URLS for more information on the neccesarry actions to enable this.

The LoadTeamRooms method lists all Team Rooms available. As you can see it requires some parameters to be able to connect to TFS. JSONConvert is used to parse the received Team Room API results.

Load Team Rooms

Using a Test Project I could easily get the properties from a configuration file.  My TeamRoomService accepts the properties. The TeamRoomServiceGetTeamRooms() method gets the rooms. The results are then places in an object that allows me to access them more easily.

Create Team Room Service

Running the tests and adding some watches I could easily validate I was on my way!

Debug Team Room

Being able to get the available Team Rooms I wanted to be able to find a specific one, re-using my earlier code this was quite simple. Please note my unit test has an if that validates my findings on either on-premise TFS or Visual Studio Online TFS instances.

Find Team Room

In both scenarios this enabled me to find a specific Team Room. Having found the Team Room ID, I was able to use the PostMessage method on the Team Room API.

Post Message

This calls the Post Message method of my TeamRoomService. This method calls the Team Room API Service to post a message. When successful it returns the ID of the posted message.

Post Message API

So lets check the Team Room for our message! Voila there it is!

Team Room Message

Having you walked through the basis of my components we are able to utilize the Team Room API to post a message. In the next part I will take you to the next phase encapsulate this TeamRoomService in a PowerShell Commandlet.

Note: The source code for this will be posted as a complete download with the latest post of this series so you get a full working solution at once!

Blog Post Series announcement on Release Management + PowerShell + TFS TeamRoom API

Blog Post Series announcement on Release Management + PowerShell + TFS TeamRoom API

In a new series of posts I will be getting more out of the combination of Visual Studio Release Management + PowerShell + TFS TeamRoom API. The series will consist out of 3 posts that wrap it all together.

  1. Utilize the TFS Team Room REST API.
  2. Encapsulate Team Room API calls with a PowerShell Commandlet
  3. Post a TFS Team Room Message from Visual Studio Release Management

First post will come shortly! Stay tuned!

Update 1: Posted part one on 18 februari 2014
Update 2: Posted part two on 23 februari 2014
Update 3: Posted part three on 28 februari 2014

Release Management and PowerShell

A few weeks ago I wrote a (long) post on InRelease, since it has been released on November 13th, it is now officially called Release Management.

Release Management comes packed with useful Tools, Actions and the ability to create Components. With these items you can really shape your ReleasePath to your needs. But it could happen that there is something you want to achieve that is unavailable.

While there are several other options available in preparing your Web solution for deployment with Release Management, I recommend reading Colin Dembosky’s post on Web Deploy and Release Mangement – the proper way, I want to explore PowerShell options. Another option would be using the Tokonization functionality (not checked this against the Release Management release).

The following steps will guide you through the process on calling a custom PowerShell action from your Release Template.

Disclaimer: I am a PowerShell newbie, so there probably are more powerful or optimized scripts possible…

1. Lets create a PowerShell Script for your desired actions. Using the PowerShell ISE Editor will help you in getting the syntax right.

2. Lets create a very basis script first. Containing all hard-coded raw materials. Test the script to see if you got all the syntax and desired outcome. In this case, ‘BlogEngineData’ is replaced by ‘BlogEngineDEV’.





3. Now we have a functional script, lets add some parameters, so we enable reuse of the script. Validate the script by executing it.




4. Now open [Release Mangement], navigate to [Inventory] and then [Tools]. Then create a new [Tool]. The tool is capable of executing the powershell script, that will be added as a resource.








Notice that in the [Arguments] options we use the Release Management parameter syntax ‘__Parameter__’ (yes that is two! underscores to start and end with). All recognized parameters are listed in the Parameters section. For our script that is four.

5. Make sure you upload the PowerShell script as a Resource. Find my sample PowerShell Script here

6. To be able to use a [Tool] you need to create an [Action], so navigate to the [Actions] section within the [Inventory] and create a new [Action]. Follow the options below and you will be OK.

Tip: Create a Category for your ‘Custom’ actions. This will help you in adding them to the Release Template.








7. Now we have a new Tool and Action we are ready to use it on our Release Template. Navigate to [Configure Apps], [Release Templates] and open a template. Find your ‘Custom’ Action, drag it to the canvas, and fill all the properties.









8. Repeat this for all your Environments / Templates.

The Release Template is now ready to be used! With this example I hope to show the potential of using a custom PowerShell script to extend the Release Management Toolbox.

Happy Releasing!