v11.0 \ WebApplications \ Microsoft.WebApplication.targets est introuvable lorsque le fichier fait réellement référence à v10

D’abord un peu de contexte. Fin 2012, nous avons migré notre solution vs2008 vers vs2010 mais nous ciblons toujours .NET 3.5. (Je ne connais rien d’autre que le dernier et le meilleur ici!)

Nous n’avions eu aucun problème avec cette configuration il y a quelques semaines lorsque les utilisateurs ont commencé à recevoir 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. 

La chose intéressante 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 frappé plusieurs d’entre nous à la fois et même sur les anciennes twigs de code qui n’ont pas changé depuis des mois.

Je soupçonne que certaines mises à jour ont été envoyées sur nos machines, ce qui a créé de la confusion, mais je ne sais pas quoi faire.

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

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 fournie avec le .NET Framework – à partir de la ligne de commande. Microsoft publie maintenant MSBuild dans le cadre de Visual Studio lui-même et également en tant qu’installateur distinct ( http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of- visual-studio.aspx ).

La solution consistait à utiliser la nouvelle version de MSBuild.exe située dans 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 un nouveau répertoire. Pour Visual Studio 2015, utilisez C:\Program Files (x86)\MSBuild\14.0\Bin .

EDIT 2

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

Si vous avez un serveur de compilation sur lequel VS2012 n’est pas installé, vous pouvez résoudre ce problème en

a) installer le package MSBuild.Microsoft.VisualStudio.Web.targets sur votre solution, et

b) remplacer cette ligne dans le fichier .csproj:

  

Avec cette ligne pointant vers le paquet nuget

  

MODIFIER

Comme @joedragons indique que la version dans la ligne mise à jour doit correspondre à la version du package nuget, c’est-à-dire remplacer les targets.11.0.2.1 par targets.xxxx pour la version actuelle.

Une solution simple à ce problème:

Aller sur le chemin suivant:

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

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

Copiez le dossier WebApplications répertoire de la dernière version et collez-le dans un autre.

Vos problèmes doivent être résolus.

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

Sensationnel. 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 10.0 de ces cibles. En l’absence de modification du code, hier, la construction s’est bien déroulée et aujourd’hui elle échoue avec une plainte concernant une version v11.0 manquante. Le .NET Framework 4.5.1 a été installé / mis à jour hier soir sur cette machine de génération en tant que mise à jour automatique. Nous allons forcer la v10.0 avec le paramètre (ou la variable env.), Mais cela nous a certainement pris par surprise …

UPDATE: Ce qui est encore plus étrange, c’est que la version actuelle de msbuild semble utiliser la première ligne du fichier sln pour déterminer quelle VisualStudioVersion utiliser par défaut, alors que la version d’hier n’a pas:

 Format Version 12.00 

Nous avons testé manuellement en changeant cela à 11h00 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 préparaient pour VS2012 (puisque MS affirmait que les fichiers de projet étaient compatibles) et que cette solution particulière avait été enregistrée pour la dernière fois (il y a plusieurs mois) dans VS2012. Avant aujourd’hui, cela ne posait pas de problème.