Uruchamianie programu MSBuild nie może odczytać SDKToolsPath

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

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.

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

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

msbuild.exe /p:GenerateSerializationAssemblies=Off

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"

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.

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!

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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

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

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.

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

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.

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.

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.

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

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
są
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 %*