Externer VS2013-Buildfehler "Fehler MSB4019: Das importierte Projekt <Pfad> wurde nicht gefunden"

Ich erstelle ein Projekt über die Befehlszeile und nicht in Visual Studio 2013. Hinweis: Ich habe mein Projekt von Visual Studio 2012 auf 2013 aktualisiert. Das Projekt lässt sich problemlos in der IDE erstellen. Außerdem habe ich VS2012 zuerst vollständig deinstalliert, neu gestartet und VS2013 installiert. Die einzige Version von Visual Studio, die ich habe, ist 2013 Ultimate.

ValidateProjects:
    39>path_to_project.csproj(245,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 <Import> declaration is correct, and that the file exists on disk.
    39>Done Building Project "path_to_project.csproj" (Clean target(s)) -- FAILED.

Hier sind die beiden fraglichen Zeilen:

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

Die ursprüngliche zweite Zeile war v10.0, aber ich habe das manuell in v12.0 geändert.

$ (VSToolsPath) verlängert sich von dem, was ich sehe, zum Ordner v11.0 (VS2012), der offensichtlich nicht mehr vorhanden ist. Der Pfad sollte zu v12.0 gewesen sein.

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

Ich habe versucht, VSToolsPath in meiner Systemumgebungsvariablentabelle anzugeben, aber das externe Build-Dienstprogramm verwendet weiterhin Version 11.0. Ich habe versucht, die Registrierung zu durchsuchen, und dabei kam nichts heraus.

Leider sehe ich keine einfache Möglichkeit, die genaue Befehlszeile zu verwenden. Ich benutze ein Build-Tool.

Gedanken?

Ich hatte das gleiche Problem und fand eine einfachere Lösung

Es liegt daran, dass Vs2012 der csproj-Datei Folgendes hinzufügt:

<PropertyGroup>
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>

Sie können diesen Teil sicher entfernen und Ihre Lösung wird erstellt.

Wie Sielu betonte, müssen Sie sicherstellen, dass die .proj-Datei mit beginnt. <Project ToolsVersion="12"Andernfalls wird beim nächsten Öffnen des Projekts mit Visual Studio 2010 der entfernte Knoten erneut hinzugefügt.

Andernfalls funktioniert die oben genannte Lösung nicht, wenn Sie webdeploy oder einen Build-Server verwenden müssen. Sie können jedoch die VisualStudioVersionEigenschaft in Ihrem Build-Skript angeben :

msbuild myproject.csproj /p:VisualStudioVersion=12.0

oder bearbeiten Sie Ihre Build-Definition:

Ich hatte dies auch und Sie können es beheben, indem Sie die Tools-Version in Ihrer Build-Definition festlegen.

Dies ist sehr einfach zu tun. Öffnen Sie Ihre Build-Definition und gehen Sie zur Seite " Prozess ". Dann haben Sie unter der Gruppe " 3. Erweitert " eine Eigenschaft namens " MSBuild Arguments ". Platzieren Sie den Parameter dort mit der folgenden Syntax

/p:VisualStudioVersion=12.0 

Wenn Sie mehr Parameter haben, trennen Sie diese durch ein Leerzeichen und nicht durch ein Komma.

Dies hängt eng zusammen, kann jedoch das spezifische Problem des OP beheben oder nicht. In meinem Fall habe ich versucht, die Bereitstellung einer Azure-Site mithilfe von VS2013 zu automatisieren. Das Erstellen und Bereitstellen über VS-Werke mit MSBuild zeigte jedoch einen ähnlichen Fehler bei den "Zielen". Es stellt sich heraus, dass MSBuild unter VS2013 anders ist und jetzt Teil von VS und nicht des .Net Frameworks ist (siehe http://timrayburn.net/blog/visual-studio-2013-and-msbuild/ ). Verwenden Sie grundsätzlich die richtige Version von MSBuild:

ALT, VS2012

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe

NEU, VS2013

C:\Program Files (x86)\MSBuild\12.0\bin\msbuild.exe

Neuere, VS2015

C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe

Noch neuer, VS2017 (nicht vollständig getestet, aber entdeckt - sie haben die Dinge ein wenig verschoben)

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\msbuild.exe

Ich habe gerade eine Antwort von Kinook erhalten, der mir einen Link gegeben hat :

Grundsätzlich muss ich vor dem Bulding Folgendes anrufen. Ich denke, Visual Studio 2013 registriert die Umgebung nicht automatisch zuerst, aber 2012 hat es getan, oder ich habe es getan und vergessen.

call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86

Hoffentlich hilft dieser Beitrag jemand anderem.

Die Lösung von Giammin ist teilweise falsch. Sie sollten NICHT die gesamte PropertyGroup aus Ihrer Lösung entfernen. In diesem Fall funktioniert die MSBuild-Funktion "DeployTarget = Package" nicht mehr. Diese Funktion setzt voraus, dass "VSToolsPath" eingestellt ist.

<PropertyGroup>
  <!-- VisualStudioVersion is incompatible with later versions of Visual Studio.  Removing. -->
  <!-- <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> -->
  <!-- VSToolsPath is required by MSBuild for features like "DeployTarget=Package" -->
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
...
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

Ich hatte dieses Problem für unsere FSharp-Ziele (FSharpTargetsPath war leer).

Viele der Pfade werden mit Bezug auf die VS-Version erstellt.

Aus verschiedenen Gründen wird unser Build mit Systemberechtigungen ausgeführt, und die Umgebungsvariable "VisualStudioVersion" wurde (vom VS 2013-Installationsprogramm) nur auf der Ebene "Benutzer" festgelegt - was fair genug ist.

Stellen Sie sicher, dass die VisualStudioVersionUmgebungsvariable 12.0auf der Ebene (System oder Benutzer), auf der Sie ausgeführt werden, auf "" gesetzt ist.

Wenn Sie dies in der Befehlszeile ausführen, wird das Problem ebenfalls behoben. SETX VisualStudioVersion "12.0"

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

Das ist Wert 4.0
Sie schaffen es 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

Ich habe ein externes Build-Dienstprogramm verwendet. Denken Sie an etwas wie Ameisen, wenn ich das Produkt richtig verstehe, nur eine kommerzielle Version. Ich musste den Hersteller für die Antwort kontaktieren.

Wie sich herausstellt, enthält das Projekt ein globales Makro, DEVSTUDIO_NET_DIR. Ich musste dort den Pfad zu .Net ändern. Sie listen verschiedene Visual Studio-Versionen als "Actions" auf, die durch mich abgehen, aber alle Wege führen zurück zu dieser einen globalen Variablen hinter den Kulissen. Ich würde das als einen Defekt gegen das Produkt auflisten, wenn es nach mir ginge, es sei denn, ich vermisse etwas in meinem Verständnis. Durch Korrigieren des Pfads wurde das Build-Problem behoben.

Ich habe Visual Studio 2013 installiert. Das hat bei mir funktioniert:

<PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' != ''">12.0</VisualStudioVersion>`
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>

Also habe ich die Bedingung von ==bis !=und den Wert von 10.0bis geändert 12.0.

Ich hatte ein ähnliches Problem. Alle vorgeschlagenen Lösungen umgehen nur dieses Problem, lösen jedoch nicht die Fehlerquelle. Die @ giammin-Lösung sollte nicht angewendet werden, wenn Sie den tfs-Build-Server verwenden, da die Veröffentlichungsfunktion nur abgestürzt ist. @ cat5dev Lösung - Behebt das Problem, löst aber nicht die Quelle.

Ich bin mir fast sicher, dass Sie eine Build-Prozessvorlage für VS2012 verwenden, da ReleaseDefaultTemplate.11.1.xaml or DefaultTemplate.11.1.xaml diese Build-Vorlagen für VS2012 erstellt wurden und $ (VisualStudioVersion) auf 11.0 festgelegt ist

Sie sollten die ReleaseTfvcTemplate.12.xaml or TfvcTemplate.12.xaml Buildprozessvorlage für VS2013 verwenden, für die $ (VisualStudioVersion) auf 12.0 festgelegt ist

Dies funktioniert ohne Änderungen in der Projektdatei.

Ich hatte auch den gleichen Fehler. Ich habe dies getan, um ihn zu beheben

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

ändern

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

und es ist geschafft.

In meinem Fall kommentiere ich einfach unter der Zeile durch Öffnen der .csproj-Datei und habe den Trick gemacht

.<!-- <Import Project="..\PRPJECTNAME.targets" /> -->

Mein Problem mag anders sein, aber ich werde hierher gezogen, aber das kann jemandem helfen.

Ich habe ein einzelnes Webprojekt aus meiner Lösung ausgewählt und versucht, es als eigenständiges Projekt zu öffnen, bei dem ein Problem aufgetreten ist, nachdem ich in der Lage bin, das Problem zu lösen.

Verwenden Sie die richtige Version von MSBuild. Setzen Sie die Umgebungsvariable auf:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin

Dies funktioniert auch für VS 2019-Projekte

Zuvor haben wir es eingestellt C:\Windows\Microsoft.NET\Framework\v4.0.30319

In meinem Fall ist die Entwicklungsumgebung VS2013 und ich verwende TFS 2010. Build wurde für .NET 4.5.1 entwickelt. Ich habe die automatische Erstellung für CI eingerichtet. Wann immer ich oben erwähnte Problemumgehungen ausprobiert habe - wie das vollständige Entfernen der Eigenschaftsgruppe oder das Ersetzen einiger Zeilen usw. Mein Build wurde früher in TFS ausgeführt, aber meine Veröffentlichung in Azure schlug mit 'MSDeploy' oder manchmal mit einem anderen Fehler fehl. Beides konnte ich nicht gleichzeitig erreichen.

Schließlich musste ich das MSBuild-Argument übergeben, um das Problem zu beheben.

Gehen Sie zu Build-Definition bearbeiten> Prozess> 3. Erweitert> MSBuild-Argumente (auf gesetzt) ​​/p:VisualStudioVersion=12.0

Es hat bei mir funktioniert.

Sie sollten den Ordner WebApplications aus C: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio \ v12.0 \ nach C: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \ kopieren

du wirst finden

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

in der csproj-Datei, für die dieser Fehler auftritt. Entfernen Sie dies einfach aus csproj und erstellen Sie es dann.

Zur Lösung des Problems muss nur eines getan werden: Aktualisieren Sie TeamCity auf Version 8.1.x oder höher, da die Unterstützung für Visual Studio 2012/2013 und MSBuild Tools 2013 nur in TeamCity 8.1 eingeführt wurde. Sobald Sie Ihre TeamCity-Version aktualisiert haben, ändern Sie die Version der MSBuild Tools-Version in Ihrem Erstellungsschritt entsprechend, und das Problem verschwindet. Weitere Informationen finden Sie hier: http://blog.turlov.com/2014/07/upgrade-teamcity-to-enable-support-for.html

Ich - nichts hat geholfen, den v11.0-Wert der VisualStudioVersion-Variablen in v10.0 zu ändern. Das Ändern der Variablen in der .csproj-Datei hat dies nicht getan. Das Einstellen über die Eingabeaufforderung hat dies nicht getan. Etc...

Kopierte meinen lokalen Ordner dieser bestimmten Version (v11.0) auf meinen Build-Server.

Ich hatte alle oben genannten Lösungen ausprobiert und immer noch kein Glück. Ich hatte gehört, dass Leute Visual Studio auf ihren Build-Servern installiert hatten, um das Problem zu beheben, aber ich hatte nur 5 GB freien Speicherplatz, also habe ich C: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio einfach auf meinen Build-Server kopiert und es einen Tag lang aufgerufen . Begann danach mit Team City 9.x und Visual Studio 2013 zu arbeiten.

Basierend auf TFS 2015 Build Server

Wenn Sie diesem Fehler entgegenwirken ... Error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.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.

Öffnen Sie die .csprojDatei des in der Fehlermeldung genannten Projekts und kommentieren Sie den folgenden Abschnitt aus

<!-- <PropertyGroup> --> <!-- <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> --> <!-- <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath> --> <!-- </PropertyGroup> -->

Ich habe diesen Fehler erhalten, als ich einige VS-Komponenten installiert habe. Leider hat mir keine dieser Antworten geholfen. Ich verwende TFS für die Befehlsentwicklung und habe keine Berechtigung zum Bearbeiten der Build-Definition. Ich habe dieses Problem gelöst, indem ich Umgebungsvariablen gelöscht habe, die VS110COMNTOOLSund aufgerufen haben VS120COMNTOOLS. Ich denke, es wurde mit meinen VS-Komponenten installiert.

Ich habe festgestellt, dass der Ordner "WebApplications" auf meinem lokalen PC fehlt und nicht mit Visual Studio 2017 installiert wurde, wie es bei der Verwendung von 2012 der Fall war.

In meinem Fall habe ich die falsche Version von verwendet MSBuild.exe .

Welche Version Sie verwenden müssen, hängt davon ab, mit welcher Version von Visual Studio Sie Ihr Projekt erstellt haben. In meinem Fall brauchte ich 14.0 (nachdem ich Visual Studio 2015 verwendet hatte).

Dies wurde gefunden bei:

C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe

Sie können unter schauen:

C:\Program Files (x86)\MSBuild

Um andere Versionen zu finden.