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.
Odpowiedzi:
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
.źródło
$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)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.1
ztargets.x.x.x.x
do bieżącej wersji.źródło
Proste rozwiązanie tego problemu:
Przejdź do następującej ścieżki:
Zobaczysz najnowszą wersję 10.0, 11.0, 12.0 w zależności od instalacji programu Visual Studio 2010, 2012 lub 2013.
Skopiuj
WebApplications
folder z dowolnego katalogu najnowszej wersji i wklej do innego.Twoje problemy powinny zostać rozwiązane.
źródło
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.
źródło
Ł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.
źródło
# Visual Studio 2010
pierwszą linię, na którejFormat Version 12.00
na 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 CIMiał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,
źródło
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*.*
źródło
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:
Zaktualizowano coś, co spowodowało usunięcie folderu v11. Czy to może być aktualizacja systemu Windows do .NET czy coś takiego?
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
źródło
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.
źródło
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"/>
źródło
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
źródło