Microsoft.WebApplication.targets est introuvable sur le serveur de génération. Quelle est votre solution?

410

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.

gerbeur
la source
1
Les projets d'application Web sont-ils obsolètes? Je me demande quelle est la raison d'être des anciennes versions de Visual Studio pour les construire?
brianary
1
Plus précisément, déployez-vous réellement via le serveur de build? par exemple, je n'ai pas, j'ai même un projet d'installation web séparé dans la solution ... et il veut toujours cette chose sanglante ... answer = supprimez-le du fichier proj! facile.
Paul Zahra
1
Corrigé en remplaçant <Import Project="..\Packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" />le chemin par $(VSToolsPath):<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" />
GJ

Réponses:

207

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.

Chris S
la source
11
Cela a fonctionné pour m2 avec un projet VS2012, après avoir remplacé la v10.0 à la v11.0
DenNukem
2
ne pouvons-nous pas simplement installer les outils MSBuild au lieu de cela? microsoft.com/en-us/download/confirmation.aspx?id=40760
user20358
1
Hélas, l'installation des outils MSBuild ne suffit pas pour créer des projets qui se compilent bien dans VisualStudio 2013
Michael Shaw
J'ai dû copier le dossier Web vers la version 11.0 pour le faire fonctionner après l'installation de VS2013, il y manquait. Pourrait compiler dans VS mais pas via MSBUILD directement.
Martin Braun du
9
travaillé pour VS2017. il suffit de copier C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ vXX.0 \ WebApplications vers C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v15.0 \ WebApplications
jokab
95

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.

Sayed Ibrahim Hashimi
la source
4
Sayed - voir la réponse ci-dessous de dansomething - votre réponse est-elle correcte? Même l'installation du package intégré VS 2010 Shell et du SDK .NET n'installera pas correctement la prise en charge du projet d'application Web?
Adam
@SayedIbrahimHashimi devez-vous enregistrer les DLL auprès du GAC si vous effectuez une copie manuelle du dossier?
TheOptimusPrimus
Et qu'en est-il des Microsoft.TextTemplating.targets? Que dois-je faire pour les mettre dans leur dossier? C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0
Developer
@ClarkKent, désolé, je ne peux pas parler du fichier TextTemplating. Je ne les connais pas.
Sayed Ibrahim Hashimi
77

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.

Andriy K
la source
Cette solution a fonctionné pour moi et était vraiment la meilleure option dans mon cas. C'est parce que je n'ai pas accès au serveur de build. J'utilise le bambou élastique d'Atlassian qui fait tourner un nouveau serveur pour agir comme serveur de build. Il ne semble pas à première vue que ces AMI incluent les cibles d'application Web ?? Cela n'a pas de sens pour moi, mais c'est comme ça.
Cody Clark du
1
C'est une bonne approche, mais cette modification nécessite que chaque fichier csproj soit modifié. C'est difficile si vous ajoutez de nouveaux projets à la solution. Bien sûr, cela peut être résolu avec des modèles de projet personnalisés, mais quand même .. Quoi qu'il en soit, cette réponse m'a indiqué la bonne direction. Merci!
100r
76

À 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: entrez la description de l'image ici

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

SOReader
la source
2
Je suis assez surpris que mon enfant de cinq ans à propos de l'intégration de libs dans le contrôle de code source, et que ses modifications obtiennent encore des votes, même aujourd'hui, alors que c'est la réponse prête à l'emploi.
Andriy K
2
@AndriyK Votre solution est un peu différente de ce que j'ai suggéré et je comprends pourquoi quelqu'un pourrait préférer la vôtre à la mienne ... à moins que ce soit juste de la paresse; D
SOReader
2
Pour rendre cela plus général, pour les futures versions de Visual Studio, vous pouvez télécharger les derniers outils de build à partir de visualstudio.microsoft.com/downloads Faites défiler la page et vers le bas développez la section "Outils pour Visual Studio", puis téléchargez le " Build Tools for Visual Studio ". Actuellement, ce sont pour VS 2017 mais je suppose que ce sera la même chose pour les futures versions. Par ailleurs, si vous avez besoin du chemin d'accès à msbuild.exe pour votre outil CI (par exemple Jenkins), pour VS 2017, il sera installé dans C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ BuildTools \ MSBuild \ 15.0 \ Bin \ msbuild.exe.
Simon Tewsi
2
La façon de le faire compatible avec build-server (lire: ligne de commande) est choco install visualstudio2017-workload-webbuildtools.
Paul Hicks
1
Notez également que le paquet « outils de construction de développement Web » , Microsoft.VisualStudio.Workload.WebBuildToolspeut être installé via la ligne de commande en appelant vs_BuildTools.exe --add Microsoft.VisualStudio.Workload.WebBuildTools. Ajoutez --passiveà ne pas avoir besoin de l'intervention de l'utilisateur.
Wai Ha Lee
70

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.

Lloyd Holman
la source
2
Il est impossible à utiliser car je dois d'abord ouvrir la solution mais je ne peux pas à cause de l'erreur.
Développeur
S'il y a plus d'un projet dans la solution, vous devriez toujours pouvoir 1. ouvrir la solution - ignorer que le projet Web ne se charge pas; 2. ajoutez la référence du nuget; 3. adopter l'une des approches mentionnées par la suite; vous pouvez modifier manuellement le fichier de projet ou remplacer la variable env.VSToolsPath dans TeamCity.
Damon
1
S'agit-il d'un package MS nuget officiellement publié, ou quelqu'un vient-il de le créer?
Simon_Weaver
merveilleuse solution - fonctionne pour différentes versions de VS. J'avais besoin d'éditer le fichier .csproj, YMMV
Jonno
39
Ce n'est pas un package de pépites Microsoft officiellement publié. Je le sais parce que je l'ai créé.
mak
54

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.

Matthew Skelton
la source
7
C'est la solution la plus simple et la plus simple de l'OMI. J'utilise VS 2013 et j'ai trouvé que le redistribuable Visual Studio 2013 Shell (isolé) était ce qui fonctionnait (celui intégré ne serait pas installé en raison de la dépendance à celui isolé).
Matt Miller,
@MatthewSkelton - Quelle est la signification de build server ?
Mohammed Zameer
2
@BountyMan - un serveur de build est un serveur qui entreprend ou contrôle les builds d'intégration continue (CI) du logiciel. Exemples: Jenkins, TeamCity, CruiseControl, etc.
Matthew Skelton
3
Malheureusement avec VS v14.0, la façon d'installer le package est via nuget mais comme mon problème était que le serveur de build n'avait pas VS installé (uniquement MSBuild), l'installation du package s'est avérée presque impossible. J'ai passé des heures à tâtonner avec PowerShell et diverses installations à moitié sauvegardées de Nuget avant de simplement copier le dossier de mon PC vers le serveur.
pasx
1
@pasx Si le message d'erreur contient "v14", vous pouvez installer Visual Studio 2015 Isolated Shell à la place, travaillé pour moi - visualstudioextensibility.com/downloads/vs-shells (sous "Télécharger les URL"; il y a une enquête obligatoire, profitez-en!)
Dunc
38

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.

quelque chose
la source
FYI - Si vous essayez de construire des projets Sql sur un serveur de build sans installer VS à part entière, vous n'avez pas de chance avec le programme d'installation GDR R2 de Team System 2008 Database Edition mentionné ici. Ses prérequis sont Visual Studio Team System 2008 Database Edition SP1 (anglais) ou Visual Studio Team System 2008 Suite SP1 (anglais) ET Visual Studio 2008 Service Pack 1. Il semble cependant que vous pouvez copier SqlServer.targets à partir de .NET Framework \ Le répertoire v4 et TeamData msbuild ciblent les fichiers à partir de \ program files \ msbuild \ microsoft \ visual studio \ v10.0 \ et vos csprojs seront créés.
Ethan J. Brown
Ce n'est certainement pas la plus jolie solution, mais pour moi le temps est le plus important. La simple copie sur le répertoire MSBuild ne fait que générer plus de problèmes pour moi.
21
C'est une réponse très importante car si vous êtes un développeur indépendant qui configure un serveur de build pour un client, vous ne voulez pas que le client doive maintenir une licence Visual Studio pour pouvoir construire son logiciel.
thelsdj
Je n'avais besoin que du package intégré au shell VS2010 et d'EntLib 5 pour obtenir le mien à construire. N'avait pas besoin de Team System.
Robin Winslow
1
Le shell VS 2010 n'est plus disponible sur ce lien, "La ressource que vous recherchez a été supprimée, son nom a changé ou est temporairement indisponible.".
kristianp
22

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
Damon
la source
8
pas besoin de faire l'étape 4, si vous remplacez simplement l'élément <Import> dans votre fichier de projet par celui-ci:<Import Project="..\..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.12.0.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" />
knocte
Cela devrait être la réponse acceptée ... et le point 4 devrait être supprimé.
Izzy
@Izzy merci, avez-vous fait le commentaire comme indiqué par knocte à la place? Je n'ai pas utilisé TC depuis quelques années, la version 7 iirc.
Damon
@Damon J'utilise Jenkins et non TC, donc c'est peut-être pourquoi je n'ai pas eu besoin de votre dernier point.
Izzy
21

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:

entrez la description de l'image ici

Alex R.
la source
Les cibles de génération sont nécessaires si vous utilisez le mécanisme "Publier" de Visual Studio. Cela permet à la compilation de se poursuivre et de se terminer, mais elle peut être incomplète.
starlocke
14

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

Korayem
la source
4
L'ajout de /p:VisualStudioVersion=12.0 aux arguments MSBuild dans la définition de build TFS 2013 (pour une solution créée dans Visual Studio 2013) a fonctionné pour moi. Pour une raison quelconque, il rechercherait des fichiers dans un dossier v11.0 sans aucun paramètre.
Sacha K
3
Cette solution a fonctionné pour moi, j'ai utilisé cette commande:msbuild /p:Platform=x86 /p:VisualStudioVersion=12.0
E.Meir
9

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/

Huy Truong
la source
8

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

entrez la description de l'image ici

Simon_Weaver
la source
Comment puis-je mettre une coche sur ce formulaire, sans rien installer?
Christian
5

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.

gerbeur
la source
2
Le lien semble rompu.
Désillusionné le
2

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" ").

Kat Lim Ruiz
la source
2

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

MonoThreaded
la source
2

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.

Hendrikswan
la source
2

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.

entrez la description de l'image ici

Habib
la source
2

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.

Colin Q
la source
pour mentionner, les modifications doivent être apportées aux fichiers .csproj, vbproj incriminés.
Colin Q
0

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.):

entrez la description de l'image ici

Arsen Khachaturyan
la source
0
  • 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

Pankaj Awasthi
la source
0

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.

ccoutinho
la source