Wystąpił błąd podczas weryfikacji. HRESULT = '8000000A'

Od jakiegoś czasu otrzymuję ten błąd podczas używania devenv na automatycznej kompilacji. Przeszukałem każdą stronę internetową, jaką mogłem znaleźć, a zwykłe odpowiedzi wspominają o odświeżaniu zależności (co, jak sądzę, naprawia to w przypadku ręcznego wdrażania, ale nie automatycznego) i usuwaniu kodowania kontroli źródła z projektów, co mi nie pomogło.

Błąd nie występuje za każdym razem, gdy kompiluję, ale za każdym razem wydaje się być losowy w różnych projektach wdrożeniowych.

Czy ktoś ma jakieś rady, dlaczego dokładnie ten błąd występuje i jak go naprawić?

Jest to znany problem w programie Visual Studio 2010 (stan wyścigu). Zobacz ten element połączenia .

Również to napotkaliśmy i otrzymaliśmy bardzo niezadowalający kontakt z pomocą techniczną w tej sprawie z firmą Microsoft. Krótko mówiąc: jest to znany problem, nie zostanie on rozwiązany, a firma Microsoft zaleca odejście od projektów instalacyjnych programu Visual Studio (.vdproj).

Rozwiązaliśmy ten problem, uruchamiając kompilację MSI po raz drugi, gdy pierwsza się nie powiedzie. Nieładne, ale działa przez większość czasu (wskaźnik błędów spadł z ~ 10% do ~ 1%).

Aktualizacja dla tych, którzy napotkali ten problem dla VS2013 lub VS2015 po uaktualnieniu projektu instalacyjnego VS200X przy użyciu rozszerzenia Microsoft Visual Studio Installer Projects.

Postępowanie zgodnie z przepisem na wersję 1.0.0.0 z MS w końcu sprawiło, że zadziałało:

Projekty Instalatora Microsoft Visual Studio

Niestety nie mogliśmy rozwiązać wszystkich problemów związanych z wierszem poleceń w tej wersji, ponieważ wciąż badamy odpowiedni sposób ich rozwiązania. To, co mamy, to obejście, które naszym zdaniem będzie działać w przypadku prawie wszystkich z nich. Jeśli nadal występuje ten problem, możesz spróbować zmienić wartość DWORD następującej wartości rejestru na 0: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0_Config\MSBuild\EnableOutOfProcBuild (VS2013)
lub
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0_Config\MSBuild\EnableOutOfProcBuild(VS2015).
Jeśli to nie istnieje, możesz utworzyć ją jako DWORD.

Aktualizacja z 14.06.2017 r

rozszerzenie Microsoft Visual Studio 2017 Installer Projects zawiera teraz narzędzie pomocnicze wiersza poleceń, które znacznie ułatwia ustawienie rejestru w projektach instalatora Microsoft Visual Studio 2017

Przykładowe ścieżki narzędzia (na podstawie zainstalowanej wersji programu Visual Studio)

Profesjonalna edycja: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\VSI\DisableOutOfProcBuild\DisableOutOfProcBuild.exe

Wydanie społecznościowe: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\VSI\DisableOutOfProcBuild\DisableOutOfProcBuild.exe

Z pliku README

To proste narzędzie ma pomóc użytkownikom ustawić klucz rejestru potrzebny do obejścia tego błędu, który może pojawić się podczas tworzenia projektów instalatora przy użyciu kompilacji z wiersza poleceń:

BŁĄD: Wystąpił błąd podczas weryfikacji. HRESULT = '8000000A'

Narzędzie jest przeznaczone dla programu Visual Studio 2017+ i ustawia ten klucz reg dla określonego zainstalowanego wystąpienia programu Visual Studio dla bieżącego użytkownika. Więc jeśli ustawiasz to w agencie kompilacji, upewnij się, że używasz konta użytkownika, którego będzie używać kompilacja.

Aby uzyskać szczegółowe informacje, uruchom „Pomoc DisableOutOfProcBuild.exe”.

Czytałem o tym gdzieś w Internecie i naprawiłem to w ten sposób (ktoś zasugerował) :

• otwórz plik projektu instalacji (.vdproj) w notatniku (lub dowolnym innym edytorze tekstu)

• usuń te wiersze na początku pliku .vdproj:

  "SccProjectName" = "8:"
  "SccLocalPath" = "8:"
  "SccAuxPath" = "8:"
  "SccProvider" = "8:"
  

• buduj ponownie - błąd zniknął

Ten błąd nie powstrzymał mnie przed wdrożeniem, budowaniem, debugowaniem (lub jakimkolwiek innym) projektem, po prostu mnie zirytował. I działo się to nawet wtedy, gdy ustawiłem wszystkie projekty tak, aby były budowane w bieżącej konfiguracji, a projekt instalacji nie.

Trwałe rozwiązanie (+ dla maszyn budowlanych)

Visual Studio 2017

W przypadku VS 2017 wywołaj następujące skrypty CMD w ramach docelowego konta systemu Windows:

Społeczność edycja
Profesjonalna edycja
Enterprise edition

TL; DR. Uwagi dla biednych DisableOutOfProcBuild.exe, oferowane przez Microsoft rozwiązanie, z którego korzystam w VS 2017.

1. DisableOutOfProcBuild.exenie zakłada, że ​​wywołasz go z folderu instalacyjnego . Nie możesz więc skopiować tego pliku .exe. (Przy okazji, jeśli chcesz zbudować .vdproj, musisz zainstalować VS.)
2. DisableOutOfProcBuild.exe będzie działać tylko wtedy, gdy bieżący katalog CMD jest ustawiony na lokalizację instalacji DisableOutOfProcBuild.exe.

Na przykład w przypadku wersji VS Professional musimy zadzwonić

CD "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\VSI\DisableOutOfProcBuild"
CALL DisableOutOfProcBuild.exe

Visual Studio 2015 i starsze

przez CMD dla bieżącego użytkownika systemu Windows

Dla wielu osób tworzenie / korekta HKEY_CURRENT_USER\..nie zawsze działa lub działa na stałe.
Próbując to rozwiązać, stwierdziłem, że w rzeczywistości muszę stworzyć / zmienić jakiś dziwny klucz pod HKEY_USERS HKEY_USERS\S-1-5-xx-xxxxxxxxxx-xxxxxxxxx-xxxxxxxxxxx-xxxxx\...\MSBuild

Ale odkryłem również, że jeśli będę używał konsoli CMD HKCUz proponowaną poprawką
REG ADD HKCU\SOFTWARE\Microsoft\VisualStudio\14.0_Config\MSBuild /t REG_DWORD /v EnableOutOfProcBuild /d 0 /f
, zapisze to wartość dokładnie w tym dziwnym kluczu HKEY_USERS \ S-1-5-xx-xxxxxxxxxx-xx ... , a nie do HKEY_CURRENT_USER .

Więc to działa od pierwszego ujęcia i na zawsze. Po prostu użyj konsoli CMD.

REG ADD HKCU\SOFTWARE\Microsoft\VisualStudio\14.0_Config\MSBuild /t REG_DWORD /v EnableOutOfProcBuild /d 0 /f
@REM (use 12.0_Config for VS2013)

Solver do budowania serwerów

Z drugiej strony ten kod zawsze działa dla bieżącego konta użytkownika, które go uruchamia (z powodu HKEY_CURRENT_USER). Ale serwery kompilacji często używają dedykowanych kont lub systemu lokalnego itp.

Naprawiłem to na moich maszynach do kompilacji, dodając następujący prosty plik wsadowy do moich zadań kompilacji (Jenkins, TeamCity, CruiseControl)

VS-2015 , VS-2013 , VS-2017-Community , VS-2017-Professional , VS-2017-Enterprise

Jak wskazano w komentarzach tutaj , dla VS2017 będziesz musiał utworzyć DWORD HKEY_CURRENT_USER \ Software \ Microsoft \ VisualStudio \ 15.0_ [IDKey] _Config \ MSBuild \ EnableOutOfProcBuild Zastąp [IDKey] sufiksem ID istniejącego podklucza 15.0 programu VisualStudio .

Na przykład, jeśli w VisualStudio zobaczysz klucz „15.0_abcd1234”, będzie to „15.0_abcd1234_Config”.

Poprawka jest teraz przesłana tutaj:

http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=33186

możesz o tym przeczytać tutaj:

http://connect.microsoft.com/VisualStudio/feedback/details/595632/inconsistent-hanging-with-devenv-2010

Napotkałem ten problem po przeniesieniu projektu na inny komputer (VS 2010, wiele projektów w rozwiązaniu).

Projekt został już utworzony na komputerze źródłowym, ale po skopiowaniu do docelowego nie byłem w stanie zbudować projektu konfiguracji i pojawił się ten błąd.

Otworzyłem /Debugfolder pod ścieżką główną projektu konfiguracji, były MyProject.msii setup.exepliki, usunąłem je i ponownie zbudowałem projekt, zadziałało. Mam nadzieję, że to zadziała również dla niektórych facetów.

Pomocne może być sprawdzenie zależności projektu.

W VS 2010 kliknij prawym przyciskiem myszy w eksploratorze rozwiązań, a następnie kliknij Wykryte zależności i Odśwież zależności, czasami rozwiązuje to problem.

Używam VS 2017, ale żadne z powyższych rozwiązań nie działa. Uaktualnij więc najnowszą wersję VS 2017 i zastosuj rozwiązanie @AussieAsh i jego działanie dobrze ...

Mam nadzieję, że to rozwiązanie może ktoś zadziała.

u mnie było to spowodowane złym plikiem .suo. (spowodowane przez skydrive) usunięcie tego pliku rozwiązało problem.

Program Visual Studio 2017 przechowuje informacje wcześniej przechowywane w rejestrze publicznym w nowym rejestrze prywatnym: C: \ Users \\ AppData \ Local \ Microsoft \ VisualStudio \ 15.0_6de65198 \ privateregistry.bin

W tym miejscu musisz dodać EnableOutOfProcBuild zgodnie z instrukcjami dla VS2013 / VS2015.

Aby zaktualizować rejestr prywatny, możesz użyć Regedit.

Kliknij, aby zaznaczyć węzeł HKEY_USERS.

Wybierz opcję Plik> Wczytaj gałąź i przejdź do pliku privateregistry.bin. Gdy ją wybierzesz, Regedit zapyta o nazwę - nie ma znaczenia, jak ją nazwiesz, ponieważ wkrótce skończymy.

Teraz pojawi się struktura rejestru i możesz przejść do Microsoft \ VisualStudio \ 15.0_Config \ MSBuild

Utwórz nowy DWORD EnableOutOfProcBuild z wartością 0.

Po zakończeniu wybierz katalog główny ula (jakkolwiek go wcześniej nazwałeś) i użyj Plik> Wyładuj Hive, aby odłączyć się od niego.

Teraz powinno działać: o)

Mój program Visual Studio 2013 w jakiś sposób stał się eksperymentalny, więc zaczął używać innego klucza rejestru dla EnableOutOfProcBuild

Aby upewnić się, że właśnie dodałem kolejną linię w moim pliku wsadowym do ustawienia wartości rejestru i zaczęło działać:

REG ADD HKCU\SOFTWARE\Microsoft\VisualStudio\12.0_Config\MSBuild /t REG_DWORD /v EnableOutOfProcBuild /d 0 /f
REG ADD HKCU\SOFTWARE\Microsoft\VisualStudio\12.0Exp_Config\MSBuild /t REG_DWORD /v EnableOutOfProcBuild /d 0 /f

Po prostu uruchom to exe

(Visual Studio 2017 Community Edition)

C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Community \ Common7 \ IDE \ CommonExtensions \ Microsoft \ VSI \ DisableOutOfProcBuild \ DisableOutOfProcBuild.exe

(Visual Studio 2017 Enterprise Edition)

C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Enterprise \ Common7 \ IDE \ CommonExtensions \ Microsoft \ VSI \ DisableOutOfProcBuild \ DisableOutOfProcBuild.exe

Okej, przyjrzałem się temu problemowi, dopóki nie stałem się niebieski na twarzy, czerwony na twarzy, straciłem włosy i straciłem rozum, i próbowałem każdego kroku, jaki mogłem znaleźć. :-RE

Moje rozwiązanie dla Visual Studio 2017 / TeamCity było połączeniem dwóch rozwiązań z @ it3xl i pewnej pomocy z @ Night94 .

Problem polegał na tym, że brakowało klucza rejestru dla użytkownika TeamCity .

• Uruchomienie, DisableOutOfProcBuild.exe jak wspomniał @AussieAsh, nie działało, ponieważ dodał klucz rejestru tylko dla mojego użytkownika.
• użycie skryptu wspomnianego przez @ it3xl również nie powiodło się podczas uruchamiania z TeamCity

Dlatego rozwiązaniem było dodanie następującego kroku kompilacji w wierszu poleceń z TeamCity przed MSBuild:

REG ADD HKCU\SOFTWARE\Microsoft\VisualStudio\15.0_2c79e3fe_Config\MSBuild /t REG_DWORD /v EnableOutOfProcBuild /d 0 /f

Po uruchomieniu tego kroku można go w razie potrzeby usunąć.

Podsumowanie rozwiązania

Zarówno:

• uruchomić DisableOutOfProcBuild.exe jako użytkownik TeamCity lub
• przejdź do klucza rejestru HKCU\SOFTWARE\Microsoft\VisualStudioi sprawdź wymienioną wersję, a następnie zmień powyższe, REG ADDaby dopasować wersje (pamiętaj, aby dodać _Config) jako krok w kompilacji TeamCity.

Ponownie powyższe powinno być zrobione tylko raz. Możesz wyłączyć wejście w TeamCity, zostawiając go w celach informacyjnych, jeśli ponownie napotkasz problem.

Step-1 Utworzyłem klucz DWORD o nazwie „ EnableOutOfProcBuild ” i ustawiłem jego wartość na „ 0 ” w poniższej ścieżce

“HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\14.0_Config\MSBuild”

Uwaga: Upewnij się, że logujesz się za pomocą tego samego użytkownika, którego próbujesz skompilować projekt

U mnie działa dobrze.

Miałem ten problem dzisiaj, spróbuj ponownie uruchomić program Visual Studio, jeśli to nie pomoże, utwórz nowy projekt, zapisz go, a następnie skopiuj pliki z projektu powodującego problem. obie metody działały dla mnie.

Najpierw wyczyść rozwiązanie, skompiluj rozwiązanie, a następnie spróbuj zbudować instalator. To usunie błąd.