Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Custom TFS Check-In Policy in Visual Studio 2017

A while ago I developed a custom TFS check-in policy that was working fine with Visual Studio 2015. Now I installed Visual Studio 2017 and wanted to register the check-in policy assembly the same way as I did with VS2015 before. But this does not work. How can I register custom check-in policy assemblies with VS2017?

For VS2015, I had these registry keys:

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\TeamFoundation\SourceControl\Checkin Policies]
"MyCheckInPolicy"="C:\\Program Files\\My\\MyCheckInPolicy.dll"

and

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\14.0_Config\TeamFoundation\SourceControl\Checkin Policies]
"MyCheckInPolicy"="C:\\Program Files\\My\\MyCheckInPolicy.dll"

and accordingly I added those keys for VS2017 (15.0):

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\15.0\TeamFoundation\SourceControl\Checkin Policies]
"MyCheckInPolicy"="C:\\Program Files\\My\\MyCheckInPolicy.dll"
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\15.0_Config\TeamFoundation\SourceControl\Checkin Policies]
"MyCheckInPolicy"="C:\\Program Files\\My\\MyCheckInPolicy.dll"

But unfortunately this does not work:

  • If I open the Team Project SourceControl settings, go to the "Check-in Policy" tab and try to Add... a policy, MyCheckInPolicy does not appear1
  • If I open the team project that uses this check-in policy already and do the above, I got an error message telling me that the assembly (mycheckinpolicy) "has not been registered".

Of course I restarted the IDE after the registry change, but even rebooting my machine did not help.

The information I found so far seems to suggest that check-in policies now have to be part of an extension (vsix), which I don't want to believe.


I guess that the problem comes from some references that cannot be resolved when the assembly is loaded into the IDE.

The MyCheckInPolicy project references the Microsoft.TeamFoundation.VersionControl.Client.dll v14.0 from the VS2015 folder C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer.
I tried to reference the respective dll from the VS2017 folders, but then the assembly does not work in both IDEs.

I also tried to use the Nuget package "Microsoft.TeamFoundation.VersionControl.All" v12.0.30723.2 instead and deployed all files from the output directory (which seem to contain all assemblies of the package) to the location mentioned in the registry keys. This had the same result: the policy cannot be loaded in neither VS2015 nor VS2017.

We are using TFS 12.0.30723.0.


1So it seems VS2017 doesn't even try to load the assembly and does not care about the registry keys?

like image 546
René Vogt Avatar asked Mar 21 '17 09:03

René Vogt


2 Answers

In Visual Studio 2017 there are breaking changes to extensibility. Much of the registry configuration has been moved into a "private" registry:

To reduce the impact on the registry, Visual Studio now uses the RegLoadAppKey function to store registry keys in a private binary file under %VsAppDataFolder%\privateregistry.bin. Only a very small number of Visual Studio-specific keys remain in the system registry. (link)

By defining the registry keys as part of a .pkgdef file in a vsix, on installation VS 2017 will (I assume) write the keys to the private registry as opposed to the actual registry, which was the case in previous versions of VS. This will allow the policy to be picked up.

So, here are the steps I went through to get our policies working in VS 2017:

  1. Install the Visual Studio SDK (can be done by modifying your installation if you didn't select the workload originally).
  2. Add a new VSIX Project to your checkin policy solution
  3. Add a .pkgdef file to the VSIX project with the following (this is the registry key entry):

    [$RootKey$\TeamFoundation\SourceControl\Checkin Policies] "YourPolicy"="$PackageFolder$\YourPolicy.dll"

  4. Modify source.extension.vsixmanifest (using the GUI wizard) in the VSIX project:

    1. Install Targets: Add your lowest supported VS Version:
      • Microsoft.VisualStudio.Community [15.0,16.0)
      • Microsoft.VisualStudio.IntegratedShell [15.0,16.0)
    2. Assets:
      • Microsoft.VisualStudio.Assembly
        • A Project in current solution
        • Project: Select your checkin policy project
      • Microsoft.VisualStudio.VsPackage
        • File on filesystem
        • Path: Select your .pkgdef file from step 3.
    3. Prerequisites: Visual Studio core editor [15.0,16.0)
  5. Build the VSIX project and distribute/install the generated vsix

This GitHub repo was helpful for piecing everything together. Some quirks I found when migrating to the vsix:

  1. By default, vsix installations are now per-user. If you operate VS under multiple users on the same machine you will need to install it for each. There is an option in the vsixmanifest to have the extension installed for all users, but this requires elevation.
  2. Our checkin policy used an app.config file, which is not supported in a vsix. I had to migrate our settings to a .settings file.
like image 96
Pero P. Avatar answered Sep 18 '22 09:09

Pero P.


It worked to me adding this key to HKCU:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\15.0\TeamFoundation\SourceControl\Checkin Policies

Hope it helps. Thanks, Wilsade

like image 43
Wilsade Avatar answered Sep 20 '22 09:09

Wilsade