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 build 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 build. Mais maintenant, je configure un nouveau serveur à partir de zéro, 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 sur la sortie que vous obtenez):

La copie du dossier suivant de votre machine de développement vers votre serveur de build 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 build. Si vous avez d'autres types de projets, vous devrez probablement copier l'intégralité du dossier msbuild.

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 l' outil de déploiement Web . Je pense que c'est ça.

UPD: à partir de VS2017, il y a une charge de travail dans Build Tools qui élimine complètement ce problème. Voir la réponse @SOReader .

Si vous préférez ne rien modifier sur le serveur de génération et que vous souhaitez toujours que le projet soit généré hors du contrôle de code source, il peut être judicieux de placer les fichiers binaires requis sous contrôle de code 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 est l'importation réelle du nouvel emplacement par rapport au répertoire de la solution. Le second 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 l'astuce que VS 2010 SP1 fait lui-même).

N'oubliez pas de copier le dossier C:\Program Files (x86)\Microsoft\VisualStudio\v10.0\WebApplicationsto BuildTargetssous votre contrôle de source.

À l'heure actuelle, en 2017, vous pouvez installer les listes d'applications Web avec MSBuildTools. Rendez-vous simplement sur cette page qui téléchargera les outils MSBuild 2017 et pendant l'installation, cliquez Web development build toolspour obtenir ces cibles également:

Cela conduira à l'installation de bibliothèques manquantes C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplicationspar défaut

Vous pouvez également utiliser le package NuGet MSBuild.Microsoft.VisualStudio.Web.targets , en les référençant dans vos projets Visual Studio, puis modifier vos références comme Andriy K le suggère.

Sur la base de cet article, vous pouvez simplement télécharger le package redistribuable Microsoft Visual Studio 2010 Shell (intégré) et les cibles sont installées.

Cela évite d'avoir à installer Visual Studio sur le serveur de génération.

Je viens de l'essayer maintenant et je 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» est introuvable. Confirmez que le chemin d'accès dans la déclaration est correct et que le fichier existe sur le disque.

Après l'installation:

[Construit correctement]

Évidemment, c'est une bien meilleure solution que d'installer Visual Studio sur un serveur de build.

Le dernier SDK Windows, comme mentionné ci-dessus, en plus du «package redistribuable Microsoft Visual Studio 2010 Shell (intégré)» pour Microsoft.WebApplication.targets et «Microsoft Visual Studio Team System 2008 Database Edition GDR R2» pour Microsoft.Data.Schema .SqlTasks.targets devrait réduire la nécessité d'installer Visual Studio 2010. Cependant, l'installation de VS 2010 peut être en fait moins globale à télécharger et moins de travail à la fin.

Ajouter une dépendance via NuGet et définir un paramètre de construction

Objectif: aucune modification / installation nécessaire aux agents de build

J'ai adopté une approche hybride de l' approche NuGet de Lloyd ici , qui était basée sur la solution de dépendances binaires de validation d'Andrik.

La raison pour laquelle je veux pouvoir ajouter de nouveaux agents de build sans avoir à les préconfigurer avec des éléments tels que celui-ci.

1. Sur une machine avec Visual Studio, ouvrez la solution; ignorer que le projet Web échoue.
2. Dans le gestionnaire de packages NuGet, ajoutez MSBuild.Microsoft.VisualStudio.Web.targets , comme Lloyd l'a mentionné.
3. Cela résoudra les binaires en [solution]\packages\MSBuild.Microsoft.VisualStudio.Web.targets.nn.n.n.n\tools\VSToolsPath\
   1. Vous pouvez les copier dans un dossier de références et les valider,
   2. Ou utilisez-les simplement là où ils se trouvent. J'ai choisi cela, mais je vais devoir traiter le 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 sur la base des commentaires, il n'est certainement pas nécessaire maintenant. Veuillez consulter les commentaires ci-dessous.

1. Ensuite, dans votre configuration de build TeamCity, ajoutez un Paramenter de build 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

Lorsque vous construisez sur le serveur build / CI, désactivez complètement l'importation Microsoft.WebApplication.targetsen spécifiant /p:VSToolsPath=''. Cela rendra essentiellement la condition de la ligne suivante fausse:

<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

Voici comment cela se fait dans TeamCity:

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

Source de la solution

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 comme suit:

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 pour qu'elle ressemble à ceci

<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/

C'est tout ce dont vous avez besoin. Seulement 103 Mo. N'installez pas tout

J'ai trouvé cela sur MS connect :

Oui, vous devez installer Visual Studio 2010 sur votre machine de génération pour créer des projets de base de données. Cela ne nécessite pas de licence supplémentaire de Visual Studio.

Donc, c'est la seule option que j'ai pour l'instant.

Ma solution est un mélange de plusieurs réponses ici.

J'ai vérifié le serveur de build 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) se développe en C: \ Program Files \ MSBuild qui n'a pas le chemin.

Par conséquent, j'ai créé un lien symbolique à l'aide de cette commande:

mklink / J "C: \ Program Files \ MSBuild \ Microsoft \ VisualStudio" "C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio"

De cette façon, $ (MSBuildExtensionsPath) se développe en un chemin valide, et aucune modification n'est nécessaire dans l'application elle-même, uniquement dans le serveur de build (peut-être que l'on pourrait créer le lien symbolique à chaque build, pour s'assurer que cette étape n'est pas perdue et est "documentée" ").

Je fixe 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

J'ai essayé un tas de solutions, mais à la fin 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, pour rendre les scripts plus faciles à coder.

Quiconque vient ici pour Visual Studio 2017. J'ai eu le même problème et je n'ai pas pu 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 v14.0dossier C:\Program Files (x86)\MSBuild\Microsoft\VisualStudiodans le même dossier que v15.0et cela a résolu toutes les erreurs. Alors maintenant, ma structure de dossiers ressemble à ci-dessous, où les deux dossiers contiennent le même contenu.

Si vous utilisez MSBuild, comme dans le cas d'un serveur de build, ce qui a fonctionné pour moi est:

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 cela aide quelqu'un.

Si vous essayez de déployer un projet à l'aide de VSTS, le problème peut être lié à la vérification de l'option "Hosted Windows Container" au lieu de "Hosted VS2017" (ou 18, etc.):

• Après l'installation des outils MSBuild de Microsoft, définissez le chemin MSBuild dans la variable d'environnement, afin qu'il puisse être exécuté à partir de n'importe quel chemin.
• Modifiez le fichier .csproj dans n'importe quel éditeur de bloc-notes tel que notepad ++ et commentez le
• Vérifiez les éléments suivants, ->
  • Assurez-vous de n'utiliser l'importation qu'une seule fois, choisissez celle qui fonctionne.
  • Assurez-vous que le dossier suivant existe sur le lecteur, «C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0» ou selon la version référencée par la cible MSBuild dans «C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v14.0 \ WebApplications \ Microsoft.WebApplication.targets "
  • À partir de l'invite de commandes, exécutez la commande suivante pour vérifier

C:> msbuild "C: \\ DotnetCi.sln" / p: Configuration = Release / p: UseWPP_CopyWebApplication = true / p: PipelineDependsOnBuild = false

• choisissez le commutateur / p selon le cas, référez-vous à entrer la description du lien ici entrez la description de l'image ici

J'avais ce problème lors de la construction d'un projet SQL Server sur un pipeline CI / CD. En fait, je l'avais aussi sur place et je n'ai pas réussi à le résoudre.

Ce qui a fonctionné pour moi, c'était d'utiliser un SDK MSBuild , capable de produire un package d'application de niveau données SQL Server ( .dacpac) à partir d'un ensemble de scripts SQL, ce qui implique la création d'un nouveau projet. Mais je voulais conserver le projet SQL Server, afin de pouvoir le lier à la base de données en direct via SQL Server Object Explorer sur Visual Studio. J'ai pris les mesures suivantes pour que cela soit opérationnel:

1. J'ai conservé mon projet SQL Server avec le .sql scripts de base de données.
2. A créé un projet de bibliothèque de classes .NET Standard 2.0, en s'assurant que le cadre cible était .NET Standard 2.0, conformément aux instructions du lien ci-dessus.

3. Définissez le contenu de la .csprojmanière suivante:

   <?xml version="1.0" encoding="utf-8"?>
   <Project Sdk="MSBuild.Sdk.SqlProj/1.0.0">
     <PropertyGroup>
       <SqlServerVersion>Sql140</SqlServerVersion>
       <TargetFramework>netstandard2.0</TargetFramework>
     </PropertyGroup>
   </Project>

4. J'ai choisi SQL140 comme version de SQL Server car j'utilise SQL Server 2019. Vérifiez cette réponse pour connaître le mappage avec la version que vous utilisez.

5. Ignorez le projet SQL Server lors de la génération, afin qu'il cesse de se rompre localement (il s'appuie sur Visual Studio, mais il échoue sur VS Code).

6. Il ne nous reste plus qu'à nous assurer que les .sqlfichiers sont à l'intérieur du projet SDK lors de sa construction. J'ai atteint cet objectif avec une routine PowerShell simple sur le pipeline CI / CD qui copiera les fichiers du projet SQL Server dans le projet SDK:

Copy-Item -Path "Path.To.The.Database.Project \ dbo \ Tables \ *" -Destination (New-item -Name "dbo \ Tables" -Type Directory -Path "Path.To.The.DatabaseSDK.Project \ ")

PS: Les fichiers doivent être physiquement dans le projet SDK, à la racine ou dans un dossier, donc les liens vers les .sdkfichiers dans le projet SQL Server ne fonctionneront pas. En théorie, il devrait être possible de copier ces fichiers avec une condition de pré-génération, mais pour une raison obscure, cela ne fonctionnait pas pour moi. J'ai également essayé d'avoir les .sqlfichiers sur le projet SDK et de les lier au projet SQL Server, mais cela romprait facilement le lien avec l'Explorateur d'objets SQL Server, j'ai donc décidé de supprimer cela également.