Co oznacza „zakończony kodem 9009” podczas tej kompilacji?

Co oznacza ten komunikat o błędzie? Co mogę zrobić, aby rozwiązać ten problem?

AssemblyInfo.cs zakończono z kodem 9009

Problem prawdopodobnie występuje w ramach etapu po kompilacji w rozwiązaniu .NET w Visual Studio.

Czy próbowałeś podać pełną ścieżkę polecenia działającego w poleceniu zdarzenia przed lub po kompilacji?

Wystąpił błąd 9009 z powodu xcopypolecenia zdarzenia po kompilacji w programie Visual Studio 2008.

Komenda została "xcopy.exe /Y C:\projectpath\project.config C:\compilepath\"zakończona z kodem 9009.

Ale w moim przypadku było to również sporadyczne. Oznacza to, że komunikat o błędzie utrzymuje się do momentu ponownego uruchomienia komputera i znika po ponownym uruchomieniu komputera. Powraca po jakimś zdalnie powiązanym problemie, który muszę dopiero odkryć.

Jednak w moim przypadku podanie polecenia z pełną ścieżką rozwiązało problem:

c:\windows\system32\xcopy.exe /Y C:\projectpath\project.config C:\compilepath\ 

Zamiast po prostu:

xcopy.exe /Y C:\projectpath\project.config C:\compilepath\

Jeśli nie mam pełnej ścieżki, po ponownym uruchomieniu działa przez chwilę, a następnie zatrzymuje się.

Również, jak wspomniano w komentarzach do tego postu, jeśli w pełnej ścieżce znajdują się spacje , to wokół polecenia potrzebne są znaki cudzysłowu . Na przykład

"C:\The folder with spaces\ABCDEF\xcopy.exe" /Y C:\projectpath\project.config C:\compilepath\

Zauważ, że ten przykład w odniesieniu do spacji nie jest testowany.

Kod błędu 9009 oznacza, że ​​nie znaleziono pliku błędu. Wszystkie podstawowe przyczyny zamieszczone w odpowiedziach tutaj są dobrą inspiracją, aby dowiedzieć się, dlaczego, ale sam błąd po prostu oznacza złą ścieżkę.

Dzieje się tak, gdy brakuje niektórych ustawień środowiska do korzystania z narzędzi Microsoft Visual Studio x86.
Dlatego spróbuj dodać jako pierwsze polecenie w swoich krokach po kompilacji:

W przypadku programu Visual Studio 2010:

call "$(DevEnvDir)..\Tools\vsvars32.bat"

Jak wspomniano w komentarzach @FlorianKoch, do VS 2017 użyj:

call "$(DevEnvDir)..\Tools\VsDevCmd.bat"

Powinien być umieszczony przed każdym innym poleceniem.
Ustawi środowisko do używania narzędzi Microsoft Visual Studio x86.

Najprawdopodobniej masz miejsce na wynikowej ścieżce.

Możesz obejść ten problem, podając ścieżki, umożliwiając w ten sposób spacje. Na przykład:

xcopy "$(SolutionDir)\Folder Name\File To Copy.ext" "$(TargetDir)" /R /Y /I

Miał tę samą zmienną po zmianie zmiennej PATH z Zmiennych środowiskowych w Win 7. Powrót do ustawień domyślnych pomógł.

Wystąpił błąd 9009, gdy mój skrypt zdarzenia po kompilacji próbował uruchomić plik wsadowy, który nie istniał w podanej ścieżce.

Powodowałem ten błąd, kiedy zredagowałem moją zmienną środowiskową Path. Po edycji przypadkowo dodałem Path=na początku ciągu ścieżki. Przy takiej zniekształconej zmiennej ścieżki nie mogłem uruchomić XCopy w wierszu poleceń (nie znaleziono polecenia lub pliku nie znaleziono), a Visual Studio odmówił uruchomienia kroku po kompilacji, powołując się na błąd o kodzie 9009.

XCopy zwykle znajduje się w C: \ Windows \ System32. Gdy zmienna środowiskowa Path pozwoliła XCopy na rozwiązanie w wierszu poleceń DOS, Visual Studio dobrze zbudowało moje rozwiązanie.

Mój dokładny błąd to

The command "iscc /DConfigurationName=Debug "C:\Projects\Blahblahblah\setup.iss"" exited with code 9009.

9009 oznacza, że ​​plik nie został znaleziony, ale tak naprawdę nie mógł znaleźć części polecenia „iscc”.

Naprawiłem to, dodając ";C:\Program Files\Inno Setup 5 (x86)\"do systemowej zmiennej środowiskowej"path"

Jeśli skrypt faktycznie robi to, co powinien, i to tylko Visual Studio denerwuje cię w związku z błędem, który możesz po prostu dodać:

exit 0

do końca skryptu.

Sprawdź pisownię. Próbowałem zadzwonić do pliku wykonywalnego, ale nazwa miała niepoprawną pisownię i dała mi exited with code 9009wiadomość.

W moim przypadku musiałem najpierw „CD” (zmienić katalog) do właściwego katalogu, przed wywołaniem polecenia, ponieważ plik wykonywalny, który wywoływałem, był w katalogu projektu.

Przykład:

cd "$(SolutionDir)"
call "$(SolutionDir)build.bat"

Kolejny wariant:

dzisiaj dzwonię do interpretera Pythona z crona w win32 i biorę ExitCode (% ERRORLEVEL%) 9009, ponieważ konto systemowe używane przez crona nie ma ścieżki do katalogu Pythona.

Problem w moim przypadku wystąpił, gdy próbowałem użyć polecenia w wierszu polecenia dla zdarzenia po kompilacji w mojej bibliotece klas testowych. Gdy używasz takich znaków cudzysłowu:

"$(SolutionDir)\packages\NUnit.Runners.2.6.2\tools\nunit" "$(TargetPath)" 

lub jeśli używasz konsoli:

"$(SolutionDir)\packages\NUnit.Runners.2.6.2\tools\nunit-console" "$(TargetPath)"

To rozwiązało problem.

Odpowiedź tfa została odrzucona, ale w rzeczywistości może powodować ten problem. Dzięki hanzolo zajrzałem do okna wyników i znalazłem:

3>'gulp' is not recognized as an internal or external command,
3>operable program or batch file.
3>D:\dev\<filepath>\Web.csproj(4,5): error MSB3073: The command "gulp clean" exited with code 9009.

Po uruchomieniu npm install -g gulpprzestałem otrzymywać ten błąd. Jeśli pojawia się ten błąd w programie Visual Studio, sprawdź okno wyjściowe i sprawdź, czy problem jest nierozłączną zmienną środowiskową.

Upewnij się także, że w oknie edycji zdarzenia po kompilacji w projekcie nie ma żadnych podziałów linii. Czasami skopiowanie polecenia xcopy z Internetu, gdy jest ono wieloliniowe i wklejenie go do VS spowoduje problem.

Dodałem „> myFile.txt” na końcu wiersza w kroku przed kompilacją, a następnie sprawdziłem plik pod kątem rzeczywistego błędu.

Dla mnie było mało miejsca na dysku i oczekiwano, że pliki, których nie można zapisać, pojawią się później. Inne odpowiedzi wspomniały o brakujących plikach (lub błędnie nazwanych / niepoprawnie przywoływanych plikach według nazwy) - ale główną przyczyną był brak miejsca na dysku.

Dla mnie stało się to po aktualizacji pakietów nuget z jednej wersji PostSharp do następnej w dużym rozwiązaniu (~ 80 projekt). Mam błędy kompilatora dla projektów, które mają polecenia w zdarzeniach PreBuild.

„cmd” nie jest rozpoznawane jako polecenie wewnętrzne lub zewnętrzne, program operacyjny ani plik wsadowy. C: \ Program Files (x86) \ MSBuild \ 14.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1249,5): błąd MSB3073: Polecenie „cmd / c C: \ GitRepos \ main \ ServiceInterfaces \ DEV.Config \ PreBuild.cmd ServiceInterfaces ”zakończony kodem 9009.

Zmienna PATH została uszkodzona i stała się zbyt długa z wieloma powtarzanymi ścieżkami związanymi z PostSharp.Patterns.Diagnostics. Kiedy zamknąłem Visual Studio i otworzyłem go ponownie, problem został rozwiązany.

Nie znaleziono jeszcze innego wariantu pliku z powodu spacji na ścieżce. W moim przypadku w skrypcie msbuild. Musiałem użyć stylu HTML & quot; ciągi znaków w poleceniu exec.

<!-- Needs quotes example with my Buildscript.msbuild file --> 
<Exec Command="&quot;$(MSBuildThisFileDirectory)\wix\wixscript.bat&quot; $(VersionNumber) $(VersionNumberShort)" 
    ContinueOnError="false" 
    IgnoreExitCode="false" 
    WorkingDirectory="$(MSBuildProjectDirectory)\wix" />

Podobnie jak inne odpowiedzi, w moim przypadku było to spowodowane brakującym plikiem. Aby dowiedzieć się, jaki jest brakujący plik, możesz przejść do okna wyjściowego, a natychmiast pokaże ci, co zaginęło.

Aby otworzyć okno wyjściowe w Visual Studio:

1. Ctrl + Alt + O
2. Widok> Dane wyjściowe

Naprawiłem to po prostu ponownie uruchamiając Visual Studio - właśnie uruchomiłem dotnet tool install xxxw oknie konsoli, a VS nie wybrał jeszcze nowych zmiennych środowiskowych i / lub ustawień ścieżki, które zostały zmienione, więc szybki restart rozwiązał problem.

Jest to dość podstawowe, miałem ten problem i zawstydzające proste niepowodzenie.

Zastosowanie aplikacji Argumenty wiersza poleceń, usunąłem je, a następnie dodałem ponownie. Nagle nie udało się zbudować projektu.

Visual Studio -> Właściwości projektu -> sprawdź, czy używasz karty „Debuguj” (nie karty „Kompiluj zdarzenia”) -> Argumenty wiersza poleceń

Użyłem obszaru tekstowego i Post / Pre-build, co w tym przypadku było nieprawidłowe.

Moje rozwiązanie było po prostu proste: czy próbowałeś go wyłączyć i włączyć ponownie? Ponownie uruchomiłem komputer i problem zniknął.

Zetknąłem się również z tym 9009problemem, gdy miałem do czynienia z sytuacją zastąpienia.

Zasadniczo, jeśli plik już istnieje i nie określono /yprzełącznika (który automatycznie zastępuje), ten błąd może wystąpić podczas uruchamiania z kompilacji.

Zauważyłem, że z jakiegoś powodu zmienna środowiskowa% windir% czasami się kasuje. Dla mnie zadziałało ponowne ustawienie zmiennej środowiskowej windir na c: \ windows, restart VS i to wszystko. W ten sposób można uniknąć konieczności modyfikacji plików rozwiązania.

Przynajmniej w Visual Studio Ultimate 2013, wersja 12.0.30723.00, aktualizacja 3, nie można oddzielić instrukcji if / else z podziałem wiersza:

Pracuje:

if '$(BuildingInsideVisualStudio)' == 'true' (echo local) else (echo server)

nie działa:

if '$(BuildingInsideVisualStudio)' == 'true' (echo local) 
else (echo server)

Kolejny powód: jeśli zdarzenie przed kompilacją odwołuje się do ścieżki bin innego projektu i widzisz ten błąd podczas uruchamiania msbuild, ale nie Visual Studio, musisz ręcznie rozmieścić projekty w pliku * .sln (za pomocą edytora tekstu), aby że projekt, na który kierujesz wydarzenie, jest budowany przed projektem wydarzenia. Innymi słowy, msbuild używa kolejności, w której projekty są wymienione w pliku * .sln, podczas gdy VS używa wiedzy o zależnościach projektu. Zdarzyło mi się to, gdy narzędzie, które tworzy bazę danych, która ma być zawarta w wixproj, zostało wymienione po wixproj.

Myślę, że w moim przypadku na ścieżce były rosyjskie symbole (wszystkie projekty były w folderze użytkownika). Kiedy umieściłem rozwiązanie w innym folderze (bezpośrednio na dysku), wszystko stało się dobrze.

Moim rozwiązaniem było utworzenie kopii pliku i dodanie kroku do zadania kompilacji, aby skopiować mój plik na oryginał.

Musisz upewnić się, że zainstalowałeś glob na całym świecie