Bu derleme sırasında “kod 9009'dan çıkıldı” ne anlama geliyor?

Bu hata mesajı ne anlama geliyor? Bu sorunu gidermek için ne yapabilirim?

AssemblyInfo.cs kodu 9009 ile çıkıldı

Sorun muhtemelen Visual Studio'da bir .NET çözümü oluşturma sonrası adımın bir parçası olarak oluyor.

Yapım öncesi veya sonrası olay komutunda çalışan komutun tam yolunu vermeye çalıştınız mı?

xcopyVisual Studio 2008'de bir derleme sonrası olay komutu nedeniyle 9009 hatası alıyordum .

Komut "xcopy.exe /Y C:\projectpath\project.config C:\compilepath\"9009 koduyla çıkıldı.

Ama benim durumumda da aralıklıydı. Yani, hata iletisi bilgisayarın yeniden başlatılmasına kadar devam eder ve bilgisayarın yeniden başlatılmasından sonra kaybolur. Ben henüz keşfetmek için bazı uzaktan ilgili sorundan sonra geri döndü.

Ancak, benim durumumda komutu tam yolu ile sağlamak sorunu çözdü:

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

Sadece yerine:

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

Tam yol yoksa, yeniden başlatmadan sonra bir süre çalışır ve sonra durur.

Ayrıca bu yazının yorumlarında belirtildiği gibi , tam yolda boşluklar varsa , komutun etrafında tırnak işaretlerine ihtiyaç vardır . Örneğin

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

Boşluklarla ilgili bu örneğin test edilmediğini unutmayın.

Hata Kodu 9009, hata dosyasının bulunamadığı anlamına gelir. Buradaki yanıtlarda yayınlanan tüm temel nedenler, nedenini bulmak için iyi bir ilham kaynağıdır, ancak hatanın kendisi sadece kötü bir yol anlamına gelir.

Microsoft Visual Studio x86 araçlarını kullanmak için bazı ortam ayarları eksik olduğunda olur.
Bu nedenle, derleme sonrası adımlarınızda ilk komut olarak eklemeyi deneyin:

Visual Studio 2010 kullanımı için:

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

@FlorianKoch'un yorumlarda belirtildiği gibi, VS 2017 kullanımı için:

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

Diğer komutlardan önce yerleştirilmelidir.
Microsoft Visual Studio x86 araçlarını kullanmak için ortam ayarlayacaktır.

Büyük olasılıkla ortaya çıkan yolunuzda yer var.

Yolları belirterek, böylece boşluklara izin vererek bu sorunu çözebilirsiniz. Örneğin:

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

Win 7'de PATH değişkenini Çevresel Değişkenlerden değiştirdikten sonra aynı değişken vardı.

Post build olay betiğim belirtilen yolda mevcut olmayan bir toplu iş dosyasını çalıştırmaya çalışırken 9009 hatası aldım.

Path ortam değişkenimi düzelttiğimde bu hatanın oluşmasına neden oldum. Düzenledikten sonra, yanlışlıkla Path=yol dizesinin başına ekledim . Böyle hatalı biçimlendirilmiş bir yol değişkeni ile, XCopy komut satırında (komut veya dosya bulunamadı) çalıştıramadı ve Visual Studio, 9009 kodunda hata nedeniyle derleme sonrası adım çalıştırmayı reddetti.

XCopy genellikle C: \ Windows \ System32 dizininde bulunur. Path ortam değişkeni XCopy'nin DOS komut isteminde çözülmesine izin verdiğinde, Visual Studio çözümümü iyi oluşturdu.

Kesin hataydı

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

9009, dosyanın bulunamadığı anlamına gelir, ancak aslında komutun "iscc" bölümünü bulamadı.

";C:\Program Files\Inno Setup 5 (x86)\"Sistem ortam değişkenine ekleyerek düzelttim"path"

Betik aslında yapması gerekeni yapıyorsa ve sadece Visual Studio ekleyebileceğiniz hata hakkında sizi rahatsız ediyorsa:

exit 0

senaryonun sonuna.

İmlayi kontrol et. Yürütülebilir bir dosyayı aramaya çalışıyordum ama adı yanlış yazılmıştı ve bana exited with code 9009mesaj verdi .

Benim durumumda, komut çağırmadan önce uygun dizine "CD" (Dizin Değiştir) gerekiyordu, çünkü aradığım yürütülebilir dosya benim proje dizininde idi.

Misal:

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

Başka bir varyant:

Bugün win32'de cron'dan python yorumlayıcısını çağırıyorum ve ExitCode (% ERRORLEVEL%) 9009'u alıyorum, çünkü cron tarafından kullanılan sistem hesabının Python dizinine yolu yok.

Benim durumumda sorun, sınama sınıfı kitaplığımda Post-build olayı için komut satırında bir komut kullanmaya çalıştığınızda oluştu. Aşağıdaki gibi tırnak işaretleri kullandığınızda:

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

veya konsolu kullanıyorsanız:

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

Bu benim için sorunu düzeltti.

tfa'nın cevabı reddedildi, ancak aslında bu soruna neden olabilir. Hanzolo sayesinde, çıkış penceresine baktım ve aşağıdakileri buldum:

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.

Çalıştırdıktan sonra npm install -g gulp, bu hatayı almaya durdu. Visual Studio'da bu hatayı alıyorsanız, çıkış penceresini kontrol edin ve sorunun ayarlanmamış bir ortam değişkeni olup olmadığına bakın.

Ayrıca, projenizde post-build olay düzenleme penceresinde satır kesmeleri olmadığından emin olun. Bazen xcopy komutunun çok satırlı olduğu zaman web'den kopyalanması ve VS'ye yapıştırılması bir soruna neden olabilir.

Önceden derleme adımında satırın sonuna "> myFile.txt" ekledim ve sonra dosyayı gerçek hata açısından inceledim.

Benim için disk alanı azdı ve yazılamayan dosyaların daha sonra sunulması bekleniyordu. Diğer cevaplar eksik dosyalardan (veya yanlış adlandırılmış / ada göre yanlış adlandırılmış dosyalar) bahsetti - ancak temel neden disk alanı eksikliğiydi.

Benim için büyük bir çözümde (~ 80 proje) nuget paketlerini bir PostSharp versiyonundan diğerine yükselttikten sonra oldu. PreBuild olaylarında komutları olan projeler için derleyici hataları var.

'cmd' dahili veya harici bir komut, çalıştırılabilir program veya toplu iş dosyası olarak tanınmıyor. C: \ Program Dosyaları (x86) \ MSBuild \ 14.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1249,5): hata MSB3073: "cmd / c C: \ GitRepos \ main \ ServiceInterfaces \ DEV.Config \ komutu PreBuild.cmd ServiceInterfaces "kodu 9009 ile çıktı.

PATH değişkeni, PostSharp.Patterns.Diagnostics ile ilişkili birden çok yinelenen yolla çok uzun hale geldi. Visual Studio'yu kapatıp yeniden açtığımda sorun giderildi.

Yoldaki boşluklar nedeniyle başka bir dosya türü bulunamadı. Benim durumumda msbuild betiğinde. HTML stilini kullanmam gerekiyordu & quot; exec komutu içinde dizeler.

<!-- 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" />

Diğer cevaplarla aynı, benim durumumda eksik dosya yüzünden oldu. Eksik dosyanın ne olduğunu bilmek için çıktı penceresine gidebilirsiniz ve eksik olanı hemen gösterecektir.

Çıktı penceresini Visual Studio'da açmak için:

1. Ctrl + Alt + O
2. Görünüm> Çıktı

Bunu sadece Visual Studio'yu yeniden başlatarak çözdüm - dotnet tool install xxxhenüz bir konsol penceresinde çalışmıştım ve VS henüz değiştirilen yeni ortam değişkenlerini ve / veya yol ayarlarını almamıştı, bu yüzden hızlı bir yeniden başlatma sorunu çözdü.

Bu oldukça basit, bu sorun vardı ve utanç verici basit başarısız.

Uygulama Komut satırı bağımsız değişkenlerini kullanın, onları kaldırdım ve sonra geri ekledim. Aniden proje inşa edilemedi.

Visual Studio -> Proje Özellikleri -> 'Hata Ayıkla' sekmesini ('Derleme Etkinlikleri' sekmesini değil) kullandığınızı doğrulayın -> Komut Satırı Bağımsız Değişkenleri

Bu durumda yanlış olan ve Post / Pre-build metin alanını kullandım.

Çözümüm şöyle basitti: Kapatıp tekrar açmayı denediniz mi? Böylece bilgisayarı yeniden başlattım ve sorun ortadan kalktı.

Üzerine 9009yazma durumu ile karşılaştığımda da bu problemle karşılaştım.

Temel olarak, dosya zaten varsa ve /yanahtarı (otomatik olarak üzerine yazan) belirtmediyseniz, bu hata bir derlemeden çalıştırıldığında ortaya çıkabilir.

Aslında bazı nedenlerden dolayı% windir% ortam değişkeninin bazen silindiğini fark ettim. Benim için işe yarayan windir ortam değişkenini c: \ windows olarak yeniden ayarlamak, VS'yi yeniden başlatmaktı ve hepsi bu. Bu şekilde çözüm dosyalarını değiştirmek zorunda kalmazsınız.

En azından Visual Studio Ultimate 2013, Sürüm 12.0.30723.00 Güncelleme 3'te, if / else deyimini satır sonu ile ayırmak mümkün değildir:

İşler:

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

çalışmıyor:

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

Yine başka bir neden: Pre-build etkinliğiniz başka bir proje bin yoluna başvuruyorsa ve msbuild'i çalıştırırken Visual Studio'yu çalıştırmıyorsanız bu hatayı görüyorsanız, * .sln dosyasındaki projeleri (bir metin düzenleyicisiyle) manuel olarak ayarlamanız gerekir. etkinlikte hedeflediğiniz projenin etkinliğin projesinden önce oluşturulduğunu unutmayın. Başka bir deyişle, msbuild projelerin * .sln dosyasında listelenme sırasını kullanırken VS proje bağımlılıkları hakkındaki bilgileri kullanır. Bir wixproj dahil edilmek üzere bir veritabanı oluşturan bir araç wixproj sonra listelendiğinde bu oldu.

Benim durumumda yolunda Rus sembolleri olduğunu düşünüyorum (tüm projeler kullanıcı klasöründeydi). Çözümü başka bir klasöre koyduğumda (doğrudan diskte), her şey yoluna girdi.

Benim çözümüm dosyanın bir kopyasını oluşturmak ve dosyayı orijinalin üzerine kopyalamak için oluşturma görevine bir adım eklemekti.

Global olarak homurdanma kurduğunuzdan emin olmanız gerekir