v11.0 \WebApplications\Microsoft.WebApplication.targets n'a pas été trouvé alors que le fichier fait référence à la version 10

Question

Tout d'abord, un peu d'histoire. Fin 2012, nous avons migré notre solution vs2008 vers vs2010 mais nous visons toujours .NET 3.5. (Je ne connais rien d'autre que le dernier et le meilleur ici !).

Nous n'avions pas eu de problèmes avec cette configuration jusqu'à ce que, il y a quelques semaines, des personnes aient commencé à obtenir ces erreurs :

"foo.csproj" (Rebuild target) (16:5) ->
  C:\...\foo.csproj(142,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 declaration is correct, and that the file exists on disk.

Ce qui est intéressant, c'est que si vous regardez le fichier de projet, il fait référence à v10, ce qui est logique car nous n'utilisons pas Visual Studio 2012.

Cette erreur a touché plusieurs d'entre nous en même temps et même sur des branches de code plus anciennes qui n'ont pas été modifiées depuis des mois.

Je soupçonne qu'une mise à jour a été poussée sur nos machines et a brouillé les choses, mais je ne sais pas quoi faire à ce sujet.

La solution à court terme a été d'installer VS 2012 et de ne pas l'utiliser, mais j'espère quelque chose d'un peu plus propre que cela.

Answer 1

J'ai rencontré le même problème avec Visual Studio 2013. Il s'avère que j'utilisais l'ancienne version de MSBuild - celle qui est livrée avec le .NET Framework - à partir de la ligne de commande. Microsoft publie désormais MSBuild dans le cadre de Visual Studio lui-même, ainsi que sous la forme d'un programme d'installation distinct ( http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx ).

La solution a consisté à utiliser la nouvelle version de MSBuild.exe située dans le répertoire C:\Program Files (x86)\MSBuild\12.0\Bin . Une fois que j'ai fait cela, toutes les erreurs de cibles ont disparu.

EDIT 1

Comme mentionné dans les commentaires, chaque nouvelle version de MSBuild apporte avec elle un nouveau répertoire. Pour Visual Studio 2015, utilisez C:\Program Files (x86)\MSBuild\14.0\Bin .

EDIT 2

Comme indiqué dans les commentaires, pour Visual Studio 2017, utilisez C:\Program Files (x86)\Microsoft Visual Studio\2017\<Edition>\MSBuild\15.0\Bin\MSBuild.exe .

Answer 2

Si vous disposez d'un serveur de construction sur lequel VS2012 n'est pas installé, vous pouvez résoudre ce problème en procédant comme suit

a) l'installation du MSBuild.Microsoft.VisualStudio.Web.targets à votre solution, et

b) en remplaçant cette ligne dans le fichier .csproj :

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

Avec cette ligne pointant vers le paquet nuget

<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="true" />

EDIT

Comme le souligne @joedragons, la version dans la ligne mise à jour doit correspondre à la version du paquet nuget, c'est-à-dire qu'il faut remplacer targets.11.0.2.1 avec targets.x.x.x.x pour la version actuelle.

Answer 3

Une solution simple à ce problème :

Allez au chemin suivant :

C:\Program Fichiers (x86) \MSBuild\Microsoft\VisualStudio

Vous verrez la dernière version V10.0, v11.0, v12.0 en fonction de votre installation de Visual Studio 2010, 2012 ou 2013.

Copie WebApplications de l'un ou l'autre des répertoires de la dernière version et le coller dans l'autre.

Vos problèmes devraient être résolus.

Answer 4

J'ai constaté que l'installation du logiciel gratuit Visual Studio 2012 Shell (isolé) installe les fichiers MSBuild de WebApplications v11. Plus léger qu'une installation complète de Visual Studio 2012 et aucun problème de licence.

Answer 5

Wow. Nous venons de voir la même chose se produire sur notre machine de construction. Nous utilisons VS2010 et ciblons .NET 4.0. Nos fichiers de projet importent explicitement la version v10.0 de ces cibles. Sans aucun changement dans le code, hier la compilation était correcte et aujourd'hui elle échoue avec une plainte à propos d'une version v11.0 manquante. Le .NET Framework 4.5.1 a été installé/mis à jour la nuit dernière sur cette machine de construction en tant que mise à jour automatique. Nous allons forcer la version 10.0 avec le paramètre (ou la variable env.), mais cela nous a pris par surprise...

MISE À JOUR : Ce qui est encore plus bizarre, c'est qu'il semble que la version actuelle de msbuild utilise la première ligne du fichier sln pour déterminer la VisualStudioVersion à utiliser par défaut, alors que la version d'hier ne le faisait pas :

Format Version 12.00

Nous avons testé manuellement le passage à la version 11.00 et la construction a recommencé à fonctionner.

Dans notre cas, même si nous ciblons et construisons tout pour 2010/4.0, certains développeurs se sont préparés pour VS2012 (puisque MS a affirmé que les fichiers de projet sont compatibles), et cette solution particulière a été sauvegardée pour la dernière fois (il y a des mois) dans VS2012. Avant aujourd'hui, cela ne posait pas de problème.