build dotnet vs publication sur Azure DevOps
J'ai une application console .NET Core 2.0. Je peux créer ou publier cette application avec succès et l'exécuter localement. Je peux également créer et publier avec succès cette application dans Azure DevOps. Cependant, si je build l'application dans Azure DevOps, je ne peux pas exécuter le résultat.
Dans Azure DevOps, j'ai essayé de créer en utilisant:
dotnet build -c Release -r win-x64 -o app
Cela génère un petit nombre de fichiers avec uniquement les fichiers liés au projet. Il n'inclut pas tous les fichiers System. *. Dll, etc. qui semblent excessifs pour la plupart de mes cas. Cette commande fonctionne correctement lorsque je l'exécute sur ma machine locale et que je peux cliquer avec succès sur le fichier MyApp.exe et exécuter mon application console. Cependant, si j'exécute la même commande sur Azure DevOps, le fichier MyApp.exe qui est généré ne s'exécute pas comme prévu. Au lieu de cela, il démarre puis se ferme immédiatement. Rien n'est imprimé dans l'application console. Je ne vois aucune erreur. L'application est très basique, comprend un "try-catch" autour de tout et a un Console.ReadLine à la fin. Donc, je pensais que ça resterait ouvert.
Quand je cours:
dotnet publish -c Release -r win-x64 -o app
J'obtiens les mêmes fichiers, mais avec tous les fichiers System. *. Dll, etc. inclus. Cette fois, j'ai remarqué que je pouvais exécuter MyApp.exe avec succès et qu'il se comportait comme prévu.
Pourquoi dotnet build ... travaille localement, mais je ne semble pas avoir le même comportement lorsque j'exécute dotnet build ... dans Azure DevOps. Il semble que je suis obligé d'utiliser dotnet publish. Mon problème est que le fichier .Zip résultant passe de ~ 500 Ko à 30 Mo. C'est une grande différence.
Une réponse de la bouche du cheval:
La commande dotnet build construit le projet et ses dépendances dans un ensemble de binaires. Les fichiers binaires incluent le code du projet dans des fichiers IL (Intermediate Language) avec une extension .dll et des fichiers de symboles utilisés pour le débogage avec une extension .pdb. Un fichier JSON de dépendances (* .deps.json) est produit qui répertorie les dépendances de l'application. Un fichier * .runtimeconfig.json est généré, qui spécifie le runtime partagé et sa version pour l'application.
Si le projet a des dépendances tierces, telles que des bibliothèques de NuGet, elles sont résolues à partir du cache NuGet et ne sont pas disponibles avec la sortie intégrée du projet. Dans cet esprit, le produit de la construction dotnet n'est pas prêt à être transféré sur une autre machine pour s'exécuter.
dotnet build - Construit un projet et toutes ses dépendances.
dotnet publish - Emballe l'application et ses dépendances dans un dossier pour le déploiement sur un système d'hébergement. (PS - cela crée également l'application avant l'emballage)
La description est en fait très bonne étant donné qu'elle provient directement de Microsoft, je ne vais donc pas reproduire les mots ici.
Comme exercice, créez une solution avec plusieurs projets. Pour l'un des projets, ajoutez une référence à un autre projet. Ajoutez des fichiers statiques auxquels votre code fait référence et quelques packages NuGet. Et exécutez ces commandes au niveau racine de la solution et au niveau du projet et observez la sortie dans le dossier bin.
Commandes à exécuter: dotnet builddotnet publish
dotnet clean pour nettoyer le dossier bin
Exécutez également ceci au niveau racine et observez la sortie avec l'indicateur autonome activé:
dotnet publish -o ./output --runtime win10-x64 --self-contained
La différence entre eux est que:
Pour la publication, les fichiers d'assembly (packages) nécessaires seront inclus dans le dossier actuel et l'application utilise ces assemblys.
Mais pour la construction, l'application fait référence aux packages qui se trouvent dans le dossier de l'utilisateur, c'est pourquoi le fichier Zip ne fait que 500 ko.
Comme il fait référence aux packages qui se trouvent dans le dossier de l'utilisateur, l'application doit donc être créée sous le même compte d'utilisateur, vous pouvez alors exécuter l'application sans la publier. Par conséquent, vous devez remplacer le compte de service de l'agent de génération par votre compte (connectez-vous en tant que), puis redémarrez le service et mettez en file d'attente une nouvelle génération.
Sinon, vous devez publier l'application.