Compatibility of Check-in Policies between Whidbey and Orcas

Team Foundation Version Control provides an extensible check-in policy framework to configure and run validation rules before checking in source code. There are many posts that explain how to configure built-in policies as well as install custom ones (refer, for example, https://www.edwardbakker.nl/PermaLink,guid,8600ae36-f9c9-4e1f-b91e-63a469b6346e.aspx and https://www.codeplex.com/VSTSGuidance/Wiki/View.aspx?title=How%20to%20create%20a%20custom%20check-in%20policy&referringTitle=Source%20Control%20Practices%20at%20a%20Glance).

 

I recently helped an internal user with policy compatibility issues between Whidbey and Orcas, and felt that this information may be of interest to others. Check-in policies configured on a Team Project having a mix of Whidbey and Orcas Visual Studio (VS) projects will work cleanly with Whidbey and Orcas clients. The complete information is presented below. A quick recap of how check-in policies function will aid in understanding what follows. Check-in policies are configured on a Team Project basis on the server. The configuration information stored on the server includes the policy type and name of the assembly that implements the policy. But it does not include the path to this assembly on the client machine, which is client specific information. This is obtained from the registry. The Whidbey client locates the assembly path from the 8.0 registry hive (Software\Microsoft\Visual Studio\8.0\Team Foundation\Source Control\Checkin Policies), while the Orcas client locates it from the 9.0 hive.

 

Check-in policies are source compatible but not binary compatible. Hence for Orcas they will have to be recompiled against the 9.0 version of Team Foundation Client (TFC) assemblies. The 8.0 version will only work with Whidbey and the 9.0 version with Orcas. Installing an 8.0 compiled policy with Orcas and trying to load it will result in the error Unable to cast object of type ‘XXXX’ to type ‘Microsoft.TeamFoundation.VersionControl.Client.IPolicyDefinition’. There are several blogs about this VS error, which occurs when an assembly that is being loaded is linked to an older version of a dependent assembly than what VS is linked to.

 

At the same time, even though the policy has to be recompiled with the 9.0 TFC assemblies and installed on the client, it does not have to be configured again on the same Team Project. As stated earlier, the policy configuration information stored on the server includes the policy type and assembly name which must match. But the path to the assemblies on the client will be obtained from the registry. The Whidbey client will locate the 8.0 policy from the 8.0 registry path, while the Orcas client will locate the 9.0 policy from the 9.0 hive.

 

So in summary, (i) recompile Whidbey policies for Orcas, making sure that the assembly name is the same, (ii) install the assembly by copying it to a location different from the 8.0 version and setting the 9.0 registry accordingly.

Comments

• Anonymous
  May 26, 2007
  Team Foundation Version Control provides an extensible check-in policy framework to configure and run