Erreur de génération VS2013 externe "erreur MSB4019: le projet importé <chemin> n'a pas été trouvé"
Je construis un projet à l'aide de la ligne de commande et non de Visual Studio 2013. Remarque: j'ai mis à niveau mon projet de Visual Studio 2012 à 2013. Le projet est parfaitement intégré à l'EDI. De plus, j'ai tout d'abord désinstallé complètement VS2012, puis redémarré et installé VS2013. La seule version de Visual Studio que j'ai est la version 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 v10.0, mais j'ai manuellement changé cela pour 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 à v12.0.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\
J'ai essayé de spécifier VSToolsPath dans la table de variables de mon 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 donné rien.
Malheureusement, je ne vois pas de 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 trouver une solution plus facile
C'est dû à Vs2012 qui a ajouté cette partie dans le 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 a souligné Siel 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, le noeud supprimé sera à nouveau ajouté.
sinon, si vous devez utiliser webdeploy ou un serveur de génération, la solution ci-dessus ne fonctionnera pas, mais vous pouvez spécifier la propriété VisualStudioVersion dans votre script de génération:
msbuild myproject.csproj /p:VisualStudioVersion=12.0
ou éditez votre définition de build:
J'avais aussi cela et vous pouvez le réparer en définissant la version des outils dans votre définition de construction.
C'est très facile à faire. Ouvrez votre définition de construction et accédez à la page "Process)". Ensuite, sous le groupe ". Avancé", vous avez une propriété appelée "Arguments MSBuild". Placez le paramètre ici 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 non résoudre un problème spécifique des PO. Dans mon cas, j'essayais d'automatiser le déploiement d'un site Azure à l'aide de VS2013. Construire et déployer via VS, cependant, utiliser 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 complètement testé mais découvert - ils ont déplacé les choses un peu)
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 :
En gros, je dois appeler le suivant avant de construire. J'imagine que Visual Studio 2013 n'enregistre pas automatiquement l'environnement en premier, mais 2012 l'a fait ou j'ai oublié de le faire.
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
Espérons que ce post aide quelqu'un d'autre.
solution de giammin est partiellement incorrect. Vous NE DEVRIEZ PAS supprimer l'ensemble de PropertyGroup de votre solution. Si vous le faites, la fonctionnalité "DeployTarget = Package" de MSBuild cessera de fonctionner. Cette fonctionnalité repose sur "VSToolsPath" en cours de configuration.
<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).
La plupart des chemins sont construits en référence à la version du VS.
Pour diverses raisons, notre version fonctionne 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 correct.
Assurez-vous que la variable d'environnement "VisualStudioVersion" est définie sur "12.0" au niveau (système ou utilisateur) que vous exécutez.
L'exécuter 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 le faites à 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'ai Visual Studio 2013 installé. 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.0 en 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. Je devais contacter le fabricant pour la réponse.
Il se trouve qu'il existe une macro globale dans le projet, DEVSTUDIO_NET_DIR. Je devais changer le chemin vers .Net là. Ils répertorient différentes versions de Visual Studio sous la forme "Actions", ce qui me permet de revenir, mais tous les chemins mènent à cette variable globale en coulisse. Je l’énumérerais comme un défaut du produit, si j’avais le choix, à moins que quelque chose ne me manque dans ma compréhension. Corriger le chemin a corrigé le problème de construction.
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 à
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
et c'est fait.
J'ai eu le même problème. Toutes les solutions proposées ne font que contourner le 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 compilation tfs car il s'agit simplement d'une fonctionnalité de publication endommagée. @ Cat5dev solution - résout le problème mais ne 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 génération pour VS201ReleaseTfvcTemplate.12.xaml or TfvcTemplate.12.xaml dont le paramètre $ (VisualStudioVersion) est défini sur 12.0
Cela fonctionne sans aucune modification dans le fichier de projet.
Dans mon cas, je viens de commenter la ligne ci-dessous en ouvrant le fichier .csproj et j'ai fait le tour
.<!-- <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 quoi je suis capable de le résoudre.
Vous devez copier le dossier WebApplications de C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\dans C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0 \
Dans mon cas, l'environnement de développement est VS2013 et j'utilise TFS 2010. La génération a été ciblée pour .NET 4.5.1. Je préparais la construction automatique pour CI. chaque fois que j'essayais les solutions de contournement mentionnées ci-dessus - comme supprimer complètement le groupe de propriétés ou remplacer certaines lignes etc. Je n'ai pas pu atteindre les deux simultanément.
Alors finalement, j'ai dû passer l'argument de MSBuild pour résoudre le problème.
Allez dans Éditer la définition de construction> Processus> 3. Avancé> Arguments MSBuild (définis sur) /p:VisualStudioVersion=12.0
Cela a fonctionné pour moi.
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 fichier .csproj 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 lorsque j'ai installé des composants VS. Malheureusement, aucune de ces réponses ne m'a pas aidé. J'utilise TFS pour le développement de commandes et je n'ai pas le droit de modifier la définition de génération. J'ai résolu ce problème en supprimant les variables d'environnement appelées VS110COMNTOOLS et VS120COMNTOOLS. Je pense qu'il a été installé avec mes composants VS.
Une seule chose à faire pour résoudre le problème: mettez à niveau TeamCity vers la version 8.1.x ou une version ultérieure, car la prise en charge de Visual Studio 2012/2013 et de MSBuild Tools 2013 n'a été introduite que dans TeamCity 8.1. Une fois que vous avez mis à niveau votre paramètre de modification de CityCity dans MSBuild Tools dans votre étape de construction, le problème disparaîtra. Pour plus d'informations, lisez ici: http://blog.turlov.com/2014/07/upgrade-teamcity-to-enable-support-for.html
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. Supprimez simplement ceci de csproj puis construisez.
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 comme je n'avais que 5 Go d'espace libre, je viens de copier C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio sur mon serveur de build et de l'appeler un jour. . J'ai commencé à travailler après cela en utilisant Team City 9.x et Visual Studio 2013.
J'ai constaté qu'il me manquait le dossier WebApplications sur mon PC local. Je n'ai pas installé avec Visual Studio 2017 comme c'était le cas lorsque j'utilisais 2012.
Moi - rien n'aidait à changer la valeur v11.0 de la variable VisualStudioVersion en v10.0. Changer la variable dans le fichier .csproj n'a pas été. Le paramétrer par une 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.
Dans mon cas, j'utilisais la mauvaise version de MSBuild.exe.
La version à 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).
Ceci 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.