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

Tout 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 jusqu'à il y a quelques semaines, lorsque les gens 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 à la 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 des branches de code plus anciennes qui n'ont pas changé depuis des mois.

Je soupçonne qu'une mise à jour a été poussée sur nos machines, ce qui a semé 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 quelque chose d'un peu plus propre que cela.

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 maintenant MSBuild dans le cadre de Visual Studio lui-même et également en tant que programme d'installation 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.

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

MODIFIER 2

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

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

a) installer le package MSBuild.Microsoft.VisualStudio.Web.targets dans 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" />

ÉDITER

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

Une solution simple à ce problème:

Accédez au chemin suivant:

C: \ Program Files (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.

Copiez le WebApplicationsdossier de l'un des répertoires de la dernière version et collez-le dans l'autre.

Vos problèmes devraient être résolus.

J'ai constaté que l'installation du shell Visual Studio 2012 gratuit (isolé) installe les fichiers MSBuild WebApplications v11. 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 v10.0 de ces cibles. Sans aucune modification du code, hier, la version était correcte 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 construction 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 ...

MISE À JOUR: Ce qui est encore plus étrange, c'est qu'il semble être le cas 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 ne le faisait pas:

Format Version 12.00

Nous avons testé manuellement en changeant cela à 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 préparent pour VS2012 (depuis que MS a affirmé que les fichiers du projet sont compatibles), et cette solution particulière a été enregistrée pour la dernière fois (il y a des mois) dans VS2012. Avant aujourd'hui, cela ne posait pas de problème.

J'ai eu le même problème. Corrigé en passant par les solutions énumérées ci-dessus. Le problème est dû au fait que la version appropriée de Visual Studio Tools (BuildTools) n'est pas disponible sur le serveur de génération. Comme indiqué à juste titre ci-dessus, cela peut être résolu en installant BuildTools mais ce n'est pas l'option dans mon cas.

Voici une autre alternative - utilisez Nuget

Install-Package MSBuild.Microsoft.VisualStudio.Web.targets -Version 14.0.0.3

Identifiez le projet de démarrage et installez les web.targets en fonction de la version de Visual studio utilisée. Les fichiers suivants seront modifiés, ce qui inclut les changements requis

Dans packages.config:

<package id="MSBuild.Microsoft.VisualStudio.Web.targets" version="14.0.0.3" targetFramework="net45" />

Dans .csproj:

<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props" Condition="Exists('..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props')" />

J'espère que cela t'aides!!! Bonne chance,

À votre santé,

Pirater, mais l'a résolu en copiant: c: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications *. * Vers c: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \Des applications Web*.*

J'ai eu cette erreur à la fin du mois de novembre sans apporter de modifications à la configuration de mon installation TeamCity ou à l'installation de MSBuild ou au code source. Sur mon serveur de build, Visual Studio n'est même pas installé et le changement de VS2010 à VS2012 a été effectué à la fin du mois d'août sans aucun problème à l'époque.

Ma version MSBuild est 4.0.30319.18408, mon serveur de build est un Windows Server 2008 R2 SP1 avec TeamCity v6.5.3.

J'ai résolu le problème en copiant simplement le dossier v11 d'un autre serveur de construction qui n'était pas affecté.

Je suppose que cela aurait pu se produire de deux manières:

1. Quelque chose a été mis à jour qui a déclenché la suppression du dossier v11. Serait-ce une mise à jour Windows vers .NET ou quelque chose?

2. Quelque chose a été mis à jour qui a changé ma configuration TeamCity / MSBuild de l'utilisation de la v10 à la v11 et les versions cessent de fonctionner car la v11 n'a jamais existé.

J'ai une mise à jour de .NET Framework 4.5.1 le 3 décembre, est-ce que cela pourrait être la raison?

Brgds

Jonas

J'ai récemment été coincé avec le même problème. Et ma conclusion est que chaque version de VS (v10, v11, v12) change le chemin de la variable de construction, comme MSBuildBinPath.

Donc, spécifier la version exacte de VS n'est pas un hack, car vous n'avez peut-être même pas la version appropriée des fichiers installée. Alors, vous feriez mieux de spécifier un paramètre et d'utiliser des cibles qui existent sur votre machine.

Dans certains cas rares, vous devrez peut-être installer une version spécifique du package VS et Web Deploy. Dans mon cas, une seule version était suffisante pour résoudre le problème.

Vous pouvez ajouter la propriété VisualStudioVersion comme ceci:

<ItemGroup>
  <ProjectToBuild Include="$(MSBuildProjectDirectory)\..\MySolution.sln">
    <Properties>Configuration=$(BuildConfiguration);WarningLevel=0;VisualStudioVersion=12.0</Properties>
  </ProjectToBuild>
</ItemGroup>
<MSBuild Projects="@(ProjectToBuild)" Targets="Rebuild"/>

Alors que je cherchais comment résoudre celui-ci, presque tout le monde a recommandé de copier le dossier MSBUILD manquant ou d'installer un SDK d'une version.

Heureusement, j'ai trouvé cet article extrêmement utile de Donovan Brown: http://donovanbrown.com/post/So-sick-of-MicrosoftWebApplicationtargets-was-not-found-build-errors!

En un mot, l'idée est de configurer la version de VisualStudio que votre build doit utiliser dans votre définition de build:

Clic droit -> "Modifier la définition de construction ..."

Allez dans "Procss" -> "3. Avancé"

et définissez "MSBuild Arguments" avec

/p:VisualStudioVersion=12.0