I was showing a demo to a client on custom policies the other day. We went through a couple of caveats that exists between the TFS 2008 and TFS 2010 way of doing things.
If you look long enough you will find specific posts or conversations on individual issues. I decided to do a post that encompasses these issues, and a couple of my findings while creating these custom policies in TFS 2010.
Creating the custom policy is fairly straight forward. Using Visual Studio, create a new class library and add a reference to “Microsoft.TeamFoundation.VersionControl.Client.dll”.
Next create the class that you will be using and inherit from “Microsoft.TeamFoundation.VersionControl.Client.PolicyBase” and implement the methods. You should have something like this:
using Microsoft.TeamFoundation.VersionControl.Client;
namespace TeamFoundation.CommentPolicy
{
public class CommentWordCountPolicy : PolicyBase
{
public override string Description
{
get { throw new System.NotImplementedException(); }
}
public override string Type
{
get { throw new System.NotImplementedException(); }
}
public override string TypeDescription
{
get { throw new System.NotImplementedException(); }
}
public override bool Edit(IPolicyEditArgs policyEditArgs)
{
throw new System.NotImplementedException();
}
public override PolicyFailure[] Evaluate()
{
throw new System.NotImplementedException();
}
}
}
The “Type” property can be related to the friendly name of the policy. Interestingly enough, the “TypeDescription” property is the description shown on the “Add Check-in Policy” dialog (Figure 1), and the “Description” property is the description shown in the description column of the “Check-in Policy” tab (Figure 2) when the policy is selected.
Figure 1: Add Check-in Policy Dialog
Figure 2: Check-in Policy Tab
The “Edit” method is where you would handle any custom configuration that you may require. This method is executed before the policy is added to the list in figure 2 and when you click the “Edit” button while the policy is highlighted in the Check-in Policy tab (Figure 2). Note that if you return “false” in this method the policy will not be added to the active list. In addition, the “PolicyBase” class has a property “CanEdit” that you can override manually. If you return false for this property the “Edit” method will not be executed and the “Edit” button next to the list in figure 2 will be disabled.
Next up is the “Evaluate” method, this is where all the magic happens. You have access to the protected property “PendingCheckin” which provides pretty much all the information that you would need to devise some weird and wonderful policies. If the “Evaluate” method returns an array containing a valid instance of a “PolicyFailure” class, the check-in will show you the policy violation.
So once you have populated the properties and methods accordingly the next point is of utmost importance. You must mark your class as Serializable. If you do not, your new policy will simply not show up in the available policies list.
Next up you need to register the policy in the registry under the following path: [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Checkin Policies].
Create a new String Value with the name of the assembly that contains your policy excluding the .dll extension and the value being the full path to your assembly. Example :
Name: TeamFoundation.CommentPolicy
Value: C:\Projects\Policies\TeamFoundation.CommentPolicy.dll
This should complete the steps to create and register a new check-in policy. The only thing left is to deploy the policy on each workstation that is to adhere to the policy. If you do not do this an error will be displayed that the policy is not installed, and it will be disregarded. The TFS 2010 Power Tools however have a “new” way of deploying these assemblies, but it is still up to the developer to opt in to the deployment mechanism.
TeamFoundation.CommentPolicy.zip
