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


201

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?



Dans mon cas, j'ai dû spécifier la VisualStudioVersion correcte dans l'événement de génération qui était en cours de construction avec la cible WebPublish.
user145400

Réponses:


250

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:

modifier la définition de build pour spécifier la propriété <code> VisualStudioVersion </code>


1
J'ai eu l'erreur en utilisant msbuild à partir de l'invite de commande. La suppression de cette partie du fichier de projet a résolu le problème.
Peter Hedberg

7
J'ai utilisé cette réponse et cela ne fonctionnait que si je m'assurais que mon fichier * proj commençait par <Project ToolsVersion = "12" Avant d'avoir <Project ToolsVersion = "4" et chaque fois que j'ouvrais le projet dans VS, il ajoutait à nouveau les deux nœuds (c'est-à-dire qu'il a migré à nouveau le projet vers la dernière version).
Sielu

3
@giammin, j'ai déjà trouvé la solution. NE supprimez PAS la section de votre fichier de projet. Définissez la bonne 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". Bien sûr, sans les guillemets. Si vous avez plus de paramètres, séparez-les par un espace et non par une virgule. La config que vous avez suggéré de supprimer est utilisée par d'autres parties de Visual Studio dans vos processus de construction ...
Ralph Jansen

9
La suppression de cette ligne semble casser Web Deploy
Colin Pear

4
Le même problème a été résolu en utilisant la propriété /p:VisualStudioVersion=12.0 comme recommandé ci-dessus. Merci
Randeep

70

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.


1
Nous venons de terminer une mise à niveau de TFS 2005 vers TFS 2013 et ce fut notre dernier obstacle. Cela a définitivement fonctionné pour nous et m'a évité d'arracher mes cheveux. Merci beaucoup! +1.
Simon Whitehead

2
Cet article de Sayed Ibrahim Hashimi décrit le problème dans Visual Studio 2010/2012. Une génération de ligne de commande utilise le format de fichier sln version -1 comme VisualStudioVersion. Vous pouvez remplacer cette valeur à partir de la ligne de commande comme Ralph le décrit, ou en tant que propriété de la tâche MSBuild à partir d'un script de génération. J'ai eu le même problème avec Visual Studio 2013 et la substitution de VisualStudioVersion a résolu le problème.
mcdon

1
Cela a également fonctionné pour nous. Nous avons également envisagé de modifier le modèle de build lui-même, décrit ici , ce qui pourrait être une meilleure option si vous avez des dizaines de définitions de build.
JamesQMurphy

cela a fonctionné pour moi. J'ai supprimé dans les fichiers csproj toute référence à visualstudioversion, puis ajouté cet argument
msbuild

51

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

Cela m'a corrigé. Aussi, réponse similaire pour une question similaire ici: stackoverflow.com/a/19826448/61569
Anthony F

22

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.


Merci beaucoup, cela a résolu mon problème lors de la construction de nodeJS node-gyple Cpp default.propsn'a pas été trouvé! +1
Pogrindis

21

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

10

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.


5
Il s'agit probablement d'un scénario courant lors de l'exécution d'un serveur de build (tel que CruiseControl ou TeamCity), où le service s'exécute sous un compte de service particulier qui peut même ne pas avoir d'autorisations de bureau interactives. Cette astuce a résolu le problème pour moi (VS 2013 installé sur une nouvelle installation de Server 2008 R2, avec CruiseControl.NET)
David Keaveny

Où puis-je voir ma "VisualStudioVersion"?
WEFX

@WEFX afficher les variables d'environnement en sélectionnant Systemdans le panneau de configuration, puis sélectionnez Advanced system settingset enfin cliquez surEnvironment Variables
Scott

6

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


Cela a fonctionné pour moi et était préférable à la modification du fichier de projet.
Sean

4

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


1
ToolsVersion ne doit pas être la seule variable à corriger ce message d'erreur car j'ai vu un projet avec ToolsVersion qui n'a pas pu être construit correctement.
Patrick Desjardins

2

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.


2

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.


2

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.


2

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.


2

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.


2

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


J'ai utilisé "C: \ Program Files (x86) \ Microsoft Visual Studio \ 2019 \ Enterprise \ MSBuild \ Current \ Bin \ MSBuild.exe" au lieu de "C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ MSBuild. exe "et ses travaux
ELKALAKHI Mohammed

Oui, j'utilise un projet SSDT (.sqlproj), avec VisualStudioVersion = 14.0 dans le fichier de projet. J'ai installé le noyau 3.1, qui définit mes vars env pour les cibles à Dieu sait seulement où. Utiliser msbuild dans le dossier que vous avez suggéré a fonctionné comme un charme!
Matthew Beck

1

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.


1

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 \


Ou copiez simplement le fichier Microsoft.WebApplication.targets à partir d'un emplacement où Visual Studio 2013 est installé.
ThatBlairGuy

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.


0

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


0

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.


0

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.


0

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


0

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.


0

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.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.