Microsoft.WebApplication.targets wurde auf dem Buildserver nicht gefunden. Was ist Ihre Lösung?

Beim Versuch, mein Projekt auf dem Build-Server zu erstellen, wird der folgende Fehler angezeigt:

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.

Ich habe dieses Problem vor einigen Monaten mit der Installation von Visual Studio 2010 auf dem Build Server gelöst. Aber jetzt richte ich einen neuen Server von Grund auf neu ein und möchte wissen, ob es eine bessere Lösung gibt, um dieses Problem zu lösen.

So beantworten Sie den Titel der Frage (aber nicht die Frage nach der Ausgabe, die Sie erhalten):

Durch Kopieren des folgenden Ordners von Ihrem Entwicklungscomputer auf Ihren Build-Server wird dies behoben, wenn es sich nur um Webanwendungen handelt

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

Entfernen Sie x86 entsprechend der Unterbrechung Ihres Builds. Wenn Sie andere Projekttypen haben, müssen Sie wahrscheinlich den gesamten msbuild-Ordner kopieren.

Das Erstellen und Veröffentlichen von WAPs wird nicht unterstützt, wenn VS nicht installiert ist. Wenn Sie VS wirklich nicht installieren möchten, müssen Sie alle Dateien unter kopieren %ProgramFiles32%\MSBuild\Microsoft\.

Sie müssen auch das Web Deploy Tool installieren . Ich denke das ist es.

UPD: Ab VS2017 gibt es in Build Tools eine Arbeitslast, die dieses Problem vollständig beseitigt. Siehe @SOReader Antwort .

Wenn Sie es vorziehen, nichts auf dem Build-Server zu ändern, und das Projekt dennoch direkt aus der Quellcodeverwaltung heraus erstellt werden soll, ist es möglicherweise eine gute Idee, die erforderlichen Binärdateien unter die Quellcodeverwaltung zu stellen. Sie müssen den Importbereich in Ihrer Projektdatei so ändern, dass er folgendermaßen aussieht:

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

Die erste Zeile ist der tatsächliche Import vom neuen Speicherort relativ zum Lösungsverzeichnis. Die zweite ist eine deaktivierte Version ( Condition="false") der ursprünglichen Zeile, mit der Visual Studio Ihr Projekt weiterhin als gültiges Webanwendungsprojekt betrachten kann (dies ist der Trick, den VS 2010 SP1 selbst ausführt).

Vergessen Sie nicht , das zu kopieren , C:\Program Files (x86)\Microsoft\VisualStudio\v10.0\WebApplicationsum BuildTargetsOrdner unter Quellcodeverwaltung.

Derzeit können Sie 2017 WebApplication-Redists mit MSBuildTools installieren. Gehen Sie einfach auf diese Seite , auf der die MSBuild 2017-Tools heruntergeladen werden, und klicken Sie während der Installation Web development build tools, um auch diese Ziele zu installieren:

Dies führt dazu, dass C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplicationsstandardmäßig fehlende Bibliotheken installiert werden

Sie können auch das NuGet-Paket MSBuild.Microsoft.VisualStudio.Web.targets verwenden , auf diese in Ihren Visual Studio-Projekten verweisen und dann Ihre Referenzen ändern, wie von Andriy K vorgeschlagen.

Basierend auf diesem Beitrag hier können Sie einfach das Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package herunterladen und die Ziele werden installiert.

Dadurch muss Visual Studio nicht auf dem Build-Server installiert werden.

Ich habe dies gerade ausprobiert und kann überprüfen, ob es funktioniert:

Vor:

Fehler MSB4019: Das importierte Projekt "C: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications \ Microsoft.WebApplication.targets" wurde nicht gefunden. Stellen Sie sicher, dass der Pfad in der Deklaration korrekt ist und die Datei auf der Festplatte vorhanden ist.

Nach der Installation:

[Baut richtig]

Dies ist natürlich eine weitaus bessere Lösung als die Installation von Visual Studio auf einem Build-Server.

Das neueste Windows SDK, wie oben erwähnt, zusätzlich zum "Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package" für Microsoft.WebApplication.targets und "Microsoft Visual Studio Team System 2008 Datenbank Edition GDR R2" für Microsoft.Data.Schema .SqlTasks.targets sollten die Notwendigkeit der Installation von Visual Studio 2010 verringern. Die Installation von VS 2010 ist jedoch möglicherweise insgesamt weniger herunterladbar und am Ende weniger arbeitsintensiv.

Fügen Sie Abhängigkeiten über NuGet hinzu und legen Sie einen Build-Parameter fest

Ziel: Keine Änderungen / Installationen an den Build-Agenten erforderlich

Ich habe hier einen hybriden Ansatz für den NuGet-Ansatz von Lloyd gewählt , der auf der von Andrik festgelegten Lösung für binäre Abhängigkeiten basiert.

Der Grund dafür ist, dass ich neue Build-Agenten hinzufügen möchte, ohne sie mit solchen Elementen vorkonfigurieren zu müssen.

1. Öffnen Sie auf einem Computer mit Visual Studio die Lösung. Ignorieren Sie, dass das Webprojekt fehlschlägt.
2. Fügen Sie im NuGet-Paketmanager MSBuild.Microsoft.VisualStudio.Web.targets hinzu , wie Lloyd erwähnt hat.
3. Dadurch werden die Binärdateien in aufgelöst [solution]\packages\MSBuild.Microsoft.VisualStudio.Web.targets.nn.n.n.n\tools\VSToolsPath\
   1. Sie können diese in einen Referenzordner kopieren und festschreiben.
   2. Oder verwenden Sie sie einfach dort, wo sie sich befinden. Ich habe dies gewählt, muss mich aber später mit der Versionsnummer im Pfad befassen.

In Version 7 habe ich Folgendes getan. Dies war möglicherweise nicht erforderlich und wird aufgrund der Kommentare jetzt definitiv nicht benötigt. Bitte beachten Sie die Kommentare unten.

1. Fügen Sie als Nächstes in Ihrer TeamCity-Buildkonfiguration einen Buildparameter für hinzu env.VSToolsPathund legen Sie ihn im Ordner VSToolsPath fest. ich benutzte..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath

Deaktivieren Sie beim Erstellen auf dem Build / CI-Server den Import von Microsoft.WebApplication.targetsinsgesamt durch Angabe /p:VSToolsPath=''. Dies macht im Wesentlichen die Bedingung der folgenden Zeile falsch:

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

So geht's in TeamCity:

Wenn Sie Visual Studio 2012 nach 2013 migrieren, öffnen Sie die Projektdatei * .csproj mit edior.
und überprüfen Sie das ToolsVersion-Element des 'Project'-Tags.

Ändern Sie den Wert von 4.0 auf 12.0

• Von

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

• Zu

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

Oder Wenn Sie mit msbuild erstellen, geben Sie einfach die VisualStudioVersion-Eigenschaft an

msbuild /p:VisualStudioVersion=12.0

Lösungsquelle

Es scheint, dass die neue Version von msbuild nicht mit Microsoft.WebApplication.targets geliefert wird. Um dies zu beheben, müssen Sie Ihre csproj-Datei folgendermaßen aktualisieren:

1) Bearbeiten Sie die Web-App csproj (Rechtsklick). Suchen Sie den Abschnitt im csproj unten bezüglich der Build-Tools. Es sollte so aussehen.

<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) Sie müssen eine VSToolsPath-Zeile unter dem VisualStudioVersion-Tag hinzufügen, damit es so aussieht

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

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

Das ist alles was Sie brauchen. Nur 103 MB. Installieren Sie nicht alles

Ich habe dies auf MS Connect gefunden :

Ja, Sie müssen Visual Studio 2010 auf Ihrem Buildcomputer installieren, um Datenbankprojekte erstellen zu können. Hierfür ist keine zusätzliche Lizenz von Visual Studio erforderlich.

Dies ist also die einzige Option, die ich derzeit habe.

Meine Lösung ist eine Mischung aus mehreren Antworten hier.

Ich habe den Build-Server überprüft und Windows7 / NET4.0 SDK wurde bereits installiert, sodass ich den Pfad gefunden habe:

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

In dieser Zeile jedoch:

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

$ (MSBuildExtensionsPath) wird zu C: \ Programme \ MSBuild erweitert, das den Pfad nicht hat.

Daher habe ich mit diesem Befehl einen Symlink erstellt:

mklink / J "C: \ Programme \ MSBuild \ Microsoft \ VisualStudio" "C: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio"

Auf diese Weise wird $ (MSBuildExtensionsPath) zu einem gültigen Pfad erweitert, und es sind keine Änderungen in der App selbst erforderlich, nur auf dem Build-Server (möglicherweise kann bei jedem Build der Symlink erstellt werden, um sicherzustellen, dass dieser Schritt nicht verloren geht und "dokumentiert" wird ").

Ich reparierte dies , indem
/p:VCTargetsPath="C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\V120"

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

Ich habe eine Reihe von Lösungen ausprobiert, aber am Ende hat diese Antwort für mich funktioniert: https://stackoverflow.com/a/19826448/431522

Grundsätzlich wird MSBuild aus dem MSBuild-Verzeichnis anstelle des Visual Studio-Verzeichnisses aufgerufen.

Ich habe auch das MSBuild-Verzeichnis zu meinem Pfad hinzugefügt, um das Codieren der Skripte zu vereinfachen.

Jeder, der für Visual Studio 2017 hierher kommt. Ich hatte ein ähnliches Problem und konnte das Projekt nach dem Update auf 15.6.1 nicht kompilieren. Ich musste MSBulild-Tools installieren, aber der Fehler war immer noch da.

Ich konnte das Problem beheben, indem ich den v14.0Ordner aus C:\Program Files (x86)\MSBuild\Microsoft\VisualStudiodemselben Ordner wie kopierte v15.0, wodurch alle Fehler behoben wurden. Jetzt sieht meine Ordnerstruktur wie folgt aus, wobei beide Ordner den gleichen Inhalt enthalten.

Wenn Sie MSBuild verwenden, wie im Fall eines Build-Servers, hat Folgendes funktioniert:

Ändern Sie Folgendes:

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

zu:

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

Mein Msbuild-Befehl lautet: *"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" solution.sln /p:Configuration=Debug /p:Platform="Any CPU"*

Hoffe das hilft jemandem.

Wenn Sie versuchen, ein Projekt mit VSTS bereitzustellen, hängt das Problem möglicherweise mit der Option "Gehosteter Windows-Container" anstelle von "Gehosteter VS2017" (oder 18 usw.) zusammen:

• Definieren Sie nach der Installation der MSBuild-Tools von Microsoft den MSBuild-Pfad in der Umgebungsvariablen, damit er von jedem Pfad aus ausgeführt werden kann.
• Bearbeiten Sie die .csproj-Datei in einem beliebigen Editor, z. B. Notepad ++, und kommentieren Sie die
• Überprüfen Sie die folgenden Elemente: ->
  • Stellen Sie sicher, dass Sie den Import nur einmal verwenden, und wählen Sie aus, was funktioniert.
  • Stellen Sie sicher, dass auf dem Laufwerk der folgende Ordner vorhanden ist: "C: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0" oder welche Version auch immer vom MSBuild-Ziel unter "C: \ Programme (x86)" referenziert wird. \ MSBuild \ Microsoft \ VisualStudio \ v14.0 \ WebApplications \ Microsoft.WebApplication.targets "
  • Führen Sie an der Eingabeaufforderung den folgenden Befehl aus, um dies zu überprüfen

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

• Wählen Sie gegebenenfalls den Schalter / p. Siehe Linkbeschreibung hier eingeben. Bildbeschreibung hier eingeben

Ich hatte dieses Problem beim Erstellen eines SQL Server-Projekts auf einer CI / CD-Pipeline. Tatsächlich hatte ich es auch vor Ort und konnte es nicht lösen.

Für mich funktionierte die Verwendung eines MSBuild SDK , mit dem .dacpacaus einer Reihe von SQL-Skripten ein SQL Server Data-Tier-Anwendungspaket ( ) erstellt werden kann, das das Erstellen eines neuen Projekts impliziert. Ich wollte das SQL Server-Projekt jedoch beibehalten, damit ich es über den SQL Server-Objekt-Explorer in Visual Studio mit der Live-Datenbank verknüpfen kann. Ich habe die folgenden Schritte unternommen, um dies zum Laufen zu bringen:

1. Hielt mein SQL Server-Projekt mit den .sqlDatenbankskripten.
2. Erstellt ein .NET Standard 2.0-Klassenbibliotheksprojekt und stellt sicher, dass das Zielframework .NET Standard 2.0 gemäß den Richtlinien im obigen Link ist.

3. Stellen Sie den Inhalt .csprojwie folgt ein:

   <?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. Ich habe Sql140 als SQL Server-Version ausgewählt, da ich SQL Server 2019 verwende. Überprüfen Sie diese Antwort , um die Zuordnung zu der von Ihnen verwendeten Version zu ermitteln.

5. Ignorieren Sie das SQL Server-Projekt beim Erstellen, damit es nicht mehr lokal unterbrochen wird (es wird zwar in Visual Studio erstellt, schlägt jedoch in VS Code fehl).

6. Jetzt müssen wir nur noch sicherstellen, dass sich die .sqlDateien im SDK-Projekt befinden, wenn es erstellt wird. Dies habe ich mit einer einfachen Powershell-Routine in der CI / CD-Pipeline erreicht, die die Dateien aus dem SQL Server-Projekt in das SDK-Projekt kopiert:

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: Die Dateien müssen sich physisch im SDK-Projekt befinden, entweder im Stammverzeichnis oder in einem Ordner, damit Links zu den .sdkDateien im SQL Server-Projekt nicht funktionieren. Theoretisch sollte es möglich sein, diese Dateien mit einer vorgefertigten Bedingung zu kopieren, aber aus irgendeinem unbekannten Grund funktionierte dies bei mir nicht. Ich habe auch versucht, die .sqlDateien im SDK-Projekt zu haben und sie mit dem SQL Server-Projekt zu verknüpfen, aber das würde die Verknüpfung mit dem SQL Server-Objekt-Explorer leicht unterbrechen, daher habe ich beschlossen, dies ebenfalls zu löschen.