Uruchamianie programu MSBuild nie może odczytać SDKToolsPath


131

Cześć, mam mały problem z uruchomieniem skryptu NAnt, który służył do poprawnego budowania mojej strony internetowej opartej na .Net 2.0, podczas kompilacji z VS2008 i powiązanymi z nim narzędziami. Niedawno zaktualizowałem wszystkie pliki projektu / rozwiązania do VS2010, a teraz moja kompilacja kończy się niepowodzeniem z następującym błędem:

[exec] C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (2249,9): błąd MSB3086: zadanie nie może znaleźć „sgen.exe” przy użyciu S dkToolsPath „” lub rejestru klucz „HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A”. Upewnij się, że SdkToolsPath jest ustawiona, a narzędzie znajduje się we właściwej lokalizacji dla procesora w SdkToolsPath i że jest zainstalowany zestaw Microsoft Windows SDK

Teraz MAM wcześniejsze wersje (.Net 3.5) zestawu Windows SDK zainstalowane na serwerze kompilacji i pełne środowisko .Net 4.0 jest zainstalowane, ale nie korzystałem z wersji zestawu Windows SDK specyficznej dla .Net 4.0.

Po kilku eksperymentach i badaniach, w końcu po prostu ustawiłem nową zmienną środowiskową „SDKToolsPath” i wskazałem ją na kopię sgen.exe w folderze sdk w systemie Windows 6.0. Spowodowało to ten sam błąd, ale zauważyłem, że chociaż zmienna środowiskowa SDKToolsPath jest ustawiona (potwierdzono, że mogę ją odtworzyć w wierszu poleceń i ma oczekiwaną wartość), komunikat o błędzie wydaje się wskazywać, że jest to nie są czytane (zwróć uwagę na puste cudzysłowy).

Większość znalezionych przeze mnie informacji dotyczy domeny .Net 3.5 (lub starszej). Niewiele jeszcze tam związanych z 4.0. Wyszukiwanie kodu błędu MSB3086 również nie przyniosło nic użytecznego. Masz jakiś pomysł, co to może być?

Scott


Powiązany problem w tym poście. Tam też zamieściłem odpowiedź. stackoverflow.com/questions/1109955/…
Diego C.

Odpowiedzi:


15

Musiałem ugryźć kulę i zainstalować VS 2010 na naszym serwerze kompilacji, aby naprawić ten problem. O ile widzę, w MSDN nie ma wersji 7.0A zestawu Windows SDK. Jednak wydaje się, że zainstalowanie VS 2010 powoduje zainstalowanie go, tworząc klucz regatowy 7.0A i folder 7.0A w Program Files \ Microsoft SDKs \ Windows.


9
Wolę nie instalować programu Visual Studio 2010 na serwerze. Wolę sugestię Simmo poniżej dotyczącą ustawienia obecnego zestawu Windows SDK na wersję 7.1. WindowsSdkVer.exe znajduje się w C: \ Program Files \ Microsoft SDKs \ Windows \ v7.1 \ Setup (zakładając, że został zainstalowany w C: \ Program Files).
Philippe,

55
Odkryłem, że jeśli instalujesz tylko Windows SDK 7.1 i .NET 4.0. MSBuild nie ustawia prawidłowych ścieżek do SDK40ToolsPath i SDK35ToolsPath. Aby to naprawić, musiałem zmienić kilka wpisów w HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0: "SDK40ToolsPath" = "$ (Rejestr: HKEY_LOCAL_MACHINE \\ SOFTWARE \\ Microsoft \\ Microsoft SDKs \\ Windows \\ v7 .1 \\ WinSDK-NetFx40Tools-x86 @ InstallationFolder) "Podobnie zmień" v7.0A "na" v7.1 "w SDK35ToolsPath i FrameworkSDKRoot.
BlueMonkMN

7
Sheesh - sam ponownie napotkałem ten sam problem, wyszukałem go w Google i znalazłem własną odpowiedź! :) Wydaje się, że coś zresetowało moją zmianę i wydaje mi się, że muszę ręcznie zastosować ją ponownie.
BlueMonkMN

3
ARRRGH! Najnowsze poprawki .NET 4.0 (2011-08-11) nadpisały te ustawienia rejestru!
si618

8
Zaktualizuj moją wcześniejszą odpowiedź. Wygląda na to, że w 64-bitowych systemach operacyjnych może być również konieczne zaktualizowanie podobnych wartości w HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 i może być konieczne zainstalowanie zestawu 8.0 SDK lub zaktualizowanie wartości w HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 i HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 \ 11.0 Wykonałem wszystkie powyższe z wyjątkiem instalacji 8.0 SDK i nie mogłem się skompilować aż do I (jako jedna partia step) zawierał moje aktualizacje do wszystkich węzłów 4.0 \ 11.0.
BlueMonkMN

227

Nie mogłem stawić czoła umieszczeniu programu Visual Studio na serwerze kompilacji.

SDK v7.0A to zestaw SDK instalowany z programem Visual Studio 2010 (litera A oznacza, że ​​jest to wersja VS). Od tego czasu została wydana nowsza wersja. Microsoft Windows SDK dla Windows 7 i .NET Framework AKA v7.1 .

Zainstalowałem to na moim serwerze kompilacji. Następnie za pomocą wiersza polecenia zestawu Windows SDK 7.1 (Start => Wszystkie programy => Microsoft Windows SDK 7.1) ustawiam domyślną wersję zestawu SDK na 7.1.

Kroki:

cd Setup

WindowsSdkVer.exe -version:v7.1

Edytuj, aby uwzględnić komentarz LordHits: nie trzeba instalować całego zestawu SDK. Wystarczy zainstalować tylko opcje „.NET Development / Intellisense and Reference Assemblies” i „.NET Development / Tools”.


4
To zadziałało idealnie dla mnie, w połączeniu z kopiowaniem plików do C: \ Program Files \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications z mojej maszyny VS.
dnolan

1
Miałem ten sam problem, co pierwotny autor i ta odpowiedź go rozwiązała! Nie musiałem instalować programu Visual Studio 2010 na moim komputerze kompilacji.
Rozwiązanie

37
Ponadto, dla wyjaśnienia, nie trzeba instalować całego zestawu SDK. Wystarczy zainstalować tylko opcje „.NET Development / Intellisense and Reference Assemblies” i „.NET Development / Tools”. To i skopiowanie plików z komentarza dnolana.
Lord Hits

Dzięki za to rozwiązanie, zadziałało idealnie na naszym serwerze kompilacji! Do Twojej wiadomości - dla każdego, kto może mieć wątpliwości, serwerem kompilacji jest Windows Server 2008 x64.
Adam Weber,

Dziękuję bardzo za tę odpowiedź; napotkałem ten sam problem w pracy z tym.
Abe

22

Po prostu przekaż parametr GenerateSerializationAssemblies z wartością Off do MsBuild.

msbuild.exe /p:GenerateSerializationAssemblies=Off

7
msbuild.exe / p: GenerateSerializationAssemblies = Off
Daniel

3
Lub ustaw opcję „Generuj zestaw serializacji: wyłączone” na karcie Kompilacja we właściwościach projektu usługi sieci Web.
samneric

6
Co to dokładnie robi?
zmiażdżyć

1
GOTCHA: Jeśli wyłączysz to na karcie kompilacji, upewnij się, że robisz to dla odpowiedniej konfiguracji kompilacji (DropDown na górze karty Kompilacja) w moim przypadku był to tylko serwer kompilacji z problemem, więc musiałem zmień to w konfiguracji „Release”.
Myster

14
Uwielbiam po prostu losowo przełączać flagi kompilacji bez pojęcia, co tak naprawdę robią.
AaronLS

14

Ręcznie przekazuję zmienne do programu MSBuild na serwerze kompilacji.

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
Właśnie to zrobiłem dla Windows 10 SDK na serwerze bez Visual Studio i Build Tools 2019. Żadne z innych rozwiązań nie wydawało się pomagać, a to załatwiło sprawę w czysty sposób.
Nicolás Fantone

8

Niedawno napotkałem podobny problem na naszym serwerze kompilacji.

Skopiowałem folder 7.0A (C: \ Program Files \ Microsoft SDKs \ Windows \ 7.0A) z mojego komputera (na którym jest zainstalowany VS2010) na serwer kompilacji w tej samej lokalizacji.

Po utworzeniu następującego klucza rejestru: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.0A. Ustaw folder InstallationFolder na C: \ Program Files \ Microsoft SDKs \ Windows \ 7.0A.

Możesz również odwołać się do rejestru na komputerze, na którym jest już zainstalowany VS2010, jeśli nie wiesz, co zrobić z rejestrem na serwerze kompilacji.


Dla mnie odpowiedź Simmo nie zadziałała - ten hack rejestru zadziałał (Win 2K3 SP2).
FinnNk

7

Napotkałem ten sam błąd, ale w innej sytuacji: używając VS 2010 Express i próbując użyć odpowiedzi Simmo, aby jawnie ustawić wersję SDK - jednak WindowsSdkVer.exe (narzędzie do ustawiania wersji) wydaje się nie być celem Express (zrozumiałe, ponieważ jest ograniczone ).

Używam VS 2010 Express na Win 7 Prof. i zawsze chce używać wersji 7.0A Win SDK (która nie ma wszystkich potrzebnych exe) i nie ma znaczenia, którą wersję wyraźnie ustawiłem jako bieżącą przy użyciu WindowsSdkVer.exe (ciągle raportuje, że ustawia bieżącą wersję SDK, ale dla VS 2008, chociaż mam tylko 2010 Ex zainstalowany).

Więc moim tanim obejściem było zainstalowanie v7.0 WIN SDK (lub innej wersji, takiej jak v7.1), a następnie zmiana nazwy folderu systemu plików na v7.0A - po prostu okłamałem VS 2010 Express, ale teraz działa!


5

Jeden z Twoich projektów używa sgen.exe (Server Generator) do generowania usługi internetowej. musisz zainstalować zestawy SDK, aby zbudować serwer lub usunąć odwołania do usług sieci Web z projektu.


1
Lub ustaw opcję „Generuj zestaw serializacji: wyłączone” na karcie Kompilacja we właściwościach projektu usługi sieci Web.
samneric

1
GOTCHA: Jeśli wyłączysz to na karcie kompilacji, upewnij się, że robisz to dla odpowiedniej konfiguracji kompilacji (DropDown na górze karty Kompilacja) w moim przypadku był to tylko serwer kompilacji z problemem, więc musiałem zmień to w konfiguracji „Release”.
Myster

5

Miałem ten sam problem na zupełnie nowym komputerze z systemem Windows 10. Moja konfiguracja:

  • Windows 10
  • Zainstalowano program Visual Studio 2015
  • Zestaw SDK systemu Windows 10

Ale nie mogłem zbudować projektów .NET 4.0:

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

Rozwiązanie: Po próbie zainstalowania zestawu SDK systemu Windows 7 (ponieważ zawiera on również zestaw SDK .NET 4.0) (ale nie powiodło się), musiałem zainstalować zestaw SDK systemu Windows 8 i upewnić się, że jest zainstalowany zestaw „.NET Framework 4.5 SDK”.

To szalone ... ale zadziałało.


To dokładnie pomogło mi również w systemie Windows 10.
bourbert,

4

Podejrzewam, że plik docelowy zastępuje ścieżkę narzędzi, szybko przejrzałem ten plik i ustawia SDKToolsPath na $ TargetFrameworkSDKToolsDirectory pod niektórymi celami w tym miejscu. Nie sądzę, aby i tak trzeba było ustawiać je w środowisku, ale mogą wymagać naprawy w plikach projektu.

Zauważ, że według tej strony http://nant.sourceforge.net/ Nant nie obsługuje .Net 4.0, czy może to być prawdziwy problem?

Przepraszam, wiem, że to tak naprawdę nie odpowiada na twoje pytanie :(


Prawidłowo, NAnt nie obsługuje jeszcze formatów plików projektu / rozwiązania dla VS2010, dlatego wzywam MSBuild do właściwego kroku kompilacji. Spisze plik celów.
Scott Mayfield

3

Nie masz zainstalowanego pakietu SDK w wersji 7.0A? To problem, który musisz rozwiązać. Zajrzyj do plików dziennika instalacji VS2010, aby zobaczyć, co poszło nie tak. Zestaw SDK powinien znajdować się w katalogu c: \ program files \ microsoft sdks \ windows \ 7.0a, a wymieniony klucz rejestru również musi być obecny. Uruchamianie z wersją 6.0a sgen.exe nie jest poprawne, prawdopodobnie użyje niewłaściwego kompilatora.


1
Pamiętaj, że jest to serwer kompilacji, więc zainstalowanie pełnego środowiska VS2010 nie było moim pierwszym wyborem. Nie mogłem znaleźć żadnego dostępnego do pobrania zestawu Windows SDK 7.0a
Scott Mayfield

3
Nie widzę problemu. Uruchomienie kompilacji na maszynie, której konfiguracja nie pasuje do maszyn deweloperskich, to problem, który szybko cię zużyje.
Hans Passant

3

Ustaw Sdk40ToolsPathraczej niż SdkToolsPathokreślić lokalizację inną niż katalogu instalacyjnym.

Napotkałem podobny problem z AL.exe, ponieważ właśnie skopiowałem narzędzia na maszynę kompilacji, zamiast instalować SDK, więc brakowało zwykłych kluczy rejestru. Uruchomiłem kompilację z wyjściem diagnostycznym (/ gadatliwość: diagnostyka) i zauważyłem, że zdefiniowano kilka ścieżek narzędzi SDK: Sdk40ToolsPath, Sdk35ToolsPath i SdkToolsPath. Ustawienie Sdk40ToolsPath tak, aby wskazywało na folder bin odpowiedniej wersji zestawu SDK, rozwiązało problem.


Gdzie ustawiłeś Sdk40ToolsPath?
Michael Freidgeim

Zakładałbym, że trzeba to dodać do ścieżki środowiska. Jednak to nie zadziałało.
Timothy Lee Russell

Przepraszam, że to było tak dawno temu, że zapomniałem szczegółów, ale myślę, że była to zmienna środowiskowa lub ustawiona w pliku projektu MSBuild. Należy również zauważyć, że pierwotne pytanie dotyczy .NET Framework 4.0 / VS2010, ale w późniejszych wersjach mogą być potrzebne inne zmienne.
IanS,

2

Zgadzam się z odpowiedzią IanSa. Nie ma potrzeby instalowania nowego SDK. Po prostu upewnij się, że wartości kluczy rejestru SDK35ToolsPath i SDK40ToolPath for MSBuild wskazują poprawne wartości kluczy rejestru.

W moim przypadku mój projekt był przeznaczony dla .NET 3.5 i musiałem ustawić SDK35ToolsPath dla klucza HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSBuild \ ToolsVersions \ 4.0 do $ (Rejestr: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v6.0A \ WinSDKNetFxTools @ InstallationFolder). I wszystko działało.


2

Mamy komputer do kompilacji winXP i używamy programu Visual Build Pro 6 do tworzenia oprogramowania. ponieważ niektórzy z naszych programistów używają VS 2010, pliki projektu zawierają teraz odniesienie do „narzędzia w wersji 4.0” iz tego, co wiem, informuje to Visual Build, że musi gdzieś znaleźć sdk7.x, mimo że tworzymy tylko dla .NET 3.5 . To spowodowało, że nie znalazł lc.exe. Próbowałem go oszukać, wskazując wszystkie makra na sdk 6.0A, który był dostarczony z VS2008, który jest zainstalowany na komputerze, ale to nie zadziałało.

W końcu udało mi się to uruchomić, pobierając i instalując pakiet SDK 7.1. Następnie utworzyłem klucz rejestru dla wersji 7.0A i wskazałem ścieżkę instalacji na ścieżkę instalacji zestawu SDK 7.1. teraz szczęśliwie znajduje zgodny "lc.exe" i cały kod kompiluje się dobrze. Mam wrażenie, że teraz będę mógł skompilować kod .NET 4.0, mimo że VS2010 nie jest zainstalowany, ale jeszcze tego nie próbowałem.


2

ToolsVersion = "4.0" robi to za mnie w moim projekcie MSBuild:

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

Cóż, w moim przypadku użyłem ToolsVersion = "14.0" dla VS 2015 i to rozwiązało problem
AndrewSilver

2

Najpierw upewnij się, że już pobrałeś i zainstalowałeś dotNetFx40_Full_x86_x64.exe (zwykle jest powiązany z Visual Stdio).

Następnie szybko ustaw nowe zmienne środowiskowe w zmiennych systemowych. jak poniżej: "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.


To jest rozwiązanie problemu. Tylko wskazówka, jeśli ktoś ma ten sam problem co I. Zmienna Env musi nazywać się TargetFrameworkSDKToolsDirectory, a nie SdkToolsPath !!!
Markus,

1

Miałem ten sam problem i zainstalowałem Windows SDK 7.0 i Windows SDK 7.1, które nie rozwiązały problemu. Przyczyną problemu dla mnie było to, że niewłaściwa biblioteka klas została zbudowana przy użyciu platformy docelowej .NET Framework 2.0.

Zmieniłem go na .NET Framework 4.0 i pracowałem lokalnie, a po sprawdzeniu w serwerze Build pomyślnie go zbudowałem.


1

Miałem podobny problem, w szczególności błąd msbuild: MSB3086, MSB3091: „AL.exe”, „resgen.exe” nie został znaleziony

Na 64-bitowym komputerze z systemem Windows 7 zainstalowałem .Net framework 4.5.1 i Windows SDK dla Windows 8.1.

Chociaż ustawienia SDK mówiły, że jest aktualne, prawdopodobnie tak nie było. Rozwiązałem problem, usuwając wszystkie zainstalowane wersje pakietu SDK, a następnie instalując następujące elementy w tej kolejności:

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

Krótka odpowiedź: w pliku .csproj istnieje sposób na określenie ścieżki do sgen.exe za pomocą SGenToolPath:

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

Twoja ścieżka może być inna, ale SGenToolPath jest tym, czego chcesz.

Aby uzyskać listę innych typowych właściwości projektu MSBuild, zobacz: https://msdn.microsoft.com/en-us/library/bb629394.aspx

Skończyło się na tym, że użyliśmy tego ustawienia SGenToolPath w pliku .csproj, zamiast edytować wartości rejestru na serwerze kompilacji. Edycja wartości rejestru na moim komputerze lokalnym również działała, ale była nieco bardziej skomplikowana i nie chcieliśmy mieszać w rejestrze na serwerze kompilacji.

W przypadku rejestru: w tym przypadku problem polegał na tym, że ścieżka (y) SDK40ToolsPath w HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild wskazywała na wartość rejestru $ (Registry: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v8.0A \ WinSDK-NetFx40Tools-x86 @ InstallationFolder), który nie istniał. Właśnie zastąpiłem to bezpośrednio rzeczywistą ścieżką.


1

Ja też napotkałem ten problem, próbując zbudować wtyczkę przy użyciu programu Visual Studio 2017 na moim okropnie popsutym komputerze w miejscu pracy. Jeśli wyszukujesz w Internecie hasło „nie można znaleźć pliku resgen.exe”, możesz znaleźć wszystkie porady w stylu „ po prostu użyj regedit do edycji rejestru systemu Windows i utwórz nowy klucz tutaj i skopiuj i wklej zawartość tego folderu do ten inny folder, bla bla bla.'

Spędziłem tygodnie po prostu psując mój Rejestr Windows za pomocą regedit, prawdopodobnie dodałem tuzin podkluczy i skopiowałem ResGen.exe do wielu różnych katalogów, czasami umieszczając go w folderze `` bin '', czasami po prostu trzymając go w folderze głównym, itp.

W końcu zdałem sobie sprawę: „Hej, gdyby Visual Studio podał bardziej szczegółowy komunikat o błędzie, nic z tego nie byłoby problemem”. Aby więc uzyskać więcej informacji na temat błędu, uruchomiłem MSBuild.exe bezpośrednio w moim pliku * .csproj z wiersza poleceń:

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

Oczywiście będziesz musiał zmienić szczegóły ścieżki, aby pasowały do ​​twojej sytuacji, ale pamiętaj, aby umieścić 1) pełną ścieżkę do MSBuild.exe 2) pełną ścieżkę do pliku * .csproj 3) -fl -flp: logfile = part, który powie MSBuild, aby utworzył plik dziennika z każdym krokiem wykonanym w procesie, 4) lokalizację, w której chcesz zapisać plik * .log i 5); verbosity = diagnostyka, która w zasadzie po prostu informuje MSBuild aby dołączyć TONY szczegółów do pliku * .log.

Po wykonaniu tej czynności kompilacja zakończy się niepowodzeniem, jak zawsze, ale pozostanie plik * .log pokazujący dokładnie, gdzie program MSBuild szukał pliku ResGen.exe. W moim przypadku w dolnej części pliku * .log znalazłem:

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"

Zasadniczo MSBuild przeszukał pięć oddzielnych katalogów pod kątem ResGen.exe, a następnie zrezygnował. Jest to rodzaj szczegółów, których po prostu nie można uzyskać z komunikatu o błędzie programu Visual Studio i rozwiązuje problem: po prostu użyj regedit, aby utworzyć klucz dla dowolnej z tych pięciu lokalizacji i umieść w nim wartość „InstallationFolder” , który powinien wskazywać na folder, w którym znajduje się plik ResGen.exe (w moim przypadku był to „C: \ Program Files \ Microsoft SDKs \ Windows \ v10.0A \ bin \ NETFX 4.7.2 Tools”).

Jeśli jesteś magistrem humanistyki, takim jak ja i nie masz doświadczenia w komputerach, możesz ulec pokusie, aby po prostu wyedytować do cholery swój rejestr systemu Windows i skopiować i wkleić plik ResGen.exe w każdym miejscu, gdy napotkasz taki błąd (którym jest oczywiście zła praktyka). Lepiej postępować zgodnie z procedurą opisaną powyżej: 1) Uruchom MSBuild.exe bezpośrednio w pliku * .csproj, aby znaleźć dokładną lokalizację, w której MSBuild szuka ResGen.exe, a następnie 2) edytuj dokładnie rejestr systemu Windows, aby program MSBuild mógł znaleźć ResGen. exe.


Próbowałem tego, ale z jakiegoś powodu nie otrzymuję listy ścieżek, które wyświetlasz. Znalazłem post podobny do twojego na tej stronie: community.sdl.com/developers-more/developers/, więc wiem, że powinien działać, ale bezskutecznie. Której wersji programu MSBuild używasz?
user11809641

Wygląda na to, że używam programu MSBuild w wersji 4.0.30319. Mam też wersję 3.5, 3.0 i 2.0.50727 zainstalowaną na tym komputerze. Próbowałem uruchomić te wersje MSBuild na moim pliku * .csproj (w taki sam sposób, jak opisano powyżej), ale to nie zadziałało ... nawet nie utworzyłem pliku * .log. /// Czy po uruchomieniu programu MSBuild na pliku * .csproj komputer tworzy przynajmniej * plik dziennika? Rozumiem, że istnieje plik dziennika, ale nie ma konkretnych informacji dotyczących ścieżek, które były przeszukiwane podczas wyszukiwania ResGen.exe - czy to prawda?
todbott

Wygląda na to, że mam tę samą wersję programu MSBuild (4.0.30319). I tak, masz rację. Otrzymuję plik dziennika, ale nie zawiera on żadnych informacji o ścieżkach rejestru. Którą z pięciu ścieżek, które opublikowałeś powyżej, ostatecznie użyłeś?
user11809641

Użyłem pierwszej ścieżki na liście - właśnie dodałem „InstallationFolder” w kluczu SOFTWARE \ WOW6432Node \ Microsoft \ Microsoft SDKs \ NETFXSDK \ 4.6.2 \ WinSDK-NetFx40Tools-x86. Ponadto plik * .log jest w rzeczywistości bardzo długi - w moim przypadku tysiące wierszy. Nie mogłem znaleźć informacji o ścieżce gołym okiem. Ostatecznie otworzyłem plik * .log w Notatniku i wyszukałem „ResGen.exe”, co zwróciło moją uwagę na odpowiedni obszar (informacje o ścieżkach).
todbott

1
Super - gratulacje! Stałeś się jedną z nielicznych osób (jak sądzę, kilkuset), którzy pokonali błędy i tajemnice i faktycznie pomyślnie skompilowali wtyczkę do Tradosa. Powodzenia w publikowaniu wtyczek, do zobaczenia w SDL Appstore!
todbott

1

Naprawiłem to, przekazując to jako parametr wiersza polecenia do msbuild.exe:

Twój przebieg będzie się różnić w zależności od wersji SDK, którą masz w swoim systemie

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

0

Oprócz modów rejestru może być konieczna zmiana wersji zestawu SDK .NET z ustawieniami ustawionymi w programie Visual Studio.

Miałem ten problem i postanowiłem sprawdzić ustawienia debugowania projektu.

Projekt => Właściwości paska narzędzi => przycisk Debuguj zaawansowane opcje kompilacji

Struktura docelowa (wszystkie konfiguracje) została ustawiona na 3,0, którego nie ma w moim systemie.

Zmieniłem to na 4.0, potem musiałem zrestartować projekt i Visual Studio 2010.

Projekt został następnie zbudowany bez błędów i uruchomiony.


Popełniłem błąd, to znajduje się poniżej. Projekt => Właściwości paska narzędzi => Kompiluj Advance Opcje kompilacji Stworzyłem również nowy projekt i nowy projekt .net został ustawiony na 3.0. Będzie więc konieczna zmiana ustawienia domyślnego. Scott A. Tovey
Scott Tovey

Dowiedziałem się, że podczas tworzenia projektu w górnej części okna znajduje się rozwijana lista wszystkich frameworków. Wszystko jest wymienione, niezależnie od tego, czy jest zainstalowane, czy nie. Po wybraniu struktury i utworzeniu projektu z tej listy pozostaje ona domyślna, dopóki nie zmienisz jej na inną platformę dla nowego projektu. Jest to trochę lekkomyślne, lista powinna zawierać tylko frameworki, które są zainstalowane w systemie.
Scott Tovey,

0

Miałem podobny problem. Zrobiłem projekt przy użyciu, Visual Studio 2010a następnie otrzymałem powyższy błąd, gdy kompilowałem go przy użyciu Visual Studio 2012. Po prostu skopiowałem całą zawartość C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0Ado C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0Ai to rozwiązało mój problem.


4
Chciałbym, żeby głosowano za najgorszym rozwiązaniem na świecie. To byłoby to.
jonypony3

0

Właśnie wystąpił ten błąd z plikiem .sln, który został pierwotnie utworzony w programie Visual Studio 2010 (i jest budowany przez Visual Studio 2010 i TFS 2010). Zmodyfikowałem plik rozwiązania, aby NIE budować projektu, który nie miał być zbudowany w określonej konfiguracji, a Visual Studio zmieniło nagłówek pliku rozwiązania z:

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

Do:

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

Przywrócenie oryginalnej wersji 2010 rozwiązało mój problem. Wydaje mi się, że wsteczna kompatybilność w Visual Studio nie została jeszcze udoskonalona.


0

spróbuj skorzystać z „naprawy” programu Visual Studio. U mnie to zadziałało.


0

Opakowanie CMD
Wypróbowałem wszystkie rzeczy stąd, a nawet więcej. Nic mi nie pomogło.

Zastosowałem otoki CMD dla MSBuild i DevEnv.com.
Główną ideą takiego wrappera jest stworzenie przygotowanego środowiska poprzez wywołanie Command Prompt z materiału Visual Studio. Następnie przekaż standardowe parametry wejściowe do wywołania programu MSBuild lub DevEnv.com.

W każdym razie na moim serwerze kompilacji mogę teraz tworzyć projekty z różnych wersji programu Visual Studio.

Jak używać
Musiałem zastąpić wywołania MSBuild i DevEnv przez wywołanie moich opakowań plików wsadowych.
I nie zmieniłem żadnych parametrów wejściowych. Jako przykład dla mojego wywołania otoki MSBuild:

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

Gotowe rozwiązanie
Tak naprawdę dużo więcej kłopotów miałem z migracją z VS 2010 do VS 2015. Ale ten był pierwszy i najtrudniejszy.
Tak więc moja skromna recepta na ratunek dla serwera kompilacji jest tutaj. Być może trudno jest zrozumieć cały ten styl CMD od pierwszej chwili, ale mam nadzieję, że jakakolwiek logika jest oczywista.

Wskazówki

MSBuild Command Prompt for Visual Studioi Developer Command Prompt for Visual Studio
używam ich odpowiednio dla MSBuild i DevEnv.com. Ale prawdopodobnie wystarczy wiersz polecenia MSBuild.

W przypadku VS 2015 te monity poleceń są tutaj C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\ . Lub przejrzyj menu programów systemu Windows.

Aby przekazać wszystkie parametry wejściowe do MSBuild lub DevEnv wewnątrz pliku wsadowego, którego użyłem CALL MSBuild %*

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.