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:
MyCheckInPolicy
does not appear1
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?
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:
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"
Modify source.extension.vsixmanifest
(using the GUI wizard) in the VSIX project:
Microsoft.VisualStudio.Community [15.0,16.0)
Microsoft.VisualStudio.IntegratedShell [15.0,16.0)
Visual Studio core editor [15.0,16.0)
This GitHub repo was helpful for piecing everything together. Some quirks I found when migrating to the vsix:
.settings
file.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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With