Erreur de génération VS2013 externe «erreur MSB4019: le projet importé <chemin> est introuvable»

Je crée un projet via la ligne de commande et non dans Visual Studio 2013. Remarque, j'avais mis à niveau mon projet de Visual Studio 2012 vers 2013. Le projet se construit correctement à l'intérieur de l'EDI. En outre, j'ai d'abord complètement désinstallé VS2012, redémarré et installé VS2013. La seule version de Visual Studio que j'ai est 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.

Voici les deux lignes en question:

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

La deuxième ligne d'origine était la v10.0, mais je l'ai modifiée manuellement en v12.0.

$ (VSToolsPath) s'allonge de ce que je vois dans le dossier v11.0 (VS2012), qui n'est évidemment plus là. Le chemin aurait dû être vers la version 12.0.

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

J'ai essayé de spécifier VSToolsPath dans ma table de variables d'environnement système, mais l'utilitaire de génération externe utilise toujours la version 11.0. J'ai essayé de chercher dans le registre et cela n'a rien donné.

Malheureusement, je ne vois aucun moyen facile d'obtenir la ligne de commande exacte utilisée. J'utilise un outil de construction.

Pensées?

J'ai eu le même problème et j'ai trouvé une solution plus simple

Cela est dû à Vs2012 ajoutant ce qui suit au fichier csproj:

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

Vous pouvez supprimer cette partie en toute sécurité et votre solution se développera.

Comme Sielu l'a souligné, vous devez vous assurer que le fichier .proj commence par <Project ToolsVersion="12"sinon la prochaine fois que vous ouvrirez le projet avec visual studio 2010, il ajoutera à nouveau le nœud supprimé.

Sinon, si vous devez utiliser webdeploy ou vous utilisez un serveur de build, la solution ci-dessus ne fonctionnera pas mais vous pouvez spécifier la VisualStudioVersionpropriété dans votre script de build:

msbuild myproject.csproj /p:VisualStudioVersion=12.0

ou modifiez votre définition de build:

Je l'avais aussi et vous pouvez le corriger en définissant la version des outils dans votre définition de build.

C'est très simple à faire. Ouvrez votre définition de build et accédez à la page " Processus ". Ensuite, sous le groupe « 3. Avancé », vous avez une propriété appelée « Arguments MSBuild ». Placez-y le paramètre avec la syntaxe suivante

/p:VisualStudioVersion=12.0 

Si vous avez plus de paramètres, séparez-les par un espace et non par une virgule.

Ceci est étroitement lié mais peut ou peut ne pas résoudre le problème spécifique des PO. Dans mon cas, j'essayais d'automatiser le déploiement d'un site Azure à l'aide de VS2013. La construction et le déploiement via VS fonctionne, cependant, en utilisant MSBuild a montré une erreur similaire autour des "cibles". Il s'avère que MSBuild est différent sous VS2013 et fait maintenant partie de VS et non du .Net Framework (voir http://timrayburn.net/blog/visual-studio-2013-and-msbuild/ ). Fondamentalement, utilisez la version correcte de MSBuild:

OLD, VS2012

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

NOUVEAU, VS2013

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

Plus récent, VS2015

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

Plus récent encore, VS2017 (pas entièrement testé mais découvert - ils ont un peu bougé les choses)

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

Je viens de recevoir une réponse de Kinook, qui m'a donné un lien :

Fondamentalement, je dois appeler ce qui suit avant de procéder au bulding. Je suppose que Visual Studio 2013 n'enregistre pas automatiquement l'environnement en premier, mais 2012 l'a fait, ou je l'ai fait et j'ai oublié.

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

Espérons que ce message aide quelqu'un d'autre.

La solution de giammin est partiellement incorrecte. Vous NE DEVEZ PAS supprimer l'intégralité de ce PropertyGroup de votre solution. Si vous le faites, la fonctionnalité "DeployTarget = Package" de MSBuild cessera de fonctionner. Cette fonctionnalité repose sur la définition de "VSToolsPath" .

<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)' != ''" />

J'ai eu ce problème pour nos cibles FSharp (FSharpTargetsPath était vide).

De nombreux chemins sont construits en référence à la version VS.

Pour diverses raisons, notre build s'exécute avec des privilèges système, et la variable d'environnement "VisualStudioVersion" n'a été définie (par le programme d'installation de VS 2013) qu'au niveau "utilisateur" - ce qui est assez juste.

Assurez-vous que la VisualStudioVersionvariable d'environnement " " est définie sur " 12.0" au niveau (système ou utilisateur) sur lequel vous exécutez.

L'exécution de cela dans la ligne de commande résoudra également le problème. SETX VisualStudioVersion "12.0"

Si vous migrez Visual Studio 2012 vers 2013, ouvrez le fichier de projet * .csprorj avec edior.
et vérifiez l'élément ToolsVersion de la balise «Project».

C'est la valeur 4,0
Vous atteignez 12,0

• De

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

• À

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

Ou si vous construisez avec msbuild, spécifiez simplement la propriété VisualStudioVersion

msbuild /p:VisualStudioVersion=12.0

J'utilisais un utilitaire de construction externe. Pensez à quelque chose comme les fourmis, si je comprends bien le produit, juste une version commerciale. J'ai dû contacter le fabricant pour la réponse.

Il s'avère que le projet contient une macro globale, DEVSTUDIO_NET_DIR. J'ai dû changer le chemin vers .Net là-bas. Ils répertorient différentes versions de Visual Studio comme "Actions", ce qui me fait perdre de vue, mais toutes les routes mènent à cette seule variable globale en coulisses. Je dirais que c'est un défaut contre le produit, si je le pouvais, à moins que je manque quelque chose dans ma compréhension. La correction du chemin a résolu le problème de construction.

J'ai installé Visual Studio 2013. Cela a fonctionné pour moi:

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

J'ai donc changé la condition de ==en !=et la valeur de 10.0en 12.0.

J'ai eu un problème similaire. Toutes les solutions proposées sont juste contourner ce problème mais ne résolvent pas la source d'erreur. La solution @giammin ne doit pas être appliquée si vous utilisez le serveur de construction tfs car il s'agit simplement d'une fonctionnalité de publication bloquée. @ cat5dev solution - résout le problème mais n'en résout pas la source.

Je suis presque sûr que vous utilisez un modèle de processus de construction pour VS2012 comme ReleaseDefaultTemplate.11.1.xaml or DefaultTemplate.11.1.xaml ces modèles de construction ont été créés pour VS2012 et $ (VisualStudioVersion) défini sur 11.0

Vous devez utiliser le modèle de processus de construction pour VS2013 ReleaseTfvcTemplate.12.xaml or TfvcTemplate.12.xaml qui a $ (VisualStudioVersion) défini sur 12.0

Cela fonctionne sans aucune modification dans le fichier de projet.

J'ai aussi eu la même erreur .. je l'ai fait pour le réparer

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

changer pour

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

et c'est fait.

Dans mon cas, je commente juste en dessous de la ligne en ouvrant le fichier .csproj et j'ai fait l'affaire

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

Mon problème peut être différent mais je suis traîné ici, mais cela peut aider quelqu'un.

J'ai choisi un seul projet Web dans ma solution et j'essaie de l'ouvrir en tant que projet autonome qui posait problème, après que je puisse résoudre le problème ci-dessus.

Utilisez la version correcte de MSBuild. Définissez la variable d'environnement sur:

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

Cela fonctionnera également pour les projets VS 2019

Auparavant, nous le réglions sur C:\Windows\Microsoft.NET\Framework\v4.0.30319

Dans mon cas, l'environnement de développement est VS2013 et j'utilise TFS 2010. La build a été ciblée pour .NET 4.5.1. Je configurais la construction automatique pour CI. à chaque fois que j'essayais les solutions de contournement mentionnées ci-dessus - comme la suppression complète du groupe de propriétés ou le remplacement de certaines lignes, etc. Je n'ai pas pu réaliser les deux simultanément.

J'ai finalement dû passer l'argument MSBuild pour résoudre le problème.

Aller à Modifier la définition de build> Processus> 3. Avancé> Arguments MSBuild (défini sur) /p:VisualStudioVersion=12.0

Ça a marché pour moi.

Vous devez copier le dossier WebApplications de C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v12.0 \ vers C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \

tu trouveras

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

dans le fichier csproj pour lequel cette erreur apparaît. Il suffit de supprimer cela de csproj et de le compiler.

Une seule chose doit être effectuée pour résoudre le problème: mettre à niveau TeamCity vers la version 8.1.x ou supérieure, car la prise en charge de Visual Studio 2012/2013 et MSBuild Tools 2013 n'a été introduite que dans TeamCity 8.1. Une fois que vous avez mis à niveau votre TeamCity, modifiez le paramètre de version de MSBuild Tools dans votre étape de génération en conséquence et le problème disparaîtra. Pour plus d'informations, lisez ici: http://blog.turlov.com/2014/07/upgrade-teamcity-to-enable-support-for.html

Moi - rien n'a aidé à changer la valeur v11.0 de la variable VisualStudioVersion en v10.0. La modification de la variable dans le fichier .csproj n'a pas fonctionné. Le définir via l'invite de commande ne l'a pas fait. Etc...

J'ai fini par copier mon dossier local de cette version spécifique (v11.0) sur mon serveur de build.

J'avais essayé toutes les solutions ci-dessus et toujours pas de chance. J'avais entendu des gens installer Visual Studio sur leurs serveurs de build pour le réparer, mais je n'avais que 5 Go d'espace libre, alors je viens de copier C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio sur mon serveur de build et je l'ai appelé un jour . Après cela, j'ai commencé à travailler avec Team City 9.x et Visual Studio 2013.

Basé sur TFS 2015 Build Server

Si vous contrecarrez cette erreur ... 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.

Ouvrez le .csprojfichier du projet nommé dans le message d'erreur et commentez la section ci-dessous

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

J'ai eu cette erreur lors de l'installation de certains composants VS. Malheureusement, aucune de ces réponses ne m'a aidé. J'utilise TFS pour le développement de commandes et je n'ai aucune autorisation pour modifier la définition de build. J'ai résolu ce problème en supprimant les variables d'environnement appelées VS110COMNTOOLSet VS120COMNTOOLS. Je pense qu'il a été installé avec mes composants VS.

J'ai constaté que je manquais le dossier WebApplications sur mon PC local, je ne l'ai pas installé avec Visual Studio 2017 comme il le faisait lorsque j'utilisais 2012.

Dans mon cas, j'utilisais la mauvaise version de MSBuild.exe .

La version que vous devez utiliser dépend de la version de Visual Studio que vous avez utilisée pour créer votre projet. Dans mon cas, j'avais besoin de 14,0 (après avoir utilisé Visual Studio 2015).

Cela a été trouvé à:

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

Vous pouvez regarder sous:

C:\Program Files (x86)\MSBuild

Pour trouver d'autres versions.