Je suis en difficulté pour obtenir Azure Devops Server 2019 (sur Prem) pour construire une configuration de projet compliquée de la mine.
J'ai plusieurs solutions qui construisent diverses applications biztalk. Certaines de ces solutions référent certains des projets dans d'autres solutions / repos. Cela fonctionne bien dans Visual Studio (fournissant à chacun des noms de leurs repos comme défaut, qu'ils font).
Pour automatiser cette version, j'ai créé un pipeline de construction multi-étages qui construit chaque solution dans l'ordre.
tandis que la solution 1 se développera avec succès, lorsqu'il s'agit de solution 2, les tâches MSBUILD ne feront pas référence les résultats des projets inclus en tant que référence de projet dans la solution.
Cela semble être parce que ces projets référencés ne sont pas marqués pour la construction - car ils ne seraient pas en mesure de se développer sans eux à leur tour, référencer leurs autres projets sur les principales solutions, etc.
BUNDLING Tout dans un seul fichier Super Solution n'est pas réalisable.
Je veux que Msbuild ait / référencer les projets qui ont déjà été construits à l'étape précédente, conformément aux références de projet. Mais Msbuild est une bête compliquée et je ne peux pas comprendre un moyen de réaliser cela.
est ce que j'essaie d'atteindre même possible? Quelqu'un peut-il me diriger dans la bonne direction?
3 Réponses :
TFS / MSBUILD, références de projet de construction
Ceci est un problème connu sur la référence du projet dans différents repos, mais malheureusement, il n'a pas de meilleure réponse. Parce que la meilleure solution est toujours d'avoir un seul référentiel.
GIT pense que les fichiers sont le contenu de l'ensemble du référentiel, pas comme une collection de fichiers. Par conséquent, cela est assez difficile à faire. Comme solution de contournement, vous pouvez envisager d'utiliser SubMODULES GIT ou Substrée GIT :
Vérifiez les informations des détails d'ici:
Références de projet GIT et Visual Studio
En outre, la solution que nous utilisons maintenant consiste maintenant à placer le code partagé dans Nuget paquet. Ensuite, vous pouvez utiliser le colis à partir de n'importe quel référentiel et vous n'avez pas à effectuer des paramètres git instables et à garder le contrôle d'accès car ils devraient être.
J'espère que cela aide.
Ce n'est pas un problème sur le contrôle de la source, mais construire. Le code source est tout tiré avec succès.
J'ai finalement revisité cela et j'ai fait une autre expérimentation.
Le seul moyen, que je puisse voir, pour obtenir TFS / MSBUILD sur / référencer d'autres sorties de projets consiste à les marquer dans la configuration de la solution de la solution pour la construction.
Maintenant, si vous faites cela dans Visual Studio et essayez de créer une solution à une autre solution, la construction échouera si la solution précédente n'a pas été entièrement construite (comme les autres dépendances chaînées n'auront pas été construit). Cela a du sens.
Mais avec TFS / MSBUILD, la construction réussira. D'après ce que je peux dire, il y a une magie qui assure que les dépendances de toutes les solutions sont résolues d'une manière ou d'une autre. Cela pourrait être de la chance, cela pourrait être un comportement spécifique (ça marche pour moi jusqu'à présent).
Le problème bien sûr est qu'il est incompatible avec Visual Studio. J'ai donc une configuration de définition «Build» supplémentaire dans chaque fichier de solutions disposant de tous les projets définis à la construction.
Cela semble le moyen le plus simple de gérer beaucoup de solutions interdépendantes sans en avoir un grand.
Il semble que Msbuild ait été modifiée pour uniquement faire référence à des références de projets de référence, et que vous pouvez revenir à ce que vous pouvez rétablir toutes les références en définissant la propriété Source: https://stackoverflow.com/a/25144169
ont confirmé ces travaux. onerreferenceandbuildprojectsSenAdSolutionConfiguration à true lors de l'exécution de Msbuild.
La solution dépend probablement de la configuration de votre contrôle source. Utilisez-vous GIT ou TFVC? Si vous utilisez GIT, est chaque application dans son propre référentiel ou existe-t-il un référentiel unique qui contient tout? Sur la base de vos commentaires sur "Fournir à tous les noms de tous les représentants de défaut", je suppose que vous utilisez GIT avec des repo individuels pour chaque application, mais pourriez-vous confirmer?
Je vérifie juste pour voir si les informations fournies étaient utiles. S'il vous plaît laissez-nous savoir si vous souhaitez une assistance supplémentaire.
Je n'ai pas de problème à obtenir le code source sur l'agent de construction. Comme cela se produit, j'utilise Git avec un super projet qui regroupe tous les projets. Cela fonctionne bien et la structure source complète est disponible pour l'agent de construction. Le problème est, selon ce qui précède, des solutions de construction qui ont des références de projet aux solutions voisines. Les fichiers sont tous là et résolus, mais Msbuild ne les renvoie pas.
Vous mentionnez des références de projet, mais vous parlez également de plusieurs solutions. Les références de projet ne sont valides que dans une solution unique. Utilisez-vous des références de chemin de fichier pour référencer la DLL de la solution 1 en solution 2?
En effet. J'ai plusieurs solutions, tous ont besoin de bâtir en séquence. Certains des projets de référence des solutions dans des solutions précédentes. Les références de projet sont relatives et valides. Si les projets sont chargés en VS sur le serveur de construction dans l'agent _work Directory, vous pouvez construire les projets très bien. L'endroit où je suis coincé est de savoir comment obtenir le pipeline Azure utiliser les mêmes arguments que vs le fait.
Référencez-vous un fichier de projet ou une DLL? Si sa DLL, vous ne pouvez pas utiliser la configuration par défaut car elle modifiera le chemin de sortie de la DLL en fonction de la configuration du projet. Vous construisez probablement dans le débogage localement et publiez sur l'agent de construction. Dans ce scénario, vous devez mettre à jour les projets à la sortie du même répertoire, quelle que soit la configuration. Ce n'est pas un problème lors de l'utilisation d'une référence de projet dans une seule solution, car Visual Studio prend en charge pour vous.
Ce sont des références de projet et non des références DLL. Tout est sur la même configuration de construction.
Pourriez-vous inclure votre fichier de projet? Quelle version de Visual Studio utilisez-vous? Personnellement, je n'étais pas au courant de la capacité de faire des références de projets de projet entre des solutions et que j'essaie de le faire avec l'exemple le plus élémentaire, cela ne fonctionne pas et cela devient une référence de fichier (Visual Studio 2017).
Bien sûr vous pouvez. Une solution n'est qu'un conteneur pour des projets. SOIT SOLUTION 1 a des projets A & B. Solution 2 possède des projets B & C. B ne peut pas être construit sans A, il est donc construit comme la construction de Solution 1. Nous devons ensuite créer une solution 2. tandis que le projet B est construit et répertorié dans la solution 2, il n'est pas marqué de construire (comme nous le savons déjà). Msbuild cependant, via TFS ne fera pas référence à la production du projet B avec les arguments générés / de référence. Ainsi, lorsque le projet C tente de construire, il ne peut pas trouver de symboles au projet B. Alors, comment pouvons-nous obtenir MSBuild pour référencer le projet B pendant la solution 2?
Je comprends parfaitement comment les références fonctionnent et il n'y a pas de magie ici. Msbuild fait simplement ce qui a été configuré dans le fichier de projet. J'ai essayé d'aider, mais si vous ne pouvez pas fournir de détails supplémentaires sur votre configuration de projet spécifique, il n'y a rien d'autre que je puisse faire pour aider.