Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
134 views
in Technique[技术] by (71.8m points)

c# - 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_MACHINESOFTWAREWOW6432NodeMicrosoftVisualStudio14.0TeamFoundationSourceControlCheckin Policies]
"MyCheckInPolicy"="C:\Program Files\My\MyCheckInPolicy.dll"

and

[HKEY_CURRENT_USERSOFTWAREMicrosoftVisualStudio14.0_ConfigTeamFoundationSourceControlCheckin Policies]
"MyCheckInPolicy"="C:\Program Files\My\MyCheckInPolicy.dll"

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

[HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoftVisualStudio15.0TeamFoundationSourceControlCheckin Policies]
"MyCheckInPolicy"="C:\Program Files\My\MyCheckInPolicy.dll"
[HKEY_CURRENT_USERSOFTWAREMicrosoftVisualStudio15.0_ConfigTeamFoundationSourceControlCheckin 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.0Common7IDECommonExtensionsMicrosoftTeamFoundationTeam 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?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

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$TeamFoundationSourceControlCheckin 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.

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...