AcumatiCares
Introduction
Dans cet article, nous allons explorer la manipulation de fichiers XML. Notre principal cas d’utilisation va être d’automatiser la compilation d’une bibliothèque d’extension à différentes versions d’Acumatica. Nous allons construire à partir de la première partie et de venir avec un script qui vous permettra de boucler automatiquement à travers plusieurs versions cibles d’Acumatica, puis de construire automatiquement les fichiers .dll à l’aide de l’outil de ligne de commande MSBuild .
Utilisation de fichiers XML et de la ligne de commande MSBuild
Commençons par installer les versions cibles d’Acumatica. Ce qui serait vraiment lisse, c’est d’avoir un script automatisé qui le fera pour vous. Pour l’instant, nous allons le prendre une étape à la fois et faire cette partie manuellement. Je fais partie future de cette série, je prévois de couvrir certaines dynamiques qui vous permettront d’installer automatiquement une nouvelle instance nette d’Acumatica avec des données de démonstration ou un instantané cible. Donc, pour l’instant, je veux juste me concentrer sur les aspects de la manipulation XML. Comme vous le savez peut-être déjà, vous pouvez obtenir n’importe quelle version d’Acumatica à https://Builds.Acumatica.com j’ai téléchargé et installé les versions les plus récentes de chacune des dernières versions majeures d’Acumatica et les ai installées en utilisant les noms suivants. PSH21_128_0009, PSH21_221_0019, PSH22_117_0016, PSH22_207_0013. J’aime généralement utiliser un préfixe de trois lettres qui connotera à quoi sert l’instance, puis les versions acumatica. Dans ce cas, j’ai utilisé PSH comme une version courte de PowerShell.
D’accord, alors maintenant que nous avons plusieurs instances d’Acumatica installées et prêtes pour cette prochaine étape, discutons de notre objectif. Ce que nous recherchons, c’est d’apporter de manière itérative des modifications au fichier .csprog. csproj n’est évidemment pas une extension XML, mais si vous inspectez le fichier dans le bloc-notes, vous verrez en effet qu’il s’agit de XML. Ce fichier contient des informations de configuration sur le projet et l’endroit où il va envoyer le fichier .dll, parmi de nombreux autres paramètres de configuration utilisés pour le projet. Essayons d’identifier les éléments que nous devons mettre à jour. Le moyen le plus simple d’aider à identifier ces éléments est d’apporter les modifications manuellement, puis d’inspecter le fichier et de rechercher les deltas. Je vais faire une copie de ce fichier. Ensuite, je vais apporter manuellement les modifications, puis enfin, j’utiliserai une CMDLET PowerShell appelée Compare-Objects pour étudier ce qui a changé.
J’aime utiliser des balises de compilation conditionnelles, en particulier lorsque le code Acumatica de base a changé d’une manière qui nécessite une version différente du code pour différentes versions d’Acumatica. Vous pouvez utiliser des instructions pragma pour indiquer au compilateur quelle version du code vous souhaitez utiliser. Ceci est utile car vous pouvez gérer toutes les versions d’Acumatica dans une seule branche de contrôle de code source. Une autre façon super utile d’utiliser la compilation conditionnelle est si vous souhaitez ajouter du code de débogage et que vous souhaitez conserver ce code de débogage. Vous pouvez dire au compilateur d’ignorer complètement tout code de débogage dans la version de production. C’est un sujet que j’ai l’intention de développer à l’avenir, mais pour l’instant, nous nous en tiendrons à ce que nous cherchons à accomplir. Dans la plupart de mes cas, j’ai besoin de définir ces symboles chaque fois que je fais des builds pour différentes versions.
Une dernière information que j’aime définir est le numéro de build. C’est une de mes bêtes noires de voir des numéros de build comme 1.0.0.0 dans cette configuration. J’aime généralement faire correspondre le numéro de build D’Acumaticas, puis utiliser quelque chose d’unique pour le dernier numéro, comme un mois et un jour. Cela intègre des informations temporelles qui sont utiles pour avoir une idée du moment où le .dll a été construit. Croyez-moi, c’est une information pratique pour savoir quand un .dll est construit. Un autre avantage de cette pratique est que vous pouvez confirmer que la construction souhaitée arrive réellement à destination dans un test d’intégration. Je suis sûr qu’un groupe d’entre vous a rencontré le problème où vous allez déployer un package, et vos modifications ne se mettent pas en place. Après avoir enfilé un tas de temps de dépannage en vous, réalisez que les mises à jour que vous venez de faire n’ont jamais fait dans un paquet. Si vous prenez l’habitude de toujours mettre à jour cette valeur avec l’écriture d’un script de test pour affirmer qu’il arrive à sa destination finale. Vous finirez par gagner du temps car vous éviterez les problèmes de régression en premier lieu.
Enregistrez vos modifications, puis exécutez cette commande PowerShell :
Vous obtiendrez les éléments qui ont changé dans le fichier en conséquence:
Il existe des outils plus élégants pour atteindre le même objectif, tels que Beyond compare. Mais cela nécessite une installation, et Compare-Objects sera toujours facilement disponible si vous en avez besoin. Juste un autre avantage d’avoir l’invite PowerShell à proximité.
Maintenant que nous savons quels éléments nous devons modifier, voyons comment le faire à l’aide des outils XML disponibles dans PowerShell. Ce que nous allons exploiter est en fait un espace de noms XML .NET par opposition à un Applet de commande PowerShell dédié. Il y a donc de fortes chances que si vous êtes un développeur .NET, vous puissiez lire et comprendre cela avec peu d’explications. La façon dont nous accédons au XML est la suivante. Il suffit de lancer le contenu du fichier dans un objet XML. La principale différence est que C# utilise la parenthèse fermante (xml) pour votre objet, et PowerShell utilise des crochets [xml]. Le reste est identique à ce que vous feriez avec C #.
Maintenant que nous avons un script qui mettra automatiquement à jour les fichiers de projet, nous pouvons maintenant examiner la création automatique et la compilation de la bibliothèque d’extensions. Pour ce faire, nous utiliserons l’invite de ligne de commande MSBuild.exe. Nous pouvons le faire avec le script PowerShell suivant.
Une chose vraiment intéressante que nous pouvons faire est que nous pouvons charger les résultats du processus de construction dans une variable et les examiner pour tous les indicateurs qui nous permettraient de savoir si les choses ont mal tourné. Nous pourrions donc ajouter ce qui suit au script pour inviter un utilisateur à obtenir des instructions pour créer manuellement le package s’il échoue. J’ai en fait utilisé cela pendant une courte période de temps comme pointant vers le C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe emplacement du MSBuild.exe a entraîné des erreurs. Nous nous sommes donc retrouvés avec un script qui n’était pas parfait mais qui automatise tout de même une bonne partie du travail. C’est la puissance d’être capable de charger les résultats dans une variable et de vérifier les indicateurs de succès ou d’échec. L’invite Read-Host pour appeler à un processus manuel est encore une fois une autre dynamique utile pour semi-automatiser votre processus.
Finalement, nous avons compris que nous n’obtenons pas l’erreur si nous utilisons l’exécutable trouvé sur ce chemin C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin\amd64\MSBuild.exe
Et puis tout allait bien avec le monde. Un autre élément remarquable est l’utilisation de Write-Host avec le paramètre -Foreground Color. C’est un excellent moyen de vous donner un retour visuel rapide si les choses se passent comme prévu. Le rouge est une excellente couleur à utiliser pour vous faire savoir que les choses ont mal tourné. Ce sont des informations que vous pouvez traiter beaucoup plus rapidement que la lecture des résultats.
L’étape suivante consiste à mettre les choses dans les fonctions afin qu’il soit plus facile d’appeler ce genre de choses à partir d’une boucle. Nous avons donc les fonctions suivantes.
Nous utiliserons le travail que nous avons fait pour mettre à jour le fichier du projet VS en tant que
Nous apporterons également notre script de la partie 1 et nous pouvons enfin combiner toutes ces étapes en une seule:
Maintenant, nous pouvons construire une boucle avec le script suivant. Nous pourrions exécuter tout cela comme un seul fichier de script, ou vous pouvez diviser vos fonctions en fichiers séparés. Ce dernier est le plus idéal, mais le premier peut tout garder dans l’essentiel pour faciliter le traitement de la lecture. Si vous divisez les fichiers, vous utilisez l’appel Import-Module {Path Of Script}.
Avec les scripts, vous déclarez généralement vos variables en haut. Ce sont les variables qui devront changer au fur et à mesure que vous compilez différents projets et pointez vers différentes versions. Les 4 premières variables sont des variables courantes qui seront utilisées dans chaque itération. La cinquième variable $BuildConfigArray, est l’information qui changera à chaque itération.
Tout le code ci-dessus peut être trouvé ici dans le GIST public ici:
https://gist.github.com/RobertWaite/0a1cbc8408a1b3a30017fbf3f80094e6
Quelle est la prochaine étape
Vous avez peut-être remarqué que nous avons mis un commutateur pour savoir s’il faut ou non inviter un utilisateur à obtenir le package réel.zip fichier hors d’Acumatica. Dans la partie 3, nous allons également explorer l’automatisation de cela afin que nous n’ayons pas besoin de cette étape manuelle. C’est la beauté de l’applet de commande Read-Host. Vous pouvez automatiser de manière itérative des pièces distinctes au fil du temps. Vous n’avez pas besoin d’avoir tout automatisé en même temps.
Résumé
Nous avons beaucoup appris dans cette partie, et il n’est pas difficile d’imaginer combien de temps nous avons économisé en créant ce script. La modification du fichier de projet XML est un travail quotidien pour un développeur. Nous avons exploré comment charger et modifier ce fichier XML à l’aide de PowerShell. Nous avons également utilisé le .exe MSBuild.
Pour lire la partie 1 de Useful PowerShell Tidbits pour vous faire gagner du temps chaque jour, allez ici: /blog/useful-powershell-tidbits-part-1/
Bon codage!
