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

98

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ć?

Chris C.
źródło
czy wreszcie dostałeś bardziej eleganckie rozwiązanie ? właśnie ponownie uruchamiałeś kompilację, gdy się nie powiodła , Może przydatne put script ( elegant solution) w skrócie, IMHO.
Kiquenet

Odpowiedzi:

53

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%).

oɔɯǝɹ
źródło
Dziękuję Ci bardzo. Przeszukałem Internet, aby dowiedzieć się, dlaczego dokładnie to się dzieje, i natknąłem się na liczne odpowiedzi Microsoftu, które były co najmniej niejasne i nieprzydatne. Właśnie uruchamiałem ponownie kompilację, gdy się nie udała, ale liczyłem na bardziej eleganckie rozwiązanie. Dzięki jeszcze raz.
Chris C.,
@ChrisC. stackoverflow.com/a/25054572/206730 odpowiedź ma więcej głosów, czy próbowałeś w ten sposób?
Kiquenet
@ oɔɯǝɹ czy mógłbyś wyjaśnić, co masz na myśli, wypowiadając uruchamianie kompilacji MSI po raz drugi ?, masz ten sam problem ...
Leon Barkan
123

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.

kristian mo
źródło
23
Zwróć uwagę, że aktualizacje programu Visual Studio 2013 usuwają tę zmienną z rejestru - trzeba będzie ją ponownie dodać.
Derek W
4
Uwaga, podczas pracy z Jenkinsem klucz rejestru musi zostać dodany dla użytkownika obsługującego niewolników Jenkins.
Jirong Hu
3
PAMIĘTAJ, że gałąź rejestru to HKEY_CURRENT_USER, więc jeśli jest ona wywoływana przez inne konto niż ty (np. Konto kompilacji tfs), musisz zalogować się jako TO konto i dodać ustawienie.
Mike Cheel
3
Aby dodać do komentarzy @DerekW, można to również wyczyścić przez automatyczne aktualizacje.
JustAnotherDeveloper
2
@MikeCheel możesz ustawić HKEY_USERS \ .DEFAULT \ Software \ Microsoft \ VisualStudio \ 14.0_Config \ MSBuild \ EnableOutOfProcBuild, aby naprawić to dla wszystkich użytkowników :)
Ian Ellis
58

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”.


Aussie Ash
źródło
5
To najlepsze rozwiązanie dla VS2017
Simon O'Beirne
1
Myślę, że to trzeci raz, kiedy miałem ten problem, spędziłem godziny próbując naprawić, a potem w końcu ponownie odkryłem tę odpowiedź. Dzięki!
Hannes Sachsenhofer
2
Musisz zmienić katalog na tę lokalizację, aby działał poprawnie. Zobacz github.com/it3xl/MSBuild-DevEnv-Build-Server-Workarounds/issues/… i github.com/it3xl/MSBuild-DevEnv-Build-Server-Workarounds/blob/…
GilesDMiddleton
1
Idealne dla mnie, używając Visual Studio 2019 Community Edition na moim komputerze kompilacji.
Maksymalna moc
48

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.

Cipi
źródło
3
Problem polega na tym, że jest to stan wyścigu. Dokonanie (losowej) korekty i przebudowy sprawi, że będzie wyglądać na naprawioną. Samo odbudowanie spowodowałoby, że problem również zniknąłby. Chciałbym wiedzieć, czy pozostaje „naprawiony” po 100 kompilacjach.
oɔɯǝɹ
6
Może to być stan wyścigu, ale powyższa poprawka działa i pozwala mi żyć dalej (do następnego numeru, który
zmusza
39

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

it3xl
źródło
1
po łataniu reg evrey kilka miesięcy od 2 lat i plik CMD nie działa dobrze jakieś rozwiązanie
CMS
1
Ten sam problem pojawił się znikąd podczas tworzenia pliku MSI z projektu instalacyjnego na serwerze kompilacji. Proces kompilacji zawsze działał wcześniej i nie zmieniał się, ale zaczął konsekwentnie zawodzić. Dodałem to do skryptu kompilacji tuż przed wywołaniem devenv.exe i zadziałało w VS 2013. Wielkie dzięki.
Jim
W VS 15.8.x ten błąd pojawia się nawet po uruchomieniu EXE, jednak po zamknięciu VS, a następnie uruchomieniu EXE i ponownym uruchomieniu VS błąd został rozwiązany. Więc coś w VS resetuje ustawienie reg, a rozwiązaniem jest zamknięcie VS, ponowne uruchomienie DisableOutOfProcBuild.exe, a następnie uruchomienie VS.
user2728841
1
Ta poprawka działała dla kompilacji VS2015 TFS vNext. Używamy lokalnego konta NT Authority \ Network Service do automatycznych kompilacji, więc ręczne dodanie klucza reg z RDPing do maszyny wirtualnej kompilacji nie naprawiło błędu automatycznego kompilowania. Dodałem krok tworzenia klucza reg tuż przed krokiem, aby wywołać Devenv.com w celu uzyskania pliku VDPROJ. Po tak długim wysiłku, aby znaleźć rozwiązanie tego problemu, chcę bardzo podziękować it3xl za opublikowanie go !!!
ckkkitty
6

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”.

przykład regedit

Noc94
źródło
4

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.

kubilay
źródło
jeszcze jedno +1, po prostu usunięcie plików .msi i setup.exe i odbudowanie projektu instalacyjnego spowodowało, że komunikat o błędzie zniknął
George
i -1, wydaje się, że rozwiązuje ten problem tylko tymczasowo, po ponownym otwarciu rozwiązania problem pojawił się ponownie
George
@ChrisSchiffhauer do rozwiązania tego problemu, tylko ty usuwasz pliki msi i exe ?
Kiquenet
Dobrze powiedziane przez @kubilay, wielkie dzięki za rozwiązanie !! Ten problem może wystąpić podczas przenoszenia projektów ze starszej do nowszej platformy, ponieważ ustawiliśmy nowszą wersję struktury we właściwościach projektu. Prawdopodobnie projekt instalacyjny może zawierać pliki .msi i .exe w swojej lokalizacji docelowej. W nowej wersji frameworka może generować błąd podczas nadpisywania plików wyjściowych. Tak więc, kliknij prawym przyciskiem myszy projekt konfiguracji -> goto „Nazwa pliku wyjściowego” (w sekcji Właściwości konfiguracyjne \ Budowanie) -> kliknij przycisk „...” (przeglądaj) -> pobierz lokalizację docelową i usuń pliki .msi oraz .exe . Teraz skompiluj projekt i powinien działać.
Navin Pandit
1

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.

Jla
źródło
1

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.

Rikin Patel
źródło
0

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

Aswin
źródło
DisableOutOfProcBuild.exe działał przez chwilę, dopóki nie zadziałał. Usunięcie pliku .suo rozwiązało problem.
Sego,
0

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)

Gwynge
źródło
Nie musisz majstrować przy prywatnym pliku rejestru, możesz po prostu samodzielnie utworzyć klucz 15.0_ <x> _Config w zwykłym rejestrze (patrz wyżej)
Night94
0

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

wprowadź opis obrazu tutaj

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
Hovhannes Hakobyan
źródło
0

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

Lakmal
źródło
0

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.

SharpC
źródło
0

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.

Dharti Sutariya
źródło
-1

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.

Fading Away90
źródło
-3

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

Keennary Pungyera
źródło