Thursday, April 21, 2011

Custom Check-in Policies for TFS 2010

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.

 Add Policy Dialog
Figure 1: Add Check-in Policy Dialog

Active 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.

zippedFile
TeamFoundation.CommentPolicy.zip

 

Logo 60x50

Monday, April 11, 2011

TFS & VS 2010 and the Database Developer

 

I was working at a client last week, giving them an overview of Database Development using Visual Studio 2010 Database Professional (DBPro). They mentioned the TFS Provider for SQL Server Management Studio (SSMS) and their attempts in trying work with it.

It had been a couple of years since I looked at it last (honestly before DBPro was released). You can download (it’s free) the plug in from here (created by the famous Martin Woodward). I noticed that it had in fact been updated to work with TFS 2010. So I decided to give it a spin.

Firstly I must highlight one of the (in my opinion) less know features in SSMS, you can create and manage projects in pretty much the same way you do in Visual Studio.

After installing the TFS Provider, make sure that SMSS knows that you are using a Source Control plugin. Select Tools | Options. Select “Source Control” and if it has not already updated, change the current plug-in to “Team Foundation Server MSSCCI Provider”.

Team Foundation Server MSSCCI Provider

Now select the File | New | Project menu option and a pretty familiar looking dialog will appear

image

Once the project has been created open up the “Solution Explorer” ( View | Solution Explorer ) and the project layout is shown

image

Right click on the “project name” and select Add | New Item. Notice that you start to get the same experience as you would in Visual Studio. You have the ability to add a number of “different” items to the project. Different categories have different templates etc..

image

And now with the Source Control plugin you can add this “Solution” or “Project” to source control (as you would a Visual Studio Project) and perform source control related check-in’s and outs, view history, compare etc. etc..

Using SSMS you still do use scripts to manage your “database”. If you only have access to Visual Studio 2010 Professional (or not at all) then this is possibly an option to evaluate (you still would need a TFS CAL).

Both SSMS and DBPro use scripts to manage your schema (DBPro has a nice “schema view” that shows you the database schema represented via scripts though), BUT with all the additional functionality that DBPro offers, including database comparisons, unit testing and data generation, I definitely prefer DBPro.

 

Logo 60x50