v11.0 \ WebApplications \ Microsoft.WebApplication.targets wurde nicht gefunden, wenn die Datei tatsächlich auf v10 verweist


84

Zuerst einige Hintergrundinformationen. Ende 2012 haben wir unsere vs2008-Lösung auf vs2010 migriert, aber wir zielen weiterhin auf .NET 3.5. (Ich weiß nichts als das Neueste und Beste hier!)

Wir hatten bis vor einigen Wochen keine Probleme mit diesem Setup, als die Leute anfingen, diese Fehler zu bekommen:

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

Das Interessante ist, dass wenn Sie sich die Projektdatei ansehen, sie auf Version 10 verweist, was sinnvoll ist, da wir Visual Studio 2012 nicht verwenden.

Dieser Fehler traf mehrere von uns gleichzeitig und sogar ältere Codezweige, die sich seit Monaten nicht geändert haben.

Ich vermute, dass ein Update auf unsere Maschinen übertragen wurde, das die Dinge verwirrte, aber ich weiß nicht, was ich dagegen tun soll.

Die kurzfristige Lösung bestand darin, VS 2012 zu installieren und nicht zu verwenden, aber ich hoffe auf etwas Saubereres.


17
Ich habe festgestellt, dass das Hinzufügen von "/p:VisualStudioVersion=10.0" zur MSBuild-Befehlszeile dazu führt, dass dies verschwindet, aber es fühlt sich immer noch wie ein Hack an.
drs9222

Antworten:


116

Ich habe das gleiche Problem mit Visual Studio 2013 festgestellt. Es stellte sich heraus, dass ich die alte Version von MSBuild - die mit .NET Framework gelieferte - über die Befehlszeile verwendet habe. Microsoft veröffentlicht MSBuild jetzt als Teil von Visual Studio selbst und auch als separates Installationsprogramm ( http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of- visual-studio.aspx ).

Die Lösung bestand darin, die neue Version von MSBuild.exe in zu verwenden C:\Program Files (x86)\MSBuild\12.0\Bin. Sobald ich das getan habe, sind alle Zielfehler verschwunden.

BEARBEITEN 1

Wie in den Kommentaren erwähnt, bringt jede neue Version von MSBuild ein neues Verzeichnis mit. Verwenden Sie für Visual Studio 2015 C:\Program Files (x86)\MSBuild\14.0\Bin.

BEARBEITEN 2

Wie in den Kommentaren erwähnt, verwenden Sie für Visual Studio 2017 C:\Program Files (x86)\Microsoft Visual Studio\2017\<Edition>\MSBuild\15.0\Bin\MSBuild.exe.


1
Ich habe im TeamCity-Forum eine Anfrage gepostet, den neuen Pfad aufzunehmen (a la wie mit NuGet-Einstellungen umgegangen wird). Hoffentlich packen sie das schnell an.
David Peden

1
Der direkte Link im Blogbeitrag zum separaten Tool-Download ist nicht mehr gültig. Der richtige Link lautet: microsoft.com/en-us/download/details.aspx?id=40760 .
David Peden

1
Und genau so hilft Jetbrains mit Version 8.0.5. Offizieller Blog-Beitrag: teamcitydev.blogspot.com/2013/11/…
David Peden

1
Wenn Sie lokale Powershell-Build-Skripte haben, können Sie diese einfach zu Ihrem Pfad hinzufügen: $env:Path = $env:Path + ";C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications"und v4 msbuild verwenden (Sie können dies auch auf Ihrer Build-Box tun)
Chris S

4
Ja! Vielen Dank - das ist die richtige Lösung.
Josh M.

52

Wenn Sie einen Build-Server haben, auf dem VS2012 nicht installiert ist, können Sie dies durch beheben

a) Installieren des Pakets MSBuild.Microsoft.VisualStudio.Web.targets auf Ihrer Lösung und

b) Ersetzen dieser Zeile in der .csproj-Datei:

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

Diese Zeile zeigt auf das Nuget-Paket

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

BEARBEITEN

Als @joedragons weist auf die Version in der aktualisierten Zeile die nuget Paketversion übereinstimmen sollte, dh ersetzen targets.11.0.2.1mit targets.x.x.x.xder aktuellen Version.


1
Ebenso ein toller Rat!
Kevin Obee

2
Danke, tolle Lösung
Pavel

1
Möglicherweise offensichtlich, aber die Zeile, durch die Sie ersetzen, sollte die Version des von Ihnen installierten Pakets enthalten. Die von mir installierte Version war 12.0.4. Als ich den Ersatzimport einfügte, wurde der gleiche Fehler angezeigt. Als ich zu ... Web.targets.12.0.4 gewechselt bin \ ... alles gut =) Vielen Dank!
Joedragons

2
Sie brauchen Teil b dieser Antwort nicht mehr. Aus irgendeinem Grund hat SO meine Bearbeitung abgelehnt, um die unnötigen Details zu entfernen.
bbodenmiller

1
danke Ich habe das gleiche mit der letzten Version MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3
Ahmed Samir

23

Eine einfache Lösung für dieses Problem:

Gehen Sie zum folgenden Pfad:

C: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio

Abhängig von Ihrer Visual Studio 2010-, 2012- oder 2013-Installation wird die neueste Version V10.0, v11.0, v12.0 angezeigt.

Kopieren Sie den WebApplicationsOrdner aus einem der neuesten Versionsverzeichnisse und fügen Sie ihn in einen anderen ein.

Ihre Probleme sollten gelöst sein.


1
Diese IMO ist die beste und einfachste Lösung :)
Gideon

Natürlich müssen Sie tatsächlich Zugriff haben, um dies auf dem Build-Server zu tun.
Dave

1
... aber warum müssen wir das manuell machen? Danke .. das hat es für mich in VS21017 behoben (Für mich war es nur eine Neuinstallation mit VS2017 - Jetzt denke ich, weil ich IIS noch nicht installiert habe)
Piotr Kula

Funktioniert auch beim Kopieren nach V14.0.
Uwe Keim


8

Beeindruckend. Wir haben gerade das Gleiche auf unserer Baumaschine gesehen. Wir verwenden VS2010 und zielen auf .NET 4.0 ab. Unsere Projektdateien importieren explizit die Version 10.0 dieser Ziele. Ohne Änderungen am Code war der Build gestern in Ordnung und heute schlägt eine Beschwerde über eine fehlende Version 11.0 fehl. Das .NET Framework 4.5.1 wurde gestern Abend als automatisches Update auf diesem Build-Computer installiert / aktualisiert. Wir werden v10.0 mit dem Parameter (oder der env. Variablen) erzwingen, aber das hat uns sicherlich überrascht ...

UPDATE: Noch seltsamer ist, dass die heutige Version von msbuild anscheinend die erste Zeile der sln-Datei verwendet, um zu bestimmen, welche VisualStudioVersion standardmäßig verwendet werden soll, während die gestrige Version dies nicht tat:

Format Version 12.00

Wir haben getestet, wie man dies manuell auf 11.00 ändert, und der Build hat wieder funktioniert.

In unserem Fall haben sich einige Entwickler auf VS2012 vorbereitet (obwohl MS behauptet hat, dass die Projektdateien kompatibel sind), obwohl wir alles für 2010 / 4.0 anvisieren und erstellen, und diese spezielle Lösung wurde zuletzt (vor Monaten) in gespeichert VS2012. Bis heute war das kein Problem.


1
Dies hat mir viel mehr geholfen als die Antwort mit der höchsten Stimme, bei der es sich anscheinend um eine ganz andere Situation handelt.
LambdaCruiser

Gleich hier @LambdaCruiser hat diese Antwort sehr geholfen. Ich habe mir den Verlauf meiner .sln-Datei angesehen und obwohl in der zweiten Zeile # Visual Studio 2010die erste Zeile gelesen wurde , endete sie mit einem Format Version 12.00Upgrade auf vs2012, wechselte aber hin und her zu vs2010. Wie Wayne trat dieses Problem nach dem Windows - Update auf dem CI - Server läuft
wal

6

Ich hatte das gleiche Problem. Behoben durch Durchlaufen der oben aufgeführten Lösungen. Das Problem wird verursacht, weil auf dem Build-Server keine entsprechende Version von Visual Studio Tools (BuildTools) verfügbar ist. Wie oben zu Recht erwähnt, kann dies durch die Installation von BuildTools behoben werden, ist in meinem Fall jedoch nicht die Option.

Hier ist eine andere Alternative - verwenden Sie Nuget

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

Identifizieren Sie das Startprojekt und installieren Sie die web.targets basierend auf der verwendeten Version von Visual Studio. Die folgenden Dateien werden geändert, einschließlich der erforderlichen Änderungen

In packages.config:

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

In .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')" />

Hoffe das hilft!!! Viel Glück,

Prost,


1
Perfekte Antwort - Sie müssen nicht mehr mit einer csproj-Datei herumspielen oder Dinge auf dem Build-Server kopieren. Funktionierte in mehreren Versionen von Visual Studio und MSBuild 2017. Ich habe die Zeile "WebApplication.targets" jedoch manuell entfernt - Nuget hat sie nicht automatisch entfernt.
Gedas Kutka

3

Hack, aber gelöst durch Kopieren von: c: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications *. * Nach c: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \Web Applikationen*.*


1

Ich habe diesen Fehler Ende November erhalten, ohne Änderungen an der Konfiguration meiner TeamCity-Installation oder der MSBuild-Installation oder am Quellcode vorgenommen zu haben. Auf meinem Build-Server ist Visual Studio noch nicht einmal installiert, und der Wechsel von VS2010 zu VS2012 wurde Ende August ohne Probleme vorgenommen.

Meine MSBuild-Version ist 4.0.30319.18408, mein Build-Server ist ein Windows Server 2008 R2 SP1 mit TeamCity v6.5.3.

Ich habe das Problem gelöst, indem ich einfach den v11-Ordner von einem anderen Build-Server kopiert habe, der nicht betroffen war.

Ich vermute, dass dies auf zwei Arten hätte geschehen können:

  1. Es wurde etwas aktualisiert, das das Löschen des v11-Ordners auslöste. Könnte es ein Windows Update auf .NET sein oder so?

  2. Es wurde etwas aktualisiert, das meine TeamCity / MSBuild-Konfiguration von v10 auf v11 geändert hat, und die Builds funktionieren nicht mehr, da v11 nie existiert hat.

Ich habe am 3. Dezember ein Update auf .NET Framework 4.5.1. Könnte das der Grund sein?

Brgds

Jonas


0

Ich habe vor kurzem mit dem gleichen Problem stecken. Und meine Schlussfolgerung ist, dass jede Version von VS (v10, v11, v12) den Pfad der Build-Variablen ändert, wie z MSBuildBinPath.

Die Angabe der genauen Version von VS ist also kein Hack, da möglicherweise nicht einmal die entsprechende Version der Dateien installiert ist. Geben Sie daher besser einen Parameter an und verwenden Sie Ziele, die auf Ihrem Computer vorhanden sind.

In einigen seltenen Fällen müssen Sie möglicherweise eine bestimmte Version des VS- und Web Deploy-Pakets installieren. In meinem Fall war nur die Version genug, um das Problem zu lösen.


0

Sie können die VisualStudioVersion-Eigenschaft folgendermaßen hinzufügen:

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

0

Als ich nach einer Lösung suchte, empfahl fast jeder, entweder den fehlenden MSBUILD-Ordner zu kopieren oder ein SDK einer bestimmten Version zu installieren.

Zum Glück habe ich diesen unglaublich hilfreichen Beitrag von Donovan Brown gefunden: http://donovanbrown.com/post/So-sick-of-MicrosoftWebApplicationtargets-was-not-found-build-errors!

Kurz gesagt besteht die Idee darin, die VisualStudio-Version zu konfigurieren, die Ihr Build in Ihrer Build-Definition verwenden soll:

Rechtsklick -> "Build-Definition bearbeiten ..."

Gehen Sie zu "Procss" -> "3. Advanced"

und setzen Sie "MSBuild Arguments" mit

/p:VisualStudioVersion=12.0

"Build-Definition bearbeiten ..." kann in VS2019
Laser42
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.