Niestandardowe zasady kontroli TFS w Visual Studio 2017

Question

Jakiś czas temu opracowałem niestandardową politykę odprawy TFS, która była działająca dobrze z Visual Studio 2015. Teraz zainstalowałem Visual Studio 2017 i chciałem zarejestrować zestaw reguł dotyczących odprawy w taki sam sposób, jak wcześniej w VS2015. Ale to nie działa. Jak mogę zarejestrować zestawy niestandardowych reguł odprawy za pomocą VS2017?

Dla VS2015, miałem te klucze rejestru:

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

i

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

a zatem ja dodanych te klucze do 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" 

ale niestety to nie działa:

• Gdybym otworzyć ustawienia Zespół Projektowy SourceControl, przejdź do zakładki "Check-in Polityki" i spróbować Dodaj ... polityka, MyCheckInPolicynie pojawia
• Gdybym otwórz projekt zespołu, który już używa tej zasady check-in i wykonaj powyższe, otrzymałem komunikat o błędzie informujący, że zespół (mycheckinpolicy) "nie został zarejestrowany".

Oczywiście zrestartowałem IDE po zmianie rejestru, ale nawet rebooting moja maszyna nie pomogła.

The information Znalazłem dotychczas wydaje sugeruje, że zasady check-in muszą być częścią rozszerzenia (vsix), w co nie chcę wierzyć.

---

Domyślam się, że problem pochodzi z niektórych odniesień, których nie można rozwiązać, gdy zespół jest ładowany do IDE.

Projekt odnosi się do Microsoft.TeamFoundation.VersionControl.Client.dll v14.0 z folderu VS2015 C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer.
Próbowałem odwołać się do odpowiednich dll z folderów VS2017, ale wtedy zespół nie działa w obu IDE.

Próbowałem również użyć pakietu Nuget "Microsoft.TeamFoundation.VersionControl.All" v12.0.30723.2 zamiast tego i wdrożyłem wszystkie pliki z katalogu wyjściowego (które wydają się zawierać wszystkie złożenia pakietu) do wspomnianej lokalizacji w kluczach rejestru. Miało to taki sam skutek: zasady nie można załadować ani w VS2015, ani w VS2017.

Używamy TFS 12.0.30723.0.

---

Więc wydaje VS2017 nawet nie próbować załadować zespół i nie dba o kluczach rejestru?

Answer 1

W programie Visual Studio 2017 istnieje możliwość rozszerzenia o breaking changes. Znacznie od konfiguracji rejestru zostały przeniesione do „prywatnej” rejestru:

aby zmniejszyć wpływ na rejestrze, Visual Studio używa teraz funkcję RegLoadAppKey do kluczy sklep rejestru w prywatnym pliku binarnego pod% VsAppDataFolder % \ privateregistry.bin. Tylko niewielka liczba kluczy specyficznych dla programu Visual Studio pozostaje w rejestrze systemu. (link)

Definiując klucze rejestru jako część pliku .pkgdef w vsix na instalacji VS 2017 roku (zakładam) Napisać klucze do prywatnego rejestru, w przeciwieństwie do rzeczywistego rejestru, który był przypadek w poprzednich wersjach VS. Umożliwi to odebranie tej polityki.

Tak, tutaj są kroki I przeszły zdobyć nasze zasady pracy w VS 2017:

1. zainstalować Visual Studio SDK (można to zrobić przez modifying instalacji, jeśli nie wybrano obciążenia pierwotnie).
2. Dodaj nową VSIX projekt do rozwiązania Polityka meldowanie

3. Dodaj plik .pkgdef do projektu VSIX z następujących (jest to pozycja klucza rejestru):

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

4. Modyfikuj source.extension.vsixmanifest (przy użyciu kreatora GUI) w projekcie VSIX:

   1. Zainstaluj cele: Dodaj swój najniższy obsługiwanego VS Wersja:
      • Microsoft.VisualStudio.Community [15.0,16.0)
      • Microsoft.VisualStudio.IntegratedShell [15.0,16.0)
   2. aktywa:
      • Microsoft.VisualStudio.Assembly
        • projekt w obecnej rozwiązanie
        • projektu: Wybierz swoją pol polską lodowaty projekt
      • Microsoft.VisualStudio.VsPackage
        • plików na systemie plików
        • Ścieżka: Wybierz plik .pkgdef od kroku 3.
   3. Wymagania: Visual Studio core editor [15.0,16.0)
5. Budowanie projektu VSIX i rozprowadzać/zainstalować wygenerowany vsix

This GitHub repo było pomocne dla składając wszystko razem. Niektóre dziwactwa, które znalazłem podczas migracji do wersji: one:

1. Domyślnie instalacje vsix są teraz przeznaczone dla poszczególnych użytkowników. Jeśli korzystasz z VS pod wieloma użytkownikami na tym samym komputerze, musisz zainstalować go dla każdego z nich. W vixixifest istnieje opcja zainstalowania rozszerzenia dla wszystkich użytkowników, ale wymaga to podniesienia.
2. Nasze zasady dotyczące sprawdzania treści wykorzystywały plik app.config, który nie jest obsługiwany w systemie vsix. Musiałem ustawić migrate nasze ustawienia na plik .settings.

Answer 2

Udało mi się dodanie tego klucza do HKCU:

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

Nadzieję, że to pomaga. Dzięki, Wilsade