v11.0\WebApplications\Microsoft.WebApplication.targets introuvable lorsque le fichier fait référence à la v10
D'abord un peu de fond. Fin 2012, nous avons migré notre solution vs2008 vers vs2010 mais nous ciblons toujours .NET 3.5. (Je ne connais que le dernier et le meilleur ici!)
Nous n'avions eu aucun problème avec cette configuration jusqu'à il y a quelques semaines, quand les gens ont commencé à avoir 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 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 que des mises à jour ont été envoyées 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.
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\<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) l’installation du 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 de pépites
<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="true" />
MODIFIER
Comme @joedragons l'indique, la version de la ligne mise à jour doit correspondre à celle du package de nuget, c'est-à-dire remplacer targets.11.0.2.1 par targets.x.x.x.x pour la version actuelle.
Une solution simple à ce problème:
Allez dans le 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 dossier WebApplications à partir de l’un des répertoires de la dernière version et collez-le dans un autre.
Vos problèmes devraient être résolus.
J'ai constaté que l'installation gratuite Visual Studio 2012 Shell (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 .NET 4.0 cible. Nos fichiers de projet importent explicitement la version 10.0 de ces cibles. En l'absence de modification du code, hier, la construction é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 compilation en tant que mise à jour automatique. Nous allons forcer la v10.0 avec le paramètre (ou variable env.), Mais cela nous a certainement pris par surprise ...
UPDATE: Ce qui est encore plus étrange, c'est qu'il semble que la version actuelle de msbuild semble utiliser la première ligne du fichier sln pour déterminer quel 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 à 11.00 et la construction a recommencé à fonctionner.
Dans notre cas, même si nous visons et construisons tout pour 2010/12, certains développeurs se préparaient pour VS2012 (puisque MS prétendait que les fichiers du projet étaient compatibles) et cette solution particulière a été enregistrée pour la dernière fois (il y a plusieurs mois) VS2012. Avant aujourd'hui, cela ne posait pas de problème.
J'ai eu le même problème. Fixé 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 une 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 web.targets en fonction de la version de Visual studio utilisée. Les fichiers suivants seront modifiés avec les modifications requises
Dans packages.config:
<package id="MSBuild.Microsoft.VisualStudio.Web.targets" version="14.0.0.3" targetFramework="net45" />
En .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é,
Pavan
Hack, mais l'a résolu en copiant: MSBuild\Microsoft\VisualStudio\v11.0\WebApplications *. *
J'ai eu cette erreur à la fin du mois de novembre sans apporter de modification à la configuration de mon installation TeamCity ou de MSBuild ni au code source. Sur mon serveur de build, Visual Studio n'est même pas installé et le passage de VS2010 à VS2012 a été effectué fin août sans aucun problème.
Ma version de MSBuild est 4.0.30319.18408, mon serveur de génération 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 à partir d'un autre serveur de compilation qui n'a pas été affecté.
Je suppose que cela aurait pu se produire de deux manières:
Quelque chose a été mis à jour qui a déclenché la suppression du dossier v11. Pourrait-il s'agir d'une mise à jour Windows vers .NET ou autre chose?
Quelque chose a été mis à jour qui a modifié ma configuration TeamCity/MSBuild de v10 à v11 et les versions ne fonctionnent plus car la v11 n'a jamais existé.
J'ai une mise à jour de .NET Framework 4.5.1 le 3 décembre, cela pourrait-il être la raison?
Brgds
Jonas
Je me suis récemment retrouvé 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 installé la version appropriée des fichiers. Vous devriez donc spécifier un paramètre et utiliser les cibles existantes sur votre ordinateur.
Dans de rares cas, vous devrez peut-être installer une version spécifique du package VS et Web Deploy. Dans mon cas, seule la version suffit à 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 recommanda de copier le dossier MSBUILD manquant ou d'installer un SDK d'une version quelconque.
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 résumé, l’idée est de configurer la version de VisualStudio que votre construction doit utiliser dans votre définition de construction:
Clic droit -> "Modifier la définition de construction ..."
Allez dans "Procss" -> "3. Avancé"
et définissez "MSBuild Arguments" avec
/p:VisualStudioVersion=12.0