MSBuild çalıştırıldığında SDKToolsPath okunamıyor


130

Naber, VS2008 ve ilişkili araçları ile derlerken .Net 2.0 tabanlı web sitemi düzgün bir şekilde oluşturmak için kullanılan bir NAnt komut dosyasını çalıştırma konusunda biraz sorun yaşıyorum. Yakın zamanda tüm proje / çözüm dosyalarını VS2010'a yükselttim ve şimdi yapım aşağıdaki hatayla başarısız oluyor:

[exec] C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (2249,9): hata MSB3086: Görev, S dkToolsPath "" veya kayıt defterini kullanarak "sgen.exe" yi bulamadı "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A" anahtarı. SdkToolsPath'in ayarlandığından ve aracın SdkToolsPath altında doğru işlemciye özgü konumda bulunduğundan ve Microsoft Windows SDK'nın kurulu olduğundan emin olun.

Şimdi, yapı sunucusunda Windows SDK'nın önceki sürümleri (.Net 3.5) var ve .Net 4.0 çerçevesinin tamamı kurulu, ancak Windows SDK'nın .Net 4.0'a özgü bir sürümünü çalıştırmadım.

Biraz deney ve araştırmadan sonra, nihayet yeni bir çevresel değişken "SDKToolsPath" kurdum ve onu windows 6.0 sdk klasörümdeki sgen.exe kopyasına işaret ettim. Bu aynı hatayı oluşturdu, ancak SDKToolsPath ortam değişkeni IS ayarlansa bile (komut satırında onu "yankılayabildiğimi" ve beklenen değere sahip olduğunu doğruladı), hata mesajının bunu gösterdiğini fark ettim. okunmuyor (boş alıntılara dikkat edin).

Bulduğum bilgilerin çoğu .Net 3.5'e (veya öncesi) özeldir. Henüz 4.0 ile ilgili pek bir şey yok. MSB3086 hata kodunu aramak da yararlı hiçbir şey üretmedi. Bunun ne olabileceği hakkında bir fikriniz var mı?

Scott


Bu gönderideki ilgili sorun. Orada da bir cevap gönderdim. stackoverflow.com/questions/1109955/…
Diego C.

Yanıtlar:


15

Bu sorunu gidermek için kurşunu ısırıp VS 2010'u derleme sunucumuza kurmam gerekti. Gördüğüm kadarıyla, MSDN'de herhangi bir yerde Windows SDK'nın 7.0A sürümü yok. Ancak, VS 2010'un yüklenmesi, onu yüklemek için görünür ve Program Files \ Microsoft SDKs \ Windows'da bir 7.0A regkey ve 7.0A klasörü oluşturur.


9
Visual Studio 2010'u bir sunucuya yüklememeyi tercih ediyorum. Simmo'nun şu anki Windows SDK'yı v7.1'e ayarlama önerisini tercih ediyorum. WindowsSdkVer.exe, C: \ Program Files \ Microsoft SDKs \ Windows \ v7.1 \ Setup konumunda bulunur (C: \ Program Files'a yüklendiğini varsayarak).
Philippe

55
Yalnızca Windows SDK 7.1 ve .NET 4.0'ı yüklerseniz buldum. MSBuild, SDK40ToolsPath ve SDK35ToolsPath için uygun yolları ayarlamaz. Düzeltmek için, HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0: "SDK40ToolsPath" = "$ (Kayıt Defteri: HKEY_LOCAL_MACHINE \\ SOFTWARE \\ Microsoft \\ Microsoft SDKs \\ Windows \\ v7'deki birkaç girişi değiştirmem gerekiyordu .1 \\ WinSDK-NetFx40Tools-x86 @ InstallationFolder) "Benzer şekilde SDK35ToolsPath ve FrameworkSDKRoot'da" v7.0A "yı" v7.1 "olarak değiştirin.
BlueMonkMN

7
Sheesh - Aynı problemle yine kendim karşılaştım, Google'da araştırdım ve kendi cevabımı buldum! :) Bir şey değişikliğimi sıfırlamış görünüyor ve sanırım bunu manuel olarak tekrar uygulamam gerekiyor.
BlueMonkMN

3
Arrrgh! En son .NET 4.0 yamaları (2011-08-11) bu kayıt defteri ayarlarının üzerine yazdı!
si618

8
Önceki cevabımla ilgili güncelleme. 64-bit işletim sistemlerinde, HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0'da da benzer değerleri güncellemek gerekli olabilir ve 8.0 SDK'yi kurmak veya HKEY_LOCAL_MACHINE'daki değerleri güncellemek gerekebilir \ YAZILIM \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 ve HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 8.0 SDK kurulumu dışında yukarıdakilerin hepsini yaptım ve şu ana kadar derleyemedim (tek bir toplu iş olarak) adım) tüm 4.0 \ 11.0 düğümlerindeki güncellemelerimi içeriyordu.
BlueMonkMN

227

Visual Studio'yu derleme sunucusuna koymakla karşılaşamadım.

SDK v7.0A, Visual Studio 2010 ile birlikte yüklenen SDK'dır (A, bunun bir VS sürümü olduğunu belirtir). O zamandan beri daha yeni bir sürüm yayınlandı. Windows 7 ve .NET Framework AKA v7.1 için Microsoft Windows SDK .

Bunu yapı sunucuma yükledim. Daha sonra Windows SDK 7.1 Komut İstemi (Başlat => Tüm Programlar => Microsoft Windows SDK 7.1) aracılığıyla SDK'nın varsayılan sürümünü 7.1 olarak ayarlıyorum.

Adımlar:

cd Setup

WindowsSdkVer.exe -version:v7.1

LordHits'in yorumunu içerecek şekilde düzenleyin: SDK'nın tamamını yüklemenize gerek yoktur. Sadece ".NET Geliştirme / Intellisense ve Referans Meclisleri" ve ".NET Geliştirme / Araçlar" seçeneklerini kurmak yeterlidir.


4
Bu benim için mükemmel bir şekilde çalıştı, dosyalar arasında VS makinemden C: \ Program Files \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications içine kopyalandı.
dnolan

1
Orijinal yazarla aynı problemle karşı karşıyaydım ve bu cevap onu çözdü! Build makineme Visual Studio 2010 yüklemem gerekmedi.
SolutionYogi

37
Ayrıca, sadece açıklığa kavuşturmak için, SDK'nın tamamını yüklemeye gerek yoktur. Sadece ".NET Geliştirme / Intellisense ve Referans Meclisleri" ve ".NET Geliştirme / Araçlar" seçeneklerini kurmak yeterlidir. Bu ve dosyaları dnolan'ın yorumundan kopyalamak.
LordHits

Bu çözüm için teşekkürler, derleme sunucumuzda benim için mükemmel çalıştı! Bilginize - Sorgulayan herkes için, yapı sunucusu Windows Server 2008 x64'tür.
Adam Weber

Bu cevap için çok teşekkürler; iş yerinde de aynı sorunla karşılaştı.
Abe

20

GenerateSerializationAssemblies parametresini Off değeriyle MsBuild'e iletmeniz yeterlidir.

msbuild.exe /p:GenerateSerializationAssemblies=Off

7
msbuild.exe / p: GenerateSerializationAssemblies = Kapalı
Daniel

2
Veya web hizmetinin proje özelliklerinin Oluştur sekmesinde "Seri hale getirme derlemesi oluştur: Kapalı" seçeneğini ayarlayın.
samneric

6
Bu tam olarak ne yapıyor?
ezmek

1
GOTCHA: Yapım sekmesinden kapatırsanız, bunu ilgili derleme yapılandırması için yaptığınızdan emin olun, (Derleme sekmesinin üst kısmındaki DropDown) benim durumumda sorunla ilgili yalnızca derleme sunucusuydu, bu yüzden bunu "Yayın" yapılandırmasında değiştirin.
Myster

14
Aslında ne yaptıkları hakkında hiçbir fikriniz olmadan, rastgele şekilde yapı bayraklarını değiştirmeyi seviyorum.
AaronLS

14

Değişkenleri derleme sunucusunda MSBuild'e manuel olarak aktarıyorum.

msbuild.exe MyProject.csproj "/p:TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools" "/p:AspnetMergePath=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools"

1
Bu, Visual Studio ve Build Tools 2019 bulunmayan bir sunucuda Windows 10 SDK için yaptığım şeydi. Diğer çözümlerin hiçbiri yardımcı olmadı ve bu da hile temiz bir şekilde yaptı.
Nicolás Fantone

8

Kısa süre önce derleme sunucumuzda benzer bir sorunla karşılaştım.

7.0A klasörünü (C: \ Program Files \ Microsoft SDKs \ Windows \ 7.0A) bilgisayarımdan (VS2010 kurulu olan) aynı konumdaki derleme sunucusuna kopyaladım.

Aşağıdaki kayıt defteri anahtarını oluşturduktan sonra: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A. InstallationFolder öğesini C: \ Program Files \ Microsoft SDKs \ Windows \ 7.0A olarak ayarlayın.

Ayrıca, derleme sunucusundaki kayıt defteri ile ne yapacağınız konusunda kafanız karışırsa, VS2010 yüklü olan makinenizdeki kayıt defterine de başvurabilirsiniz.


Benim için Simmo'nun cevabı işe yaramadı - yine de bu kayıt defteri hacklendi (Win 2K3 SP2).
FinnNk

7

Aynı hatayla karşılaştım ama farklı bir durumda: VS 2010 Express'i kullanarak ve SDK sürümünü açıkça ayarlamak için Simmo'nun cevabını kullanmaya çalışıyorum - ancak WindowsSdkVer.exe (sürüm belirleyici aracı) Express'i hedeflemiyor gibi görünüyor (sınırlı olduğu için anlaşılabilir ).

Win 7 Prof. üzerinde VS 2010 Express kullanıyorum ve her zaman Win SDK'nın v7.0A'sını kullanmak istiyor (gerekli tüm exes'e sahip değil) ve hangi sürümü açıkça kullanarak geçerli olarak ayarladığım önemli değil WindowsSdkVer.exe (Yalnızca 2010 Ex kurulu olmasına rağmen, SDK'nın mevcut sürümünü ayarladığını bildirmeye devam ediyor, ancak VS 2008 için.)

Bu yüzden benim ucuz geçici çözümüm v7.0 WIN SDK'yi (veya v7.1 gibi başka bir sürümü) yüklemek ve ardından dosya sistemi klasörünü v7.0A olarak yeniden adlandırmaktı - temelde VS 2010 Express'e yalan söyledim ama şimdi çalışıyor!


5

Projelerinizden biri web hizmeti oluşturmak için sgen.exe (Sunucu Oluşturucu) kullanıyor. Derleme Sunucusu için SDK'ları yüklemeniz veya projeden Web Hizmeti referanslarını kaldırmanız gerekir.


1
Veya web hizmetinin proje özelliklerinin Oluştur sekmesinde "Seri hale getirme derlemesi oluştur: Kapalı" seçeneğini ayarlayın.
samneric

1
GOTCHA: Yapım sekmesinden kapatırsanız, bunu ilgili derleme yapılandırması için yaptığınızdan emin olun, (Derleme sekmesinin üst kısmındaki DropDown) benim durumumda sorunla ilgili yalnızca derleme sunucusuydu, bu yüzden bunu "Yayın" yapılandırmasında değiştirin.
Myster

4

Hedefler dosyasının araç yolunu geçersiz kıldığından şüpheleniyorum, bu dosyaya hızlıca baktım ve SDKToolsPath'i oradaki bazı hedeflerin altında $ TargetFrameworkSDKToolsDirectory olarak ayarladım. Bunları zaten ortamda ayarlamanız gerektiğini düşünmüyorum, ancak proje dosyalarınızda düzeltilmesi gerekebilir.

Bu sayfaya göre http://nant.sourceforge.net/ Nant'ın .Net 4.0'ı desteklemediğine dikkat edin, bu gerçek sorun olabilir mi?

Üzgünüm, bunun sorunuzu gerçekten cevaplamadığını biliyorum :(


Doğru, NAnt henüz VS2010 için proje / çözüm dosya formatlarını desteklemiyor, bu yüzden gerçek derleme adımı için MSBuild'e sesleniyorum. Hedefler dosyasını kontrol edecek.
Scott Mayfield

4

Yepyeni bir Windows 10 makinesinde de aynı sorunu yaşadım. Kurulumum:

  • Windows 10
  • Visual Studio 2015 Yüklendi
  • Windows 10 SDK

Ancak .NET 4.0 projeleri oluşturamadım:

Die Aufgabe konnte "AL.exe" mit dem SdkToolsPath-Wert "" veya Registrierungsschlüssel "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86

Çözüm: Windows 7 SDK'yı yüklemeyi denedikten (ve başarısız olduktan) sonra (çünkü bu, .NET 4.0 SDK'yı da içeriyor) Windows 8 SDK'yı yüklemem ve ".NET Framework 4.5 SDK" nın kurulu olduğundan emin olmam gerekiyordu.

Çılgınca ... ama işe yaradı.


Bu bana Windows 10'da da yardımcı oldu.
bourbert

3

Aslında SDK 7.0A sürümüne sahip değil misiniz? Bu, düzeltmeniz gereken bir sorun. Neyin yanlış gittiğini görmek için VS2010 yükleme günlük dosyalarına bakın. SDK c: \ program files \ microsoft sdks \ windows \ 7.0a içinde bulunmalı ve listelenen kayıt defteri anahtarı da mevcut olmalıdır. Sgen.exe'nin 6.0a sürümüyle çalışmak uygun değildir, yanlış derleyiciyi kullanmak zorundadır.


1
Unutmayın, bu bir derleme sunucusu, bu yüzden VS2010 ortamının tamamını kurmak benim ilk tercihim değildi. Windows SDK 7.0a'nın herhangi bir indirmesini bulamadım
Scott Mayfield

3
Sorunu görmüyorum. Yapılandırması geliştirici makineler ile uyuşmayan bir makinede bir derlemeyi çalıştırmak, sizi çabucak yıpratacak bir sorundur.
Hans Passant

3

Kurulum dizini dışında bir konum belirtmek Sdk40ToolsPathyerine ayarlayın SdkToolsPath.

AL.exe ile benzer bir sorunla karşılaştım çünkü araçları SDK'yı kurmak yerine yapı makinesine xcopledim, bu yüzden normal kayıt defteri anahtarları eksikti. Tanılama çıktısı (/ verbosity: diagnostik) içeren bir derleme çalıştırdım ve birkaç SDK aracı yolu tanımlandığını fark ettim: Sdk40ToolsPath, Sdk35ToolsPath ve SdkToolsPath. Sdk40ToolsPath'i uygun SDK sürümünün bin klasörüne işaret edecek şekilde ayarlamak sorunu benim için çözdü.


Sdk40ToolsPath'i nereye ayarladınız?
Michael Freidgeim

Çevre yoluna eklenmesi gerektiğini varsayıyorum. Ancak benim için işe yaramadı.
Timothy Lee Russell

Üzgünüm, bu çok uzun zaman önceydi, ayrıntıları unuttum, ancak bunun bir ortam değişkeni olduğunu veya MSBuild proje dosyasında ayarlandığını düşünüyorum. Ayrıca, orijinal sorunun .NET Framework 4.0 / VS2010 ile ilgili olduğunu, ancak daha sonraki çerçeve sürümleri için farklı değişkenlerin gerekli olabileceğini unutmayın.
IanS

2

IanS'ın cevabına katılıyorum. Yeni SDK yüklemenize gerek yok. Yalnızca MSBuild için SDK35ToolsPath ve SDK40ToolPath kayıt defteri anahtar değerlerinin doğru kayıt defteri anahtarı değerlerini gösterdiğinden emin olun.

Benim durumumda projem .NET 3.5 için hedeflenmişti ve HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 anahtarı için SDK35ToolsPath'i $ (Kayıt Defteri: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v6.0A \ olarak ayarlamak zorunda kaldım) WinSDKNetFxTools @ InstallationFolder). Ve her şey çalıştı.


2

WinXP derleme bilgisayarımız var ve yazılımımızı oluşturmak için Visual Build Pro 6 kullanıyoruz. Geliştiricilerimizden bazıları VS 2010 kullandığından, proje dosyaları artık "araç sürümü 4.0" için referans içeriyor ve söyleyebileceğim kadarıyla, bu, Visual Build'a bir yerde bir sdk7.x bulması gerektiğini söylüyor, yalnızca .NET 3.5 için oluşturmamıza rağmen . Bu, lc.exe'yi bulmamasına neden oldu. Tüm makroları bilgisayarda yüklü olan VS2008 ile gelen 6.0A sdk'ye yönlendirerek onu kandırmaya çalıştım, ancak bu işe yaramadı.

Sonunda sdk 7.1'i indirip yükleyerek çalıştırdım. Daha sonra 7.0A için bir kayıt defteri anahtarı oluşturdum ve kurulum yolunu 7.1 sdk'nin yükleme yoluna işaret ettim. şimdi mutlu bir şekilde uyumlu bir "lc.exe" bulur ve tüm kod iyi derlenir. VS2010 kurulu olmasa bile artık .NET 4.0 kodunu derleyebileceğime dair bir his var ama henüz denemedim.


2

ToolsVersion = "4.0" MSBuild projemde bunu benim için yapıyor:

<Project DefaultTargets="Do" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

Benim durumumda VS 2015 için ToolsVersion = "14.0" kullandım ve bu sorunu çözdü
AndrewSilver

2

Öncelikle dotNetFx40_Full_x86_x64.exe dosyasını indirdiğinizden ve yüklediğinizden emin olun (Genellikle Visual Stdio ile bağlanır).

Ardından, Sistem değişkenlerinde hızlı bir şekilde yeni bir Ortam Değişkenleri ayarlayın. aşağıdaki gibi: "TargetFrameworkSDKToolsDirectory":"C:\Program Files (x86)\Microsoft SDKs\Windows\vxx.0A\bin\NETFX 4.6.1 Tools" //note:the path:'\vxx.0A\' is a variable indicating your version. it's '\v10.0A\' for me.


Bu sorunu çözüyor. Eğer birisi I ile aynı sorunu yaşıyorsa sadece bir ipucu. Env Değişkeninin SdkToolsPath değil, TargetFrameworkSDKToolsDirectory olarak adlandırılması gerekir !!!
Markus

1

Aynı sorunu yaşadım ve sorunu çözmeyen Windows SDK 7.0 ve Windows SDK 7.1'i yükledim. Benim için sorunun nedeni, rahatsız edici sınıf kitaplığının .NET Framework 2.0 Hedef Çerçevesi ile oluşturulmuş olmasıydı.

Bunu .NET Framework 4.0 olarak değiştirdim ve yerel olarak çalıştım ve Build sunucusunda kontrol edildiğinde başarıyla oluşturdum.


1

Benzer bir sorunla karşılaştım, özellikle msbuild başarısız oldu: MSB3086, MSB3091: "AL.exe", "resgen.exe" bulunamadı

64 bitlik bir Windows 7 makinesinde, .Net framework 4.5.1 ve Windows 8.1 için Windows SDK kurdum.

SDK için kurulumlar güncel olduğunu söylese de, muhtemelen değildi. SDK'nın tüm yüklü sürümlerini kaldırarak ve ardından aşağıdaki sırayla aşağıdakileri yükleyerek sorunu çözdüm:

http://www.microsoft.com/en-us/download/details.aspx?id=3138

http://www.microsoft.com/en-us/download/details.aspx?id=8279

http://msdn.microsoft.com/en-us/windows/desktop/hh852363.aspx

http://msdn.microsoft.com/en-us/windows/desktop/aa904949.aspx


1

Kısa cevap: .csproj dosyasında, SGenToolPath kullanarak sgen.exe yolunu belirtmenin bir yolu vardır:

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="14.0">
  <PropertyGroup>
    <SGenToolPath>C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools</SGenToolPath>
  </PropertyGroup>

Yolunuz farklı olabilir, ancak SGenToolPath istediğiniz şeydir.

Diğer yaygın MSBuild Project özelliklerinin bir listesi için bkz: https://msdn.microsoft.com/en-us/library/bb629394.aspx

Yapı sunucusundaki kayıt defteri değerlerini düzenlemek yerine .csproj dosyasında bu SGenToolPath ayarını kullanmaya son verdik. Yerel makinemdeki kayıt defteri değerlerini düzenlemek de işe yaradı, ancak biraz daha karmaşıktı ve yapı sunucusundaki kayıt defteri ile uğraşmak istemedik.

Kayıt defteri için: Bu durumda sorun, HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild altındaki SDK40ToolsPath (ler) 'in bir kayıt defteri değerini $ (Kayıt: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A) göstermesiydi. \ WinSDK-NetFx40Tools-x86 @ InstallationFolder) yok. Bunu doğrudan gerçek yolla değiştirdim.


1

Ben de bu sorunla korkunç derecede karışık iş yeri bilgisayarımda Visual Studio 2017 kullanarak bir eklenti oluşturmaya çalışırken karşılaştım. İnternette "resgen.exe bulunamıyor" şeklinde arama yaparsanız, ' Windows Kayıt Defterinizi düzenlemek için regedit'i kullanın ve burada yeni bir anahtar oluşturun ve bu klasörün içeriğini kopyalayıp içine yapıştırın ' gibi tüm bu önerileri bulabilirsiniz . bu diğer klasör, blah blah blah. '

Regedit ile Windows Kayıt Defterimi karıştırarak haftalar geçirdim, muhtemelen bir düzine alt anahtar ekledim ve ResGen.exe'yi birçok farklı dizine kopyalayıp yapıştırdım, bazen bir 'bin' klasörüne koydum, bazen sadece ana klasörde tuttum. vb.

Sonunda, "Hey, eğer Visual Studio daha ayrıntılı bir hata mesajı verseydi, bunların hiçbiri sorun olmazdı." Bu nedenle, hatayla ilgili daha fazla ayrıntı almak için, MSBuild.exe'yi doğrudan * .csproj dosyamda komut satırından çalıştırdım:

 "C:/Windows/Microsoft.NET/Framework/v4.0.3.0319/MSBuild.exe C:/Users/Todd/Plugin.csproj -fl -flp:logfile="C:/Users/Todd/Desktop/error_log.log";verbosity=diagnostic"

Elbette, durumunuza uyacak şekilde yol ayrıntılarını değiştirmeniz gerekecektir, ancak 1) MSBuild.exe'nin tam yolunu 2) * .csproj dosyanızın tam yolunu 3) -fl -flp'yi koyduğunuzdan emin olun: logfile = part, MSBuild'e işlemde attığı her adım için bir günlük dosyası oluşturmasını söyleyecek, 4) * .log dosyasının kaydedilmesini istediğiniz konum ve 5); ayrıntı = tanılama, temelde sadece MSBuild'e söyler * .log dosyasına TONS ayrıntı eklemek için.

Bunu yaptıktan sonra, yapı her zamanki gibi başarısız olur, ancak MSBuild'in ResGen.exe dosyanızı tam olarak nerede aradığını gösteren bir * .log dosyası kalır. Benim durumumda, * .log dosyasının altına yakın bir yerde şunu buldum:

Compiling plug-in resources (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6.2\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6.1\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.6\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.1a\WinSDK-NetFx40Tools-x86 (Task ID:41)
Looking in key SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.0a\WinSDK-NetFx40Tools-x86 (Task ID:41)
MSBUILD: error : Failed to locate ResGen.exe and unable to compile plug-in resource file "C:/Users/Todd/PluginResources.resx"

Temelde MSBuild , ResGen.exe için beş ayrı dizine baktı ve sonra pes etti. Bu, Visual Studio hata mesajından alamayacağınız türden ayrıntıdır ve sorunu çözer: bu beş konumdan herhangi biri için bir anahtar oluşturmak için regedit'i kullanın ve anahtara "InstallationFolder" değerini girin , ResGen.exe dosyanızın bulunduğu klasörü göstermelidir (benim durumumda "C: \ Program Files \ Microsoft SDKs \ Windows \ v10.0A \ bin \ NETFX 4.7.2 Tools" idi).

Bilgisayarlarda arka planı olmayan benim gibi bir beşeri bilimler öğrencisiyseniz, Windows Kayıt Defterinizden düzenlemeyi yapmak ve bunun gibi bir hatayla karşılaştığınızda ResGen.exe'yi kopyalayıp yapıştırmak isteyebilirsiniz. tabii ki kötü uygulama). Yukarıda özetlenen prosedürü takip etmek daha iyidir: 1) MSBuild'in ResGen.exe'yi aradığı tam konumu bulmak için doğrudan * .csproj dosyanızda MSBuild.exe'yi çalıştırın, ardından 2) MSBuild'in ResGen'i bulabilmesi için Windows Kayıt Defterinizi tam olarak düzenleyin. exe.


Bunu denedim ama nedense görüntülediğiniz yolların listesini alamıyorum. Bu sitede sizinkine benzer bir gönderi buldum: community.sdl.com/developers-more/developers/… bu yüzden işe yaraması gerektiğini biliyorum, ancak boşuna. MSBuild'in hangi sürümünü kullanıyorsunuz?
user11809641

Görünüşe göre MSBuild 4.0.30319 sürümünü kullanıyorum. Ayrıca bu bilgisayarda 3.5, 3.0 ve 2.0.50727 sürümleri de yüklü. MSBuild'in bu sürümlerini * .csproj dosyamda çalıştırmayı denedim (yukarıda belirtilenle aynı şekilde), ancak işe yaramadı ... bir * .log dosyası bile oluşturmadı. /// * .csproj dosyanız üzerinde MSBuild'i çalıştırdığınızda, bilgisayar en azından bir * günlük dosyası mı üretiyor? Anladığım kadarıyla bir günlük dosyası var, ResGen.exe'yi ararken aranan yollarla ilgili hiçbir özel bilgi yok - bu doğru mu?
todbott

Görünüşe göre MSBuild'in (4.0.30319) aynı sürümüne sahibim. Ve evet, haklısın. Bir günlük dosyası alıyorum, ancak Kayıt defteri yolları hakkında herhangi bir bilgi vermiyor. Yukarıda gönderdiğiniz beş yoldan hangisini kullandınız?
user11809641

Listedeki 1. yolu kullandım - SOFTWARE \ WOW6432Node \ Microsoft \ Microsoft SDKs \ NETFXSDK \ 4.6.2 \ WinSDK-NetFx40Tools-x86 anahtarına bir "Kurulum Klasörü" ekledim. Ayrıca, * .log dosyası aslında çok uzun - benim durumumda binlerce satır. Yol bilgisini çıplak gözle bulamadım. * .Log dosyasını Not Defteri'nde açtım ve ilgili alana (yol bilgileri) dikkatimi çeken "ResGen.exe" yi aradım.
todbott

1
Süper - tebrikler! Hatalar ve gizemle savaşan ve aslında Trados için bir eklentiyi başarıyla derleyen bir avuç insandan (sanırım birkaç yüz) biri oldunuz. Eklenti yayınlamanızda bol şanslar, SDL Appstore'da görüşmek üzere!
todbott

1

Bunu komut satırı parametresi olarak msbuild.exe'ye ileterek düzelttim:

Kilometreniz, sisteminizdeki SDK sürümüne bağlı olarak değişecektir.

/p:TargetFrameworkSDKToolsDirectory="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools

0

Kayıt defteri modlarının yanı sıra, ayarlarınızın Visual Studio'da ayarlanan .net sdk sürümünü değiştirmeniz gerekebilir.

Bu sorunu yaşıyordum ve proje hata ayıklama ayarlarını kontrol etmeye karar verdim.

Proje => Araç Çubuğu Özellikleri => Hata Ayıklama Gelişmiş Derleme Seçenekleri düğmesi

Hedef Çerçeve (tüm konfigürasyonlar), sistemimde olmayan 3.0'a ayarlandı.

Bunu 4.0 olarak değiştirdim, ardından projeyi ve Visual Studio 2010'u yeniden başlatmak zorunda kaldım.

Proje daha sonra hatasız inşa edildi ve çalıştı.


Bir hata yaptım, aşağıda buldum. Proje => Araç Çubuğu Özellikleri => Gelişmiş Derleme Seçenekleri düğmesi Ayrıca yeni bir proje oluşturdum ve yeni proje .net 3.0 olarak ayarlandı. Bu nedenle varsayılan ayarı da değiştirmeniz gerekecektir. Scott A. Tovey
Scott Tovey

Bir proje oluşturduğunuzda, pencerenin üst kısmında tüm çerçevelerin bir açılır listesi olduğunu öğrendim. Her şey kurulu olup olmadığına bakılmaksızın listelenir. Bir çerçeve seçip bu listeden bir proje oluşturduğunuzda, siz onu yeni bir proje için başka bir çerçeveye değiştirene kadar varsayılan olarak kalır. Bu biraz umursamaz, liste yalnızca sistemde kurulu olan çerçeveleri içermelidir.
Scott Tovey

0

Benzer bir problemim vardı. Kullanarak bir proje yaptım Visual Studio 2010ve kullanarak derlediğimde yukarıdaki hatayı aldım Visual Studio 2012. Tüm içeriğini C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0Aiçine kopyaladım C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0Ave bu benim sorunumu çözdü.


3
Keşke dünyanın en kötü çözümü için bir oy olsaydı. Bu o olurdu.
jonypony3

0

Başlangıçta Visual Studio 2010'da oluşturulan (ve Visual Studio 2010 ve TFS 2010 tarafından oluşturulan) bir .sln dosyasında bu hatayı aldım. Çözüm dosyasını, belirli bir konfigürasyonda oluşturulmaması gereken bir proje OLUŞTURMAMAK için değiştirdim ve görsel stüdyo, çözüm dosyasının başlığını şu şekilde değiştirdim:

Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010

Kime:

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 14
VisualStudioVersion = 14.0.24720.0
MinimumVisualStudioVersion = 10.0.40219.1

Orijinal 2010 sürümüne geri döndürmek sorunumu çözdü. Sanırım Visual Studio'da geriye dönük uyumluluk hala mükemmelleştirilmedi.


0

görsel stüdyonun "onarımını" kullanmayı deneyin. Benim için çalıştı.


0

CMD sarıcı
Buradaki her şeyi ve hatta daha fazlasını denedim. Bana hiçbir şey yardımcı olmadı.

MSBuild ve DevEnv.com için bir CMD sarmalayıcı uyguladım.
Böyle bir sarmalayıcının içindeki ana fikir, Visual Studio kaynağından Komut İstemlerini çağırarak hazırlanmış bir ortam oluşturmaktır. Ve sonra standart giriş parametrelerini bir MSBuild veya DevEnv.com çağrısına geçirin.

Her neyse, derleme sunucumda artık farklı Visual Studio sürümlerinden projeler oluşturabiliyorum.

Nasıl kullanılır
MSBuild ve DevEnv çağrılarını toplu iş dosyası sarmalayıcılarıma bir çağrı ile değiştirmem gerekiyordu.
Ve hiçbir giriş parametresini değiştirmedim. MSBuild sarmalayıcı çağrıma örnek olarak:

MsBuild_Wrapper.bat MySolution.sln /target Build /property:Configuration=Release

Hazır çözüm
Aslında, VS 2010'dan VS 2015'e geçişte çok daha fazla sorun yaşadım. Ancak bu, ilk ve en zor olanıydı.
Yani, Build Server için mütevazı kurtarma tarifim burada. Muhtemelen tüm bu CMD stilini ilk andan itibaren anlamak zordur, ancak herhangi bir mantık aşikardır, umarım.

İpuçları
var
MSBuild Command Prompt for Visual Studiove Developer Command Prompt for Visual Studio
bunları MSBuild ve DevEnv.com için uygun şekilde kullanıyorum. Ancak muhtemelen MSBuild Komut İstemi yeterli olacaktır.

VS 2015 için bu komut istemleri burada C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\. Veya Windows programları menüsüne bakın.

Tüm girdi parametrelerini kullandığım bir toplu iş dosyası içinde MSBuild veya DevEnv'e geçirmek için CALL MSBuild %*

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.