Nie znaleziono Microsoft.WebApplication.targets na serwerze kompilacji. Jakie jest twoje rozwiązanie

Próba zbudowania mojego projektu na serwerze kompilacji daje mi następujący błąd:

Microsoft (R) Build Engine Version 4.0.30319.1
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

Rozwiązałem ten problem kilka miesięcy temu, instalując Visual Studio 2010 na Build Server. Ale teraz konfiguruję nowy serwer od zera i chcę wiedzieć, czy jest jakieś lepsze rozwiązanie tego problemu.

Aby odpowiedzieć na tytuł pytania (ale nie na pytanie o wynik, który otrzymujesz):

Skopiowanie następującego folderu z komputera dewelopera na serwer kompilacji rozwiązuje ten problem, jeśli są to tylko aplikacje internetowe

C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications

Usuń x86 zgodnie z tym, jak psuje się twoja kompilacja. Jeśli masz inne typy projektów, prawdopodobnie będziesz musiał skopiować cały folder msbuild.

Budowanie i publikowanie WAP nie jest obsługiwane, jeśli VS nie jest zainstalowany. Powiedziawszy to, jeśli naprawdę nie chcesz instalować VS, musisz skopiować wszystkie pliki %ProgramFiles32%\MSBuild\Microsoft\.

Musisz także zainstalować narzędzie Web Deploy Tool . Myślę, że o to chodzi.

UPD: od VS2017 w Narzędziach do budowania występuje obciążenie, które całkowicie eliminuje ten problem. Zobacz odpowiedź @SOReader .

Jeśli nie chcesz niczego modyfikować na serwerze kompilacji i nadal chcesz, aby projekt budował się bezpośrednio poza kontrolą źródła, dobrym pomysłem może być poddanie wymaganych plików binarnych kontroli źródła. Musisz zmodyfikować sekcję importowania w pliku projektu, aby wyglądała następująco:

<Import Project="$(SolutionDir)\BuildTargets\WebApplications\Microsoft.WebApplication.targets" />
<Import Condition="false" Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

Pierwszy wiersz to rzeczywisty import z nowej lokalizacji, który jest względny do katalogu rozwiązania. Drugi to wyłączona wersja ( Condition="false") oryginalnej linii, która pozwala Visual Studio nadal uważać twój projekt za prawidłowy projekt aplikacji sieciowej (to jest sztuczka, którą robi sam VS 2010 SP1).

Nie zapomnij skopiować C:\Program Files (x86)\Microsoft\VisualStudio\v10.0\WebApplicationsdo BuildTargetsfolderu pod kontrolą źródła.

Obecnie, w 2017 r., Możesz zainstalować redisty aplikacji sieci Web za pomocą MSBuildTools. Wystarczy przejść do tej strony , która pobierze narzędzia MSBuild 2017, a podczas instalacji kliknij, Web development build toolsaby zainstalować również te cele:

Spowoduje to C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplicationsdomyślną instalację brakujących bibliotek

Możesz także użyć pakietu NuGet MSBuild.Microsoft.VisualStudio.Web.targets , odwołując się do nich w swoich projektach Visual Studio, a następnie zmieniać odniesienia, jak sugeruje Andriy K.

W oparciu o ten post tutaj możesz po prostu pobrać pakiet redystrybucyjny powłoki Microsoft Visual Studio 2010 Shell (zintegrowane), a elementy docelowe zostaną zainstalowane.

Pozwala to uniknąć konieczności instalowania programu Visual Studio na serwerze kompilacji.

Właśnie wypróbowałem to teraz i mogę sprawdzić, czy to działa:

Przed:

błąd MSB4019: Nie znaleziono importowanego projektu „C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications \ Microsoft.WebApplication.targets”. Sprawdź, czy ścieżka w deklaracji jest poprawna i czy plik istnieje na dysku.

Po instalacji:

[Buduje poprawnie]

Jest to oczywiście znacznie lepsze rozwiązanie niż instalowanie programu Visual Studio na serwerze kompilacji.

Najnowszy zestaw Windows SDK, jak wspomniano powyżej, oprócz „pakietu redystrybucyjnego powłoki Microsoft Visual Studio 2010 (zintegrowany)” dla Microsoft.WebApplication.targets i „Microsoft Visual Studio Team System 2008 Database Edition GDR R2” dla Microsoft.Data.Schema .SqlTasks.targets powinien zmniejszyć potrzebę instalacji programu Visual Studio 2010. Jednak instalacja VS 2010 może być w rzeczywistości mniej ogólna do pobrania, a na koniec mniej pracy.

Dodaj zależność za pomocą NuGet i ustaw parametr kompilacji

Cel: żadne zmiany / instalacje nie są konieczne w agentach kompilacji

Zastosowałem tu hybrydowe podejście do Lloyda , oparte na NuGet , oparte na rozwiązaniu zależności binarnych autorstwa Andrika.

Powód, dla którego chcę mieć możliwość dodawania nowych agentów kompilacji bez konieczności wstępnego konfigurowania ich za pomocą takich elementów.

1. Na komputerze z programem Visual Studio otwórz rozwiązanie; zignoruj ​​niepowodzenie projektu internetowego.
2. W menedżerze pakietów NuGet dodaj MSBuild.Microsoft.VisualStudio.Web.targets , jak wspomniał Lloyd.
3. To rozwiąże binaria do [solution]\packages\MSBuild.Microsoft.VisualStudio.Web.targets.nn.n.n.n\tools\VSToolsPath\
   1. Możesz skopiować je do folderu referencyjnego i zatwierdzić,
   2. Lub po prostu użyj ich tam, gdzie są. Wybrałem to, ale później będę musiał zająć się numerem wersji.

W wersji 7 wykonałem następujące czynności. To może nie być konieczne, a na podstawie komentarzy zdecydowanie nie jest teraz potrzebne. Zobacz komentarze poniżej.

1. Następnie w konfiguracji kompilacji TeamCity dodaj Paramenter kompilacji env.VSToolsPathi ustaw go w folderze VSToolsPath; użyłem..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath

Podczas budowania na serwerze kompilacji / CI wyłącz import Microsoft.WebApplication.targetscałkowicie, określając /p:VSToolsPath=''. Zasadniczo spowoduje to, że warunek następującej linii będzie fałszywy:

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

Oto jak to się robi w TeamCity:

Jeśli przeprowadzisz migrację programu Visual Studio 2012 do 2013, otwórz plik projektu * .csproj za pomocą programu edior.
i zaznacz element ToolsVersion znacznika „Project”.

Zmień wartość z 4,0 na 12,0

• Od

  <?xml version="1.0" encoding="utf-8"?>
  <Project ToolsVersion="4.0" ...

• Do

  <?xml version="1.0" encoding="utf-8"?>
  <Project ToolsVersion="12.0" ...

Lub Jeśli budujesz przy pomocy msbuild, po prostu określ właściwość VisualStudioVersion

msbuild /p:VisualStudioVersion=12.0

Źródło rozwiązania

Wygląda na to, że nowa wersja msbuild nie jest dostarczana z Microsoft.WebApplication.targets. Aby to naprawić, musisz zaktualizować plik csproj w następujący sposób:

1) Edytuj aplikację internetową csproj (prawy przycisk myszy). Znajdź sekcję csproj na dole dotyczącą narzędzi do budowania. Tak powinno tak wyglądać.

<PropertyGroup>  
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
</PropertyGroup>  
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />  
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />  
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />  

2) Musisz dodać jedną linię VSToolsPath poniżej znacznika VisualStudioVersion, aby tak wyglądało

<PropertyGroup>  
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  <!--Add the below line to fix the project loading in VS 2017 -->
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
  <!--End -->
</PropertyGroup>  
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />  
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />  
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />  

Link referencyjny: https://alastaircrabtree.com/cannot-open-vs-2015-web-project-in-vs-2017/

To wszystko czego potrzebujesz. Tylko 103 MB. Nie instaluj wszystkiego

Znalazłem to na MS connect :

Tak, musisz zainstalować program Visual Studio 2010 na komputerze kompilacji, aby budować projekty baz danych. Nie wymaga to dodatkowej licencji programu Visual Studio.

Jest to więc jedyna opcja, jaką mam na razie.

Moje rozwiązanie jest mieszanką kilku odpowiedzi tutaj.

Sprawdziłem serwer kompilacji, a Windows7 / NET4.0 SDK został już zainstalowany, więc znalazłem ścieżkę:

C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v9.0 \ WebApplications \ Microsoft.WebApplication.targets`

Jednak w tej linii:

<Import Project = "$ (MSBuildExtensionsPath) \ Microsoft \ VisualStudio \ v9.0 \ WebApplications \ Microsoft.WebApplication.targets" />

$ (MSBuildExtensionsPath) rozwija się do C: \ Program Files \ MSBuild który nie ma ścieżki.

Dlatego stworzyłem dowiązanie symboliczne za pomocą tego polecenia:

mklink / J „C: \ Program Files \ MSBuild \ Microsoft \ VisualStudio” „C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio”

W ten sposób $ (MSBuildExtensionsPath) rozwija się do prawidłowej ścieżki i żadne zmiany nie są potrzebne w samej aplikacji, tylko na serwerze kompilacji (być może można utworzyć dowiązanie symboliczne przy każdej kompilacji, aby upewnić się, że ten krok nie zostanie utracony i zostanie „udokumentowany” „).

Naprawiłem to, dodając
/p:VCTargetsPath="C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\V120"

do
Build > Build a Visual Studio project or solution using MSBuild > Command Line Arguments

Wypróbowałem wiele rozwiązań, ale ostatecznie ta odpowiedź zadziałała dla mnie: https://stackoverflow.com/a/19826448/431522

Zasadniczo wymaga wywołania MSBuild z katalogu MSBuild, zamiast z katalogu Visual Studio.

Dodałem również katalog MSBuild do mojej ścieżki, aby ułatwić pisanie skryptów.

Każdy, kto przyjdzie tutaj na Visual Studio 2017. Miałem podobny problem i nie mogłem skompilować projektu po aktualizacji do 15.6.1. Musiałem zainstalować narzędzia MSBulild, ale błąd nadal występował.

Byłem w stanie rozwiązać problem, kopiując v14.0folder z C:\Program Files (x86)\MSBuild\Microsoft\VisualStudiotego samego folderu, co v15.0rozwiązało wszystkie błędy. Więc teraz moja struktura folderów wygląda jak poniżej, gdzie oba foldery zawierają tę samą zawartość.

Jeśli używasz MSBuild, tak jak w przypadku serwera kompilacji, działało dla mnie:

Zmień następujące ustawienia:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

do:

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

Moje polecenie Msbuild to: *"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" solution.sln /p:Configuration=Debug /p:Platform="Any CPU"*

Mam nadzieję, że to komuś pomoże.

Jeśli próbujesz wdrożyć projekt za pomocą VSTS, problem może być związany z zaznaczeniem opcji „Hostowany kontener Windows” zamiast „Hostowany VS2017” (lub 18 itd.):

• Po instalacji narzędzi MSBuild firmy Microsoft zdefiniuj ścieżkę MSBuild w zmiennej środowiskowej, aby można ją było uruchomić z dowolnej ścieżki.
• Edytuj plik .csproj w dowolnym edytorze notatników, takim jak notepad ++, i komentuj
• Sprawdź następujące elementy, ->
  • Upewnij się, że używasz importu tylko raz, wybierz cokolwiek, co działa.
  • Upewnij się, że na dysku istnieje następujący folder „C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0” lub dowolna wersja, do której odwołuje się obiekt docelowy MSBuild w folderze „C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0 \ WebApplications \ Microsoft.WebApplication.targets "
  • W wierszu polecenia uruchom następujące polecenie, aby to sprawdzić

C:> msbuild "C: \\ DotnetCi.sln" / p: Configuration = Release / p: UseWPP_CopyWebApplication = true / p: PipelineDependsOnBuild = false

• wybierz odpowiednio przełącznik / p, patrz opis linku tutaj wprowadź opis obrazka tutaj

Miałem ten problem podczas tworzenia projektu SQL Server na potoku CI / CD. W rzeczywistości miałem go także lokalnie i nie udało mi się go rozwiązać.

Dla mnie zadziałało użycie zestawu MSBuild SDK , zdolnego do tworzenia pakietu aplikacji SQL Server Data-Tier Application ( .dacpac) z zestawu skryptów SQL, co oznacza tworzenie nowego projektu. Chciałem jednak zachować projekt SQL Server, aby móc połączyć go z bazą danych na żywo za pomocą Eksploratora obiektów SQL Server w programie Visual Studio. Podjąłem następujące kroki, aby to uruchomić:

1. Utrzymałem mój projekt SQL Server z .sql skryptów bazy danych.
2. Utworzono projekt biblioteki klas .NET Standard 2.0, upewniając się, że docelową strukturą jest .NET Standard 2.0, zgodnie z wytycznymi w powyższym łączu.

3. Ustaw zawartość w .csprojnastępujący sposób:

   <?xml version="1.0" encoding="utf-8"?>
   <Project Sdk="MSBuild.Sdk.SqlProj/1.0.0">
     <PropertyGroup>
       <SqlServerVersion>Sql140</SqlServerVersion>
       <TargetFramework>netstandard2.0</TargetFramework>
     </PropertyGroup>
   </Project>

4. Wybrałem Sql140 jako wersję programu SQL Server, ponieważ korzystam z programu SQL Server 2019. Sprawdź tę odpowiedź, aby znaleźć mapowanie do używanej wersji.

5. Zignoruj ​​projekt SQL Server podczas kompilacji, aby przestał się łamać lokalnie (buduje się w Visual Studio, ale nie działa na VS Code).

6. Teraz musimy tylko upewnić się, że .sqlpliki są w projekcie SDK po jego zbudowaniu. Osiągnąłem to za pomocą prostej procedury PowerShell na potoku CI / CD, która kopiowałaby pliki z projektu SQL Server do projektu SDK:

Copy-Item -Path "Path.To.The.Database.Project \ dbo \ Tables \ *" -Destination (New-item -Name "dbo \ Tables" -Type Directory -Path "Path.To.The.DatabaseSDK.Project \ ”)

PS: Pliki muszą znajdować się fizycznie w projekcie SDK, w katalogu głównym lub w folderze, więc łącza do .sdkplików w projekcie programu SQL Server nie będą działać. Teoretycznie powinno być możliwe skopiowanie tych plików z warunkiem przed kompilacją, ale z jakiegoś niejasnego powodu nie działało to dla mnie. Próbowałem także mieć .sqlpliki w projekcie SDK i połączyć je z projektem SQL Server, ale łatwo przerwałoby to łącze za pomocą Eksploratora obiektów SQL Server, więc postanowiłem to również usunąć.