Erreur de construction de VS2013 externe "error MSB4019 : The imported project <path> was not found"

Question

Je construis un projet par la ligne de commande et non dans Visual Studio 2013. J'ai mis à jour mon projet de Visual Studio 2012 à 2013. Le projet se construit bien dans l'IDE. De plus, j'ai d'abord désinstallé complètement VS2012, puis redémarré et installé VS2013. La seule version de Visual Studio que je possède 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 originale était la v10.0, mais j'ai manuellement changé cela en v12.0.

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

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

J'ai essayé de spécifier VSToolsPath dans mon tableau de variables d'environnement système, mais l'utilitaire de construction externe utilise toujours la v11.0. J'ai essayé de faire une recherche 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.

Qu'en pensez-vous ?

Answer 1

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

Il est dû au fait que Vs2012 a ajouté 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 retirer cette partie en toute sécurité et votre solution sera construite.

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

Dans le cas contraire, si vous devez utiliser webdeploy ou si vous utilisez un serveur de construction, la solution ci-dessus ne fonctionnera pas mais vous pouvez spécifier le paramètre VisualStudioVersion dans votre script de construction :

msbuild myproject.csproj /p:VisualStudioVersion=12.0

ou modifiez votre définition de construction :

Answer 2

J'ai eu ce problème aussi et vous pouvez le résoudre 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 allez dans la section " Processus page ". Ensuite, sous la rubrique " 3. Avancé "Vous avez une propriété appelée " Arguments de MSBuild ". Placez-y le paramètre avec la syntaxe suivante

/p:VisualStudioVersion=12.0 

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

Answer 3

Ceci est étroitement lié mais peut ou ne peut pas résoudre le problème spécifique du PO. Dans mon cas, j'ai essayé d'automatiser le déploiement d'un site Azure en utilisant 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 pas du .Net Framework (cf. http://timrayburn.net/blog/visual-studio-2013-and-msbuild/ ). Fondamentalement, utilisez la bonne version 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 déplacé les choses)

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

Answer 4

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

En gros, je dois appeler les personnes suivantes avant de construire. 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

J'espère que cet article aidera quelqu'un d'autre.

Answer 5

La solution de Giammin est partiellement incorrecte. Vous êtes sur NE DEVRAIT PAS supprimez l'ensemble de ce PropertyGroup de votre solution. Si vous le faites, "DeployTarget=Package" de MSBuild. la fonction cessera de fonctionner. Cette fonction s'appuie sur le "VSToolsPath". en cours.

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