Wersja 11.0 \ WebApplications \ Microsoft.WebApplication.targets nie została znaleziona, gdy plik faktycznie odwołuje się do wersji 10

84

Najpierw trochę tła. Pod koniec 2012 r. Dokonaliśmy migracji naszego rozwiązania vs2008 do vs2010, ale nadal naszym celem jest .NET 3.5. (Nie znam nic poza najnowszymi i najlepszymi tutaj!)

Nie mieliśmy żadnych problemów z tą konfiguracją, aż kilka tygodni temu, kiedy ludzie zaczęli otrzymywać te błędy:

"foo.csproj" (Rebuild target) (16:5) ->
  C:\...\foo.csproj(142,3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

Ciekawe jest to, że jeśli spojrzysz na plik projektu, odnosi się on do wersji 10, co ma sens, ponieważ nie używamy Visual Studio 2012.

Ten błąd dotknął kilku z nas naraz, a nawet w starszych gałęziach kodu, które nie zmieniły się od miesięcy.

Podejrzewam, że jakaś aktualizacja została wypchnięta na nasze maszyny, co spowodowało zamieszanie, ale nie wiem, co z tym zrobić.

Krótkoterminowym rozwiązaniem było zainstalowanie VS 2012 i nie używanie go, ale mam nadzieję na coś nieco czystszego niż to.

drs9222
źródło
17
Zauważyłem, że dodanie „/p:VisualStudioVersion=10.0” do wiersza poleceń programu MSBuild sprawia, że ​​to znika, ale nadal wydaje się, że jest to włamanie.
drs9222

Odpowiedzi:

116

Napotkałem ten sam problem z Visual Studio 2013. Okazuje się, że korzystałem ze starej wersji MSBuild - tej, która jest dostarczana z .NET Framework - z wiersza poleceń. Firma Microsoft udostępnia teraz MSBuild jako część samego programu Visual Studio, a także jako oddzielny instalator ( http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of- visual-studio.aspx ).

Rozwiązaniem było użycie nowej wersji MSBuild.exe znajdującej się w C:\Program Files (x86)\MSBuild\12.0\Bin. Kiedy to zrobiłem, wszystkie błędy celów zniknęły.

EDYCJA 1

Jak wspomniano w komentarzach, każda nowa wersja programu MSBuild zawiera nowy katalog. W przypadku programu Visual Studio 2015 użyj C:\Program Files (x86)\MSBuild\14.0\Bin.

EDYCJA 2

Jak wspomniano w komentarzach, w przypadku programu Visual Studio 2017 użyj C:\Program Files (x86)\Microsoft Visual Studio\2017\<Edition>\MSBuild\15.0\Bin\MSBuild.exe.

NathanAldenSr
źródło
1
Opublikowałem żądanie na forum TeamCity, aby uwzględnić nową ścieżkę (a la sposób obsługi ustawień NuGet). Miejmy nadzieję, że szybko się z tym uporają.
David Peden
1
Bezpośredni link w poście na blogu do oddzielnego pobierania narzędzi nie jest już ważny. Prawidłowy link to: microsoft.com/en-us/download/details.aspx?id=40760 .
David Peden
1
I tak po prostu Jetbrains przybywa na ratunek w wersji 8.0.5. Oficjalny post na blogu: teamcitydev.blogspot.com/2013/11/…
David Peden
1
Jeśli masz lokalne skrypty kompilacji Powershell, możesz po prostu dodać je do swojej ścieżki: $env:Path = $env:Path + ";C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications"i użyć v4 msbuild (możesz to zrobić również na swoim polu kompilacji)
Chris S
4
Tak! Dziękuję - to jest właściwe rozwiązanie.
Josh M.
52

Jeśli masz serwer kompilacji, na którym nie jest zainstalowany VS2012, możesz to naprawić za pomocą

a) zainstalowanie pakietu MSBuild.Microsoft.VisualStudio.Web.targets w swoim rozwiązaniu oraz

b) zastępując ten wiersz w pliku .csproj:

<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

Z tą linią wskazującą na pakiet nuget

<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="true" />

EDYTOWAĆ

Jak @joedragons podkreśla wersji uaktualnionej linii powinien odpowiadać Nuget wersję pakietu, czyli zastąpić targets.11.0.2.1z targets.x.x.x.xdo bieżącej wersji.

Daniel de Zwaan
źródło
1
Świetna rada!
Kevin Obee
2
Dzięki, świetne rozwiązanie
Pavel
1
Może to oczywiste, ale wiersz, którym zastępujesz, powinien zawierać wersję zainstalowanego pakietu. Ten, który zainstalowałem, to 12.0.4, więc kiedy wstawiłem import zastępczy, otrzymałem ten sam błąd. Kiedy przełączyłem się na ... Web.targets.12.0.4 \ ... wszystko dobrze =) Dziękuję bardzo!
joedragons
2
Nie potrzebujesz już części b tej odpowiedzi. Z jakiegoś powodu SO odrzucił moją zmianę, aby usunąć niepotrzebne szczegóły.
bbodenmiller
1
dzięki Zrobiłem to samo z ostatnią wersją MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3
Ahmed Samir
23

Proste rozwiązanie tego problemu:

Przejdź do następującej ścieżki:

C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio

Zobaczysz najnowszą wersję 10.0, 11.0, 12.0 w zależności od instalacji programu Visual Studio 2010, 2012 lub 2013.

Skopiuj WebApplicationsfolder z dowolnego katalogu najnowszej wersji i wklej do innego.

Twoje problemy powinny zostać rozwiązane.

samdubey
źródło
1
To IMO jest najlepszym i prostym rozwiązaniem :)
gideon
Oczywiście wymaga to rzeczywistego dostępu do tego na serwerze kompilacji.
Dave
1
... ale dlaczego musimy to robić ręcznie? Dzięki ... to naprawiło to dla mnie w VS21017 (dla mnie była to świeża instalacja tylko z VS2017 - teraz myślę, że to dlatego, że jeszcze nie zainstalowałem IIS)
Piotr Kula
Działa również podczas kopiowania do wersji 14.0.
Uwe Keim
12

Odkryłem, że zainstalowanie bezpłatnej powłoki programu Visual Studio 2012 (izolowana) powoduje zainstalowanie plików WebApplications v11 MSBuild. Lżejszy niż pełna instalacja programu Visual Studio 2012 i bez problemów licencyjnych.

Thomas F. Abraham
źródło
8

Łał. Właśnie widzieliśmy, że to samo dzieje się na naszej maszynie. Używamy VS2010 i docelowej platformy .NET 4.0. Nasze pliki projektu jawnie importują wersję 10.0 tych obiektów docelowych. Bez zmian w kodzie, wczoraj kompilacja była w porządku, a dziś kończy się niepowodzeniem z reklamacją dotyczącą brakującej wersji v11.0. NET Framework 4.5.1 został zainstalowany / zaktualizowany zeszłej nocy na tej maszynie jako automatyczna aktualizacja. Zamierzamy wymusić wersję 10.0 za pomocą parametru (lub zmiennej env.), Ale to z pewnością nas zaskoczyło ...

AKTUALIZACJA: Jeszcze bardziej dziwne jest to, że wydaje się, że dzisiejsza wersja msbuild wydaje się używać pierwszej linii pliku sln, aby określić, która VisualStudioVersion ma być domyślnie używana, podczas gdy wczorajsza wersja nie:

Format Version 12.00

Przetestowaliśmy ręcznie zmieniając to na 11.00 i kompilacja znów zaczęła działać.

W naszym przypadku, mimo że celujemy i budujemy wszystko na 2010 / 4.0, niektórzy deweloperzy przygotowywali się do VS2012 (ponieważ MS twierdził, że pliki projektu są kompatybilne), a to konkretne rozwiązanie zostało ostatnio zapisane (miesiące temu) w VS2012. Wcześniej nie stanowiło to problemu.

lesscode
źródło
1
Pomogło mi to znacznie bardziej niż najwyższa głosowana odpowiedź, która wydaje się dotyczyć zupełnie innej sytuacji.
LambdaCruiser
To samo tutaj @LambdaCruiser, ta odpowiedź bardzo pomogła. Spojrzałem na historię mojego pliku .sln i pomimo tego, że druga linia przeczytała # Visual Studio 2010pierwszą linię, na której Format Version 12.00na pewnym etapie zaktualizowałem do vs2012, ale przełączałem się tam iz powrotem na vs2010. Podobnie jak Wayne, ten problem wystąpił po uruchomieniu aktualizacji systemu Windows na serwerze CI
wal,
6

Miałem ten sam problem. Naprawiono, przechodząc przez powyższe rozwiązania. Ten problem jest spowodowany tym, że odpowiednia wersja narzędzi programu Visual Studio (BuildTools) nie jest dostępna na serwerze kompilacji. Jak słusznie wskazano powyżej, można to rozwiązać, instalując BuildTools, ale nie jest to opcja w moim przypadku.

Oto kolejna alternatywa - użyj Nuget

Install-Package MSBuild.Microsoft.VisualStudio.Web.targets -Version 14.0.0.3

Zidentyfikuj projekt startowy i zainstaluj plik web.targets na podstawie używanej wersji programu Visual Studio. Następujące pliki zostaną zmodyfikowane, co zawiera wymagane zmiany

W packages.config:

<package id="MSBuild.Microsoft.VisualStudio.Web.targets" version="14.0.0.3" targetFramework="net45" />

W .csproj:

<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props" Condition="Exists('..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props')" />

Mam nadzieję że to pomoże!!! Powodzenia,

Twoje zdrowie,

user2964808
źródło
1
Doskonała odpowiedź - eliminuje potrzebę małpowania z plikiem csproj lub kopiowania rzeczy na serwerze kompilacji. Pracowałem w wielu wersjach programu Visual Studio i MSBuild 2017. Jednak ręcznie usunąłem wiersz „WebApplication.targets” - nuget nie usunął go automatycznie.
Gedas Kutka,
3

Hack, ale rozwiązano to, kopiując: c: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications *. * Do c: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \Aplikacje internetowe*.*

Wolf5
źródło
1

Otrzymałem ten błąd pod koniec listopada bez wprowadzania żadnych zmian w konfiguracji mojej instalacji TeamCity lub instalacji MSBuild ani w kodzie źródłowym. Na moim serwerze kompilacji nie jest nawet zainstalowany program Visual Studio, a zmiana z VS2010 na VS2012 została dokonana pod koniec sierpnia bez żadnych problemów.

Moja wersja MSBuild to 4.0.30319.18408, mój serwer kompilacji to Windows Server 2008 R2 z dodatkiem SP1 z TeamCity v6.5.3.

Rozwiązałem problem, po prostu kopiując folder v11 z innego serwera kompilacji, na który nie miało to wpływu.

Domyślam się, że mogło się to zdarzyć na dwa sposoby:

  1. Zaktualizowano coś, co spowodowało usunięcie folderu v11. Czy to może być aktualizacja systemu Windows do .NET czy coś takiego?

  2. Coś zostało zaktualizowane, co zmieniło moją konfigurację TeamCity / MSBuild z używania wersji 10 na wersję 11, a kompilacje przestały działać, ponieważ wersja 11 nigdy nie istniała.

3 grudnia dostałem aktualizację do .NET Framework 4.5.1. Czy to może być powód?

Brgds

Jonas

Jonas
źródło
0

Niedawno utknąłem z tym samym problemem. I mój wniosek jest taki, że każda wersja VS (v10, v11, v12) zmienia ścieżkę zmiennej kompilacji, np MSBuildBinPath.

Zatem określenie dokładnej wersji VS nie jest hackem, ponieważ możesz nawet nie mieć zainstalowanej odpowiedniej wersji plików. Dlatego lepiej określ parametr i użyj celów, które istnieją na twoim komputerze.

W rzadkich przypadkach może być konieczne zainstalowanie określonej wersji programu VS i pakietu Web Deploy. W moim przypadku do rozwiązania problemu wystarczyła tylko wersja.

Johnny_D
źródło
0

Możesz dodać właściwość VisualStudioVersion w następujący sposób:

<ItemGroup>
  <ProjectToBuild Include="$(MSBuildProjectDirectory)\..\MySolution.sln">
    <Properties>Configuration=$(BuildConfiguration);WarningLevel=0;VisualStudioVersion=12.0</Properties>
  </ProjectToBuild>
</ItemGroup>
<MSBuild Projects="@(ProjectToBuild)" Targets="Rebuild"/>
user3586919
źródło
0

Ponieważ szukałem sposobu rozwiązania tego problemu, prawie każdy zalecał skopiowanie brakującego folderu MSBUILD lub zainstalowanie jakiegoś SDK jakiejś wersji.

Na szczęście znalazłem niesamowicie pomocny post Donovana Browna: http://donovanbrown.com/post/So-sick-of-MicrosoftWebApplicationtargets-was-not-found-build-errors!

W skrócie, chodzi o to, aby skonfigurować wersję VisualStudio, której kompilacja powinna używać w definicji kompilacji:

Kliknij prawym przyciskiem myszy -> „Edytuj definicję kompilacji ...”

Idź do „Procss” -> „3. Zaawansowane”

i ustaw „MSBuild Arguments” z

/p:VisualStudioVersion=12.0
A. Yosupov
źródło
Nie można znaleźć „Edytuj definicję kompilacji ...” w VS2019
Laser42