Blog

Changing the Default CheckIn Action in TFS

04 Jul, 2015
Xebia Background Header Wave
Tweeten

For some weeks ago, I had a team ask me if it was possible to change the default CheckIn action for relating a work item to a check-in in TFS. After finding different solutions, I thought it would be helpful to share with you the different options I found.

So what’s the problem?

As you will know, when you want to relate a work item with your check-in in TFS, you have to choose between two CheckIn actions: Associate or Resolve. The first one, Associate, is used to just link the work item with the future changeset. The second one, Resolve, also automatically closes the work item on check-in.

Figure 1 - Default CheckIn action is Resolve
Figure 1 – Default CheckIn action is Resolve

By default, your Visual Studio client will select the Resolve action on check-in. For some situations this is very helpful. However, when you want to use the Associate action most of the time, it is very annoying and inefficient to change the CheckIn action each time you check-in. A solution for this is to change the default CheckIn action to Associate. But how to achieve this?

The solutions

There are two solutions for changing the default CheckIn action to Associate:

  1. Server side – Remove the Resolve action from the different work item types

The first solution is to remove the Resolve action out of the different work item types in your Team Project. This can be achieved by removing the Check-In actions (in XML marked by the <ACTION value=”Microsoft.VSTS.Actions.CheckIn”/> element) from the different transitions in your work item types, by using the TFS Power Tools Process Editor or an appropriate XML editor.

Figure 2 - Removing the Checkin action from the work item type XML
Figure 2 – Removing the Checkin action from the work item type XML

Note: when choosing for an appropriate XML editor, don’t forget to import the changed work item types into your team project.

Based on the process template of your Team Project, you have to possibly change the following work item types:

SCRUM TemplateAgile TemplateCMMI template
  • Code Review Request
  • Task
  • Bug
  • Code Review Request
  • Issue
  • Task
  • User Story
  • Bug
  • Change Request
  • Code Review Request
  • Issue
  • Requirement
  • Task

The main advantage of this solution is that it solves the problem server side, so you’re done in one go for all Visual Studio clients that connect with your Team Project. However, there are also some disadvantages with this solution. The most important one is that the different Visual Studio users are not able to use the Resolve action anymore. Other cons are:

  • You need at the least the Project Administrator role to make this changes.
  • You make changes in the default process templates that are delivered by Microsoft. The more customizations you have in your process template, the greater the effort you have to spent on future process template synchronizations.
  1. Client side – Changing the ResolveAsDefaultCheckinAction value in the registry

Another solution is to change the ResolveAsDefaultCheckinAction string value in the registry to false. This needs to be changed on all the different client machines, for all different versions of Visual Studio, and will change the default check-in action in Visual Studio to Associate. The big advantage of this solution is that it is still possible for users to select the Resolve action on check-in.

Figure 3 - Changing the ResolveAsDefaultCheckinAction string value in the registry
Figure 3 – Changing the ResolveAsDefaultCheckinAction string value in the registry

To change this behavior for your Visual Studio client, you have to change the ResolveAsDefaultCheckinAction string value in one of the following registry keys:

VS2010 - HKCU:SoftwareMicrosoftVisualStudio10.0TeamFoundationSourceControlBevavior
VS2012 - HKCU:SoftwareMicrosoftVisualStudio11.0TeamFoundationSourceControlBehavior
VS2013 - HKCU:SoftwareMicrosoftVisualStudio12.0TeamFoundationSourceControlBehavior

After making this change in the registry key, you have to restart all your Visual Studio instances. If the changes are not picked up by your Visual Studio client, execute devenv /setup from the Visual Studio Developer Command Prompt to force Visual Studio to pick up the new registry settings. When everything went well, you will see the Associate action been selected by default.

Figure 4 - Default CheckIn action is Associate
Figure 4 – Default CheckIn action is Associate

The big advantage of this solution is that you do not change the process template. Other advantages are:

  • Users are still able to make use of the Resolve action;
  • Each user can choose for his own default CheckIn action;

The disadvantages of this solution are:

  • For some Visual Studio clients prior to Visual Studio 2012, this solution will not work.
  • Each time you install a new major version of Visual Studio on your client machine, you have to change the ResolveAsDefaultCheckinAction string value in the registry key to change the default CheckIn action for that Visual Studio version.

 Which option to choose?

I advised the team the second solution because it still offers the Resolve action and it does not change the process template. We accepted that the solution is not working for some of the VS2010 users, because we expect VS2010 is been replaced by VS2013 in the near future.

To minimize the second disadvantage of this solution, I have made a powershell script which automatically changes the required registry values. It works for both VS2010, VS2012 and VS2013.

Cornell Knulst
Cornell works for Xpirit, Hilversum, The Netherlands, as a trainer/architect. He is specialized in the domain of Application Lifecycle Management and Continuous Delivery, with a special focus on Microsoft-based technologies.
Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts