Microsoft.WebApplication.targets est introuvable, sur le serveur de génération. Quelle est votre solution?
Essayer de construire mon projet sur le serveur de compilation me donne l'erreur suivante:
Microsoft (R) Build Engine Version 4.0.30319.1
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
J'ai résolu ce problème il y a quelques mois en installant Visual Studio 2010 sur le serveur de génération. Mais maintenant, je configure un nouveau serveur à partir de rien et je veux savoir s’il existe une meilleure solution pour résoudre ce problème.
Pour répondre au titre de la question (mais pas à la question concernant le résultat obtenu):
La copie du dossier suivant de votre ordinateur dev sur votre serveur de compilation résout ce problème s'il ne s'agit que d'applications Web.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications
Supprimez x86 en fonction de la rupture de votre construction. Si vous avez d'autres types de projets, vous devrez probablement copier le dossier msbuild en entier.
La création et la publication de WAP ne sont pas prises en charge si VS n’est pas installé. Cela dit, si vous ne voulez vraiment pas installer VS, vous devrez copier tous les fichiers sous %ProgramFiles32%\MSBuild\Microsoft\.
Vous devrez également installer le Web Deploy Tool . Je pense que c'est ça.
UPD: à compter de VS2017, il existe une charge de travail dans Build Tools qui élimine complètement ce problème. Voir @SOReader answer .
Si vous préférez ne rien modifier sur le serveur de génération et que vous souhaitez tout de même que le projet repose directement sur le contrôle de source, il peut être judicieux de placer les fichiers binaires requis sous le contrôle de source. Vous devrez modifier la section des importations dans votre fichier de projet pour ressembler à ceci:
<Import Project="$(SolutionDir)\BuildTargets\WebApplications\Microsoft.WebApplication.targets" />
<Import Condition="false" Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
La première ligne représente l'importation réelle à partir du nouvel emplacement par rapport au répertoire de la solution. La seconde est une version désactivée (Condition="false") de la ligne d'origine qui permet à Visual Studio de toujours considérer votre projet comme un projet d'application Web valide (c'est le truc que VS 2010 SP1 fait lui-même).
N'oubliez pas de copier le dossier C:\Program Files (x86)\Microsoft\VisualStudio\v10.0\WebApplications dans BuildTargets sous votre contrôle de source.
Vous pouvez également utiliser le package NuGet MSBuild.Microsoft.VisualStudio.Web.targets , en les référençant dans vos projets Visual Studio, puis modifiez vos références comme suggéré par Andriy K.
Basé sur ce post ici vous pouvez simplement télécharger le Package redistribuable Microsoft Visual Studio 2010 Shell et les cibles sont installées.
Cela évite d'installer Visual Studio sur le serveur de génération.
Je viens d'essayer ceci maintenant, et peux vérifier que cela fonctionne:
Avant:
erreur MSB4019: le projet importé "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" n'a pas été trouvé. Confirmez que le chemin dans la déclaration est correct, et que le fichier existe sur le disque.
Après l'installation:
[Construit correctement]
C'est une solution bien meilleure que l'installation de Visual Studio sur un serveur de construction, bien évidemment.
À l'heure actuelle, en 2017, vous pouvez installer des redistributeurs WebApplication avec MSBuildTools. Allez simplement sur cette page qui téléchargera MSBuild 2017 Tools et pendant l'installation, cliquez sur Web development build tools pour que ces cibles soient également installées: 
Cela conduira à installer les bibliothèques manquantes dans C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications par défaut
Le dernier SDK Windows, comme mentionné ci-dessus, en plus du "Package redistribuable Microsoft Visual Studio 2010 Shell" pour Microsoft.WebApplication.targets et "Edition de base de données Microsoft Visual Studio Team System 2008 GDR R2". for Microsoft.Data.Schema.SqlTasks.targets devrait réduire le besoin d’installer Visual Studio 2010. Toutefois, l’installation de VS 2010 est peut-être moins complexe à télécharger et moins laborieuse à la fin.
Lors de la construction sur le serveur build/CI, désactivez l'importation de Microsoft.WebApplication.targets en spécifiant /p:VSToolsPath=''. Cela va essentiellement rendre fausse la condition de la ligne suivante:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
Voici comment cela se passe dans TeamCity:
Ajouter une dépendance via NuGet et définir un paramètre de construction
Goal: aucune modification/installation nécessaire pour les agents de génération
J'ai adopté une approche hybride de la approche NuGet de Lloyd ici basée sur la solution solution de dépendances binaires de Andrik.
Je veux pouvoir ajouter de nouveaux agents de génération sans avoir à les préconfigurer avec des éléments tels que celui-ci.
- Sur une machine avec Visual Studio, ouvrez la solution. ignorer que le projet Web échoue.
- Dans le gestionnaire de paquets NuGet, ajoutez MSBuild.Microsoft.VisualStudio.Web.targets , comme l'a mentionné Lloyd.
- Cela résoudra les fichiers binaires en
[solution]\packages\MSBuild.Microsoft.VisualStudio.Web.targets.nn.n.n.n\tools\VSToolsPath\- Vous pouvez les copier dans un dossier de références & commit,
- Ou tout simplement les utiliser là où ils sont. J'ai choisi ceci, mais je vais devoir traiter du numéro de version dans le chemin plus tard.
Dans la version 7, j'ai fait ce qui suit. Cela n’a peut-être pas été nécessaire et, d’après les commentaires, ce n’est absolument plus nécessaire maintenant. S'il vous plaît voir les commentaires ci-dessous.
- Ensuite, dans votre configuration de génération TeamCity, ajoutez un Paramenter de génération pour
env.VSToolsPathet définissez-le dans le dossier VSToolsPath. J'ai utilisé..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath
Si vous migrez Visual Studio 2012 vers 2013, ouvrez le fichier de projet * .csproj avec edior.
et vérifiez l’élément ToolsVersion de la balise 'Project'.
Changer sa valeur de 4.0 à 12.0
De
<?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="4.0" ...À
<?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="12.0" ...
Ou si vous construisez avec msbuild, spécifiez simplement la propriété VisualStudioVersion
msbuild /p:VisualStudioVersion=12.0
C'est tout ce dont vous avez besoin. Seulement 103MB. Ne pas tout installer
Il semble que la nouvelle version de msbuild ne soit pas livrée avec Microsoft.WebApplication.targets. Pour résoudre ce problème, vous devez mettre à jour votre fichier csproj de la manière suivante:
1) Modifiez l’application Web csproj (clic droit). Trouvez la section dans le csproj vers le bas concernant les outils de construction. Cela devrait ressembler à ça.
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
2) Vous devez ajouter une ligne VSToolsPath sous la balise VisualStudioVersion afin qu’elle ressemble à
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<!--Add the below line to fix the project loading in VS 2017 -->
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<!--End -->
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
Lien de référence: https://alastaircrabtree.com/cannot-open-vs-2015-web-project-in-vs-2017/
J'ai trouvé ceci sur MS connect :
Oui, vous devez installer Visual Studio 2010 sur votre machine à construire pour construire projets de base de données. Cela fait pas besoin d'une licence supplémentaire de Visual Studio.
Donc, c'est la seule option que j'ai pour l'instant.
Tous ceux qui viennent ici pour Visual Studio 2017. J'avais le même problème et je ne pouvais pas compiler le projet après la mise à jour vers 15.6.1. J'ai dû installer les outils MSBulild mais l’erreur était toujours là.
J'ai pu résoudre le problème en copiant le dossier v14.0 de C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio dans le même dossier que v15.0, ce qui a résolu toutes les erreurs. Alors maintenant, ma structure de dossiers ressemble à celle ci-dessous, où les deux dossiers contiennent le même contenu.
J'ai essayé plusieurs solutions, mais au final, cette réponse a fonctionné pour moi: https://stackoverflow.com/a/19826448/431522
Cela implique essentiellement d'appeler MSBuild à partir du répertoire MSBuild, au lieu du répertoire Visual Studio.
J'ai également ajouté le répertoire MSBuild à mon chemin, afin de rendre les scripts plus faciles à coder.
Ma solution est un mélange de plusieurs réponses ici.
J'ai vérifié le serveur de compilation et le SDK Windows7/NET4.0 était déjà installé. J'ai donc trouvé le chemin:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets`
Cependant, sur cette ligne:
<Import Project = "$ (MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
$ (MSBuildExtensionsPath) passe à C:\Program Files\MSBuild qui n'a pas le chemin.
Par conséquent, ce que j'ai fait était de créer un lien symbolique en utilisant cette commande:
mklink/J "C:\Programmes\MSBuild\Microsoft\VisualStudio" "C:\Programmes (x86)\MSBuild\Microsoft\VisualStudio"
De cette façon, $ (MSBuildExtensionsPath) se développe en un chemin valide. Aucune modification n’est nécessaire dans l’application elle-même, mais uniquement dans le serveur de génération (vous pouvez éventuellement créer le lien symbolique à chaque génération pour vous assurer que cette étape n’est pas perdue et documentée ").
J'ai corrigé cela en ajoutant/p:VCTargetsPath="C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\V120"
dans Build > Build a Visual Studio project or solution using MSBuild > Command Line Arguments
Si vous utilisez MSBuild, comme dans le cas d'un serveur de compilation, ce qui a fonctionné pour moi est le suivant:
Modifiez les éléments suivants:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
à:
<Import Project="$(MSBuildBinPath)\Microsoft.VisualBasic.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
Ma commande Msbuild est: *"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" solution.sln /p:Configuration=Debug /p:Platform="Any CPU"*
J'espère que ça aide quelqu'un.
Si vous essayez de déployer un projet avec VSTS, le problème peut être lié à la vérification de l'option "Conteneur Windows hébergé" au lieu de "VS2017 hébergé" (ou 18, etc.):
