c# visual - Erreur de génération externe VS2013 "MSB4019: Le projet importé <path> n'a pas été trouvé"





studio download (19)


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 \

Je construis un projet via la ligne de commande et non à l'intérieur de Visual Studio 2013. Remarque, j'avais mis à jour mon projet de Visual Studio 2012 à 2013. Le projet s'intègre parfaitement dans l'IDE. En outre, j'ai complètement désinstallé VS2012 en premier, 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 v10.0, mais j'ai manuellement changé cela en v12.0.

$ (VSToolsPath) s'allonge depuis 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 ma table de variables d'environnement système, mais l'utilitaire de construction externe utilise toujours v11.0. J'ai essayé de chercher dans le registre et cela n'a rien donné.

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 trouvé une solution plus facile

Il est dû à Vs2012 en ajoutant dans le fichier csproj cette partie:

<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 va se construire.

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

Sinon, si vous devez utiliser webdeploy ou si vous utilisez 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 construction:




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.

Comme il se trouve, il y a une macro globale dans le projet, DEVSTUDIO_NET_DIR. J'ai dû changer le chemin vers .Net là. Ils listent différentes versions de studio visuel comme des "Actions", qui à travers moi, mais tous les chemins ramènent à cette variable globale dans les coulisses. J'inscrirais cela comme un défaut contre le produit, si je le pouvais, à moins que je ne manque quelque chose dans ma compréhension. La correction du chemin a corrigé le problème de construction.




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

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

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




J'avais essayé toutes les solutions ci-dessus et toujours pas de chance. J'avais entendu des gens installer le studio visuel sur leurs serveurs de construction pour le réparer, mais j'avais seulement 5gb d'espaces libres ainsi j'ai juste copié C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio à mon serveur de construction et l'ai appelé un jour . J'ai commencé à travailler après ça en utilisant team city 9.x et visual studio 2013.




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

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

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

J'espère que ce message aidera quelqu'un d'autre.




Une seule chose doit être faite pour résoudre le problème: mettre à niveau TeamCity vers la version 8.1.x ou ultérieure car le support pour Visual Studio 2012/2013 et MSBuild Tools 2013 a été introduit uniquement dans TeamCity 8.1. Une fois que vous avez mis à jour votre paramètre TeamCity, modifiez MSBuild Tools Version dans votre étape de construction et que le problème disparaîtra. Pour plus d'informations, lisez ici: http://blog.turlov.com/2014/07/upgrade-teamcity-to-enable-support-for.html




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 == à != Et la valeur de 10.0 à 12.0 .




Lancer ceci dans la ligne de commande résoudra également le problème. SETX VisualStudioVersion "12.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. Supprimez simplement ceci de csproj et puis construisez.




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

C'est très facile à faire. Ouvrez votre définition de build et allez à la page " Process ". Ensuite, sous le groupe " 3. Advanced ", vous avez une propriété appelée " MSBuild Arguments ". Placez le paramètre là avec la syntaxe suivante

/p:VisualStudioVersion=12.0 

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




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




Dans mon cas, l'environnement de développement est VS2013 et j'utilise TFS 2010. Build a été ciblé pour .NET 4.5.1. Je mettais en place la construction automatique pour CI. chaque fois que j'ai essayé des solutions de contournement mentionnées ci-dessus - comme supprimer des groupes de propriétés complètement ou en remplaçant certaines lignes etc.my build utilisé dans TFS mais ma publication à azur utilisé pour échouer avec 'MSDeploy' ou parfois une erreur différente. Je n'étais pas capable de réaliser les deux simultanément.

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

Goto Modifier la définition de construction> Traiter> 3. Avancé> Arguments MSBuild (définir sur) /p:VisualStudioVersion=12.0

Cela a fonctionné pour moi.




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.




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

<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 cette erreur quand j'installe des 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 pas les permissions pour éditer la définition de construction. J'ai résolu ce problème en supprimant les variables d'environnement qui appelaient VS110COMNTOOLS et VS120COMNTOOLS . Je pense qu'il a été installé avec mes composants VS.




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




Ceci est étroitement lié mais peut ou ne peut pas résoudre le problème spécifique d'OP. Dans mon cas, j'essayais d'automatiser le déploiement d'un site Azure en utilisant VS2013. Construire et déployer 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 de .Net Framework (voir http://timrayburn.net/blog/visual-studio-2013-and-msbuild/ ). Fondamentalement, utilisez la bonne version de MSBuild:

VIEUX, 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 bougé les choses un peu)

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



prods.Remove(prods.Single(p=>p.ID == 1));

vous ne pouvez pas modifier la collection dans foreach, comme le suggère Vincent





c# .net web-applications build visual-studio-2013