Пользовательская политика регистрации TFS в Visual Studio 2017

Недавно я разработал собственную политику проверки TFS, которая была отлично работает с Visual Studio 2015. Теперь я установил Visual Studio 2017 и хотел зарегистрировать сборку политики проверки так же, как и с VS2015 раньше. Но это не работает. Как я могу зарегистрировать собственные сборки политики проверки с помощью VS2017?

Для VS2015 у меня были следующие ключи реестра:

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

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

и соответственно я добавил эти ключи для 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"

Но, к сожалению, это не работает:

Если я открою настройки Team Project SourceControl, перейдите на вкладку "Политика регистрации" и попробуйте Add... политику, MyCheckInPolicy не появится ¹
Если я открою командный проект, который уже использует эту политику регистрации, и я сделал сообщение об ошибке, сообщающее мне, что сборка (MyCheckInPolicy) "не была зарегистрирована".

Конечно, я перезапустил IDE после изменения реестра, но даже перезагрузка моя машина не помогла.

информация Я обнаружил, что до сих пор кажется, что политики проверки теперь должны быть частью расширения (vsix), которое я не хочу верить.

Я предполагаю, что проблема связана с некоторыми ссылками, которые невозможно решить, когда сборка загружена в среду IDE.

Проект MyCheckInPolicy ссылается на Microsoft.TeamFoundation.VersionControl.Client.dll v14.0 из папки VS2015 C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer.
Я попытался ссылаться на соответствующую dll из папок VS2017, но тогда сборка не работает в обеих IDE.

Я также попытался использовать пакет Nuget "Microsoft.TeamFoundation.VersionControl.All" v12.0.30723.2 вместо этого и развернул все файлы из выходного каталога (который, кажется, содержит все сборки пакета), в указанное в ключи реестра. Это имело такой же результат: политика не может быть загружена ни в VS2015, ни в VS2017.

Мы используем TFS 12.0.30723.0.

¹ Итак, похоже, VS2017 даже не пытается загрузить сборку и не заботится о ключах реестра?

Ответ 1

В Visual Studio 2017 есть нарушение изменений в расширяемость. Большая часть конфигурации реестра была перенесена в реестр "private":

Чтобы уменьшить влияние на реестр, Visual Studio теперь использует Функция RegLoadAppKey для хранения ключей реестра в частном двоичном файле в разделе% VsAppDataFolder%\privateregistry.bin. Только очень небольшое число ключей Visual Studio остаются в системном реестре. (ссылка)

Определяя ключи реестра как часть файла .pkgdef в vsix, при установке VS 2017 будет (я полагаю) писать ключи в частный реестр, в отличие от реального реестра, что было в предыдущих версиях VS. Это позволит подобрать политику.

Итак, вот шаги, которые я прошел, чтобы наши политики работали в VS 2017:

Установите SDK Visual Studio (можно сделать изменение вашей установки, если вы не выбрали рабочую нагрузку изначально).
Добавьте новый проект VSIX в ваше политическое решение для проверки.
Добавьте файл .pkgdef в проект VSIX со следующим (это запись в разделе реестра):

[$RootKey$\TeamFoundation\SourceControl\Checkin Policies] "YourPolicy"="$PackageFolder$\YourPolicy.dll"
Измените source.extension.vsixmanifest (используя мастер GUI) в проекте VSIX:
- Установка целей: добавьте свою самую низкую поддерживаемую версию VS:
  - Microsoft.VisualStudio.Community [15.0,16.0)
  - Microsoft.VisualStudio.IntegratedShell [15.0,16.0)
- Активы:
  - Microsoft.VisualStudio.Assembly
    - Проект в текущем решении
    - Проект: выберите проект политики проверки.
  - Microsoft.VisualStudio.VsPackage
    - Файл в файловой системе
    - Путь: выберите файл .pkgdef с шага 3.
- Предпосылки: Visual Studio core editor [15.0,16.0)
Создайте проект VSIX и распространите/установите сгенерированный vsix

Это Репо GitHub было полезно для сборки всего вместе. Некоторые причуды, которые я обнаружил при миграции на vsix:

По умолчанию установки vsix теперь доступны для каждого пользователя. Если вы используете VS под несколькими пользователями на одном компьютере, вам нужно будет установить его для каждого. В vsixmanifest есть опция для установки расширения для всех пользователей, но для этого требуется повышение.
В нашей политике проверки использовался файл app.config, который не поддерживается в vsix. Мне пришлось перенести наши настройки в файл .settings.

Ответ 1

Ответ 2