J'ai cette erreur lors de la configuration de l'intégration continue dans le serveur TFS, mais j'ai déjà trouvé la réponse. Peut-être que cela aidera d'autres personnes :
The imported project "C:\Program Files (x86)\
MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\
Microsoft.WebApplications.targets" was not found.
Oui, c'est la réponse. J'allais répondre moi-même mais je me suis dit que je n'avais pas assez de réputation pour le faire tout de suite. La réponse est aussi ici : stack247.wordpress.com/2011/08/29/…
Y a-t-il des circonstances actuelles dans lesquelles nous sommes pas autorisé à copier des cibles sur une machine de construction ? Sommes-nous toujours autorisés à copier un fichier .targets à partir d'une installation Visual Studio, en supposant qu'une seule machine soit autorisée à utiliser cette unité de gestion des stocks ?
Pour tous ceux qui tomberont sur ce problème à l'avenir, rappelez-vous qu'il arrive que les projets soient configurés avec des chemins statiques. Dans mon cas, le projet est configuré avec un chemin statique vers v11.0 tout en se développant dans v12.0 et j'ai donc juste eu besoin de dupliquer la petite structure de dossiers dans les v11.0 chemin. Bonne réponse Jim !
<!--<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />-->Commenter la ligne ci-dessus dans le .CSproj. Il semble que ce soit un bug de Microsoft qui ne supprime pas ou ne commente pas lors de la mise à jour du projet de Visual Studio 2008 à 2010.
J'ai eu un problème similaire, mais avec une version différente de VS. <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
J'ai vécu une expérience similaire.
J'avais écrit ceci dans notre Autobuild.targets exécuté dans le cadre d'une construction. Il définit MSWebApplicationTargets :
<MSWebApplicationTargets>$(SolutionDirectory)\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3</MSWebApplicationTargets>Puis dans un .csproj qui fait partie du projet et qui a été utilisé dans le build qu'il a eu :
<Import
Project="$(MSWebApplicationTargets)/tools/VSToolsPath/WebApplications/Microsoft.WebApplication.targets" />Maintenant, notre problème était que lorsque nous avons ouvert le projet dans Visual Studio, il a dit que c:/tools/VSToolsPath/WebApplications/Microsoft.WebApplication.targets n'existe pas (parce que VS a considéré MSWebApplicationTargets pour être indéfini et semblait donc être par défaut à c:\ ). Vous ne fournissez pas assez d'informations, mais c'est peut-être ce qui a causé votre problème également.
Tout ce que j'avais à faire pour résoudre ce problème était d'ajouter une condition :
<Import
Project="$(MSWebApplicationTargets)/tools/VSToolsPath/WebApplications/Microsoft.WebApplication.targets"
Condition="'$(MSWebApplicationTargets)' != ''" />Microsoft.WebApplication.targets
Dans le cadre d'une discussion ultérieure, j'ai fait cela avec Microsoft.WebApplication.targets pour ne pas avoir à compter sur l'installation de Visual Studio sur les serveurs de construction. Je l'ai ajouté comme une dépendance :
manage nuget packages . Cela a créé un packages.config qui énumère MSBuild.Microsoft.VisualStudio.Web.targets en tant que dépendance.nuget.exe restore au début du build script pour que les dépendances soient téléchargées.
Télécharger et installer Paquet Redistribuable Microsoft Visual Studio 2013 Shell (isolé) . Ou utilisez le lien direct vers vs_isoshell.exe . J'ai l'intention de créer un paquet NuGet pour cela à une date ultérieure.
L'avantage que je vois à cette approche est qu'elle lève tout doute sur les questions de droits d'auteur.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Voir aussi ... stackoverflow.com/questions/3980909/