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ć?
elegant solution
) w skrócie, IMHO.Odpowiedzi:
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%).
źródło
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
źródło
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)
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”.
źródło
Czytałem o tym gdzieś w Internecie i naprawiłem to w ten sposób (ktoś zasugerował) :
usuń te wiersze na początku pliku .vdproj:
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.
źródło
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.DisableOutOfProcBuild.exe
nie 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.)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ć
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
HKCU
z 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.
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
źródło
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”.
źródło
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
źródło
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
/Debug
folder pod ścieżką główną projektu konfiguracji, byłyMyProject.msi
isetup.exe
pliki, usunąłem je i ponownie zbudowałem projekt, zadziałało. Mam nadzieję, że to zadziała również dla niektórych facetów.źródło
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.
źródło
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.
źródło
u mnie było to spowodowane złym plikiem .suo. (spowodowane przez skydrive) usunięcie tego pliku rozwiązało problem.
źródło
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)
źródł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ć:
źródło
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
źródło
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 .
DisableOutOfProcBuild.exe
jak wspomniał @AussieAsh, nie działało, ponieważ dodał klucz rejestru tylko dla mojego użytkownika.Dlatego rozwiązaniem było dodanie następującego kroku kompilacji w wierszu poleceń z TeamCity przed MSBuild:
Po uruchomieniu tego kroku można go w razie potrzeby usunąć.
Podsumowanie rozwiązania
Zarówno:
DisableOutOfProcBuild.exe
jako użytkownik TeamCity lubHKCU\SOFTWARE\Microsoft\VisualStudio
i sprawdź wymienioną wersję, a następnie zmień powyższe,REG ADD
aby 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.
źródło
Step-1 Utworzyłem klucz DWORD o nazwie „ EnableOutOfProcBuild ” i ustawiłem jego wartość na „ 0 ” w poniższej ścieżce
Uwaga: Upewnij się, że logujesz się za pomocą tego samego użytkownika, którego próbujesz skompilować projekt
U mnie działa dobrze.
źródło
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.
źródło
Najpierw wyczyść rozwiązanie, skompiluj rozwiązanie, a następnie spróbuj zbudować instalator. To usunie błąd.
źródło