AcumatiCares
Introduction
Dans ce billet, nous allons explorer la manipulation de fichiers XML. Notre principal cas d'utilisation sera d'automatiser la compilation d'une bibliothèque d'extensions pour différentes versions d'Acumatica. Nous nous appuierons sur la première partie pour créer un script qui vous permettra de parcourir automatiquement plusieurs versions cibles d'Acumatica et de compiler automatiquement les fichiers .dll à l'aide de l'outil de ligne de commande MSBuild.
Travailler avec des fichiers XML et la ligne de commande MSBuild
Commençons par installer les versions cibles d'Acumatica. Ce qui serait vraiment génial, c'est d'avoir un script automatisé qui ferait cela pour vous. Pour l'instant, nous allons procéder étape par étape et faire cette partie manuellement. Dans une prochaine partie de cette série, je prévois de couvrir certaines dynamiques qui vous permettront d'installer automatiquement une nouvelle instance d'Acumatica avec des données de démonstration ou un snapshot cible. Pour l'instant, je souhaite me concentrer sur les aspects de la manipulation du XML. Comme vous le savez peut-être déjà, vous pouvez obtenir n'importe quelle version d'Acumatica à l'adresse 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 je 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 connote l'objet de l'instance, puis les versions Acumatica. Dans ce cas, j'ai utilisé PSH comme version courte de PowerShell.
Très bien, maintenant que nous avons plusieurs instances d'Acumatica installées et prêtes pour la prochaine étape, discutons de notre objectif. Ce que nous voulons, c'est apporter des modifications itératives au fichier .csprog. csproj n'est évidemment pas une extension XML, mais si vous inspectez le fichier dans le bloc-notes, vous verrez qu'il s'agit bien d'un fichier XML. Ce fichier contient des informations de configuration sur le projet et sur 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. La façon la plus simple d'identifier ces éléments est d'effectuer les changements manuellement, puis d'inspecter le fichier et de rechercher les deltas. Je vais faire une copie de ce fichier. Ensuite, j'effectuerai les modifications manuellement et, enfin, j'utiliserai un CMDLET PowerShell appelé Compare-Objects pour rechercher ce qui a changé.
J'aime utiliser des balises de compilation conditionnelle, en particulier lorsque le code de base d'Acumatica 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 déclarations pragma pour indiquer au compilateur la version du code que vous souhaitez utiliser. Ceci est utile car vous pouvez maintenir toutes les versions d'Acumatica dans une seule branche de contrôle de source. Une autre façon très utile d'utiliser la compilation conditionnelle est d'ajouter du code de débogage et de conserver ce code de débogage. Vous pouvez demander 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 allons nous en tenir à ce que nous cherchons à accomplir. Dans la plupart des cas, j'ai besoin de définir ces symboles lorsque j'effectue des compilations pour différentes versions.
Une dernière information que j'aime mettre en place 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 et utiliser quelque chose d'unique pour le dernier numéro, comme un mois et un jour. Cela permet d'intégrer des informations temporelles qui sont utiles pour avoir une idée de la date à laquelle le fichier .dll a été créé. Croyez-moi, il est très utile de savoir quand un fichier .dll a été créé. Un autre avantage de cette pratique est qu'elle permet de confirmer que la construction souhaitée arrive bien à destination dans le cadre d'un test d'intégration. Je suis sûr qu'un certain nombre d'entre vous ont déjà rencontré le problème suivant : vous allez déployer un paquetage et vos modifications ne sont pas prises en compte. Après avoir passé beaucoup de temps à résoudre le problème, vous vous rendez compte que les mises à jour que vous venez de faire n'ont jamais été intégrées dans un paquet. Si vous prenez l'habitude de toujours mettre à jour cette valeur et d'écrire un script de test pour vous assurer qu'elle arrive à sa destination finale, vous gagnerez du temps. Vous gagnerez du temps en évitant les problèmes de régression.
Enregistrez vos modifications, puis exécutez cette commande PowerShell :
Vous obtiendrez les éléments qui ont été modifiés dans le fichier :
Il existe des outils plus élégants pour atteindre le même objectif, comme Beyond compare. Mais cela nécessite une installation, et Compare-Objects sera toujours disponible si vous en avez besoin. C'est un autre avantage d'avoir l'invite PowerShell à portée de main.
Maintenant que nous savons quels éléments nous devons modifier, voyons comment le faire en utilisant les outils XML disponibles dans PowerShell. Ce que nous allons exploiter est en fait un espace de noms XML .NET, par opposition à un CMDLET PowerShell dédié. Il y a donc de fortes chances que si vous êtes un développeur .NET, vous puissiez lire et comprendre ceci sans trop d'explications. La façon dont nous accédons au XML est la suivante. Il suffit de convertir le contenu du fichier en un objet XML. La principale différence est que C# utilise des parenthèses fermantes (xml) pour votre objet, et PowerShell utilise des crochets [xml]. Le reste est identique à ce que vous feriez en C#.
Maintenant que nous disposons d'un script qui mettra automatiquement à jour les fichiers du projet, nous pouvons nous pencher sur la construction automatique et la compilation de la bibliothèque d'extension. Pour ce faire, nous utiliserons la ligne de commande MSBuild.exe. Nous pouvons le faire avec le script PowerShell suivant.
Il est possible de charger les résultats du processus de construction dans une variable et de les examiner à la recherche d'indicateurs qui nous permettraient de savoir si les choses ont mal tourné. Ainsi, nous pourrions ajouter ce qui suit au script pour demander à l'utilisateur de construire manuellement le paquet s'il échoue. J'ai en fait utilisé cette méthode pendant une courte période, car le fait de pointer vers l'emplacement C:\NWindows\NMicrosoft.NET\NFramework\Nv4.0.30319\NMSBuild.exe de MSBuild.exe entraînait des erreurs. Nous nous sommes donc retrouvés avec un script qui n'était pas parfait mais qui automatisait tout de même une bonne partie du travail. C'est la puissance de la possibilité 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 découvert que nous n'obtenions pas l'erreur si nous utilisions l'exécutable trouvé dans ce chemin C:\NProgram Files\NMicrosoft Visual Studio\2022\NProfessional\NMSBuild\NCurrent\NBin\Namd64\NMSBuild.exe
Et tout est rentré dans l'ordre. 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 déroulent comme prévu. Le rouge est une couleur idéale pour vous indiquer que les choses se sont mal passées. C'est une information que vous pouvez traiter beaucoup plus rapidement qu'en lisant les résultats.
L'étape suivante consiste à mettre les choses dans des fonctions afin qu'il soit plus facile de les appeler à partir d'une boucle. Nous avons donc les fonctions suivantes.
Nous utiliserons le travail que nous avons fait pour mettre à jour le fichier VS Project comme suit
Nous apporterons également notre script de la première partie et nous pourrons enfin combiner toutes ces étapes en une seule :
Nous pouvons maintenant construire une boucle avec le script suivant. Nous pouvons exécuter tout cela dans un seul fichier de script, ou vous pouvez diviser vos fonctions dans des fichiers séparés. Cette dernière solution est la plus idéale, mais la première permet de tout regrouper dans un seul fichier pour faciliter la lecture. Si vous séparez les fichiers, utilisez l'appel Import-Module {Chemin du script}.
Avec les scripts, vous déclarez généralement vos variables en haut de la page. Ce sont ces variables qui devront être modifiées lorsque vous compilerez différents projets et pointerez vers différentes versions. Les quatre premières variables sont des variables communes qui seront utilisées à chaque itération. La cinquième variable , $BuildConfigArray, est l'information qui changera à chaque itération.
Tout le code ci-dessus se trouve dans la GIST publique ici :
https://gist.github.com/RobertWaite/0a1cbc8408a1b3a30017fbf3f80094e6
Prochaines étapes
Vous avez peut-être remarqué que nous avons mis un interrupteur pour demander ou non à l'utilisateur d'extraire le fichier Package.zip d'Acumatica. Dans la partie 3, nous allons explorer l'automatisation de cette opération afin d'éviter cette étape manuelle. C'est la beauté de la cmdlet Read-Host. Vous pouvez automatiser de manière itérative des éléments distincts au fil du temps. Il n'est pas nécessaire de tout automatiser en même temps.
Résumé
Nous avons beaucoup appris dans cette partie, et il n'est pas difficile d'imaginer le temps que nous avons gagné 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é MSBuild.exe.
Pour lire la première partie de Useful PowerShell Tidbits to Help Save You Time Every Day, cliquez ici : /blog/useful-powershell-tidbits-part-1/
Bon codage !
