AcumatiCares
Introducción
En este post, vamos a explorar la manipulación de archivos XML. Nuestro caso de uso principal va a ser automatizar la compilación de una biblioteca de extensión para diferentes versiones de Acumatica. Vamos a construir a partir de la primera parte y llegar a una secuencia de comandos que le permitirá automáticamente bucle a través de múltiples versiones de destino de Acumatica y luego construir automáticamente los archivos .dll utilizando la herramienta de línea de comandos MSBuild.
Trabajar con archivos XML y la línea de comandos MSBuild
Empecemos por instalar las versiones de destino de Acumatica. Lo que sería realmente ingenioso es tener algún script automatizado que haga esto por ti. Por ahora, iremos paso a paso y haremos esta parte manualmente. En una parte futura de esta serie, planeo cubrir algunas dinámicas que le permitirán instalar automáticamente una nueva instancia neta de Acumatica con datos de demostración o una instantánea de destino. Así que, por ahora, sólo quiero centrarme en los aspectos de la manipulación de XML. Como ya sabrás, puedes obtener cualquier build de Acumatica en https://Builds.Acumatica.com. He descargado e instalado los builds más recientes de cada una de las últimas versiones principales de Acumatica y los he instalado con los siguientes nombres. PSH21_128_0009, PSH21_221_0019, PSH22_117_0016, PSH22_207_0013. Generalmente me gusta usar un prefijo de tres letras que connote para qué es la instancia y luego las versiones de Acumatica. En este caso, he utilizado PSH como versión abreviada de PowerShell.
Muy bien, ahora que tenemos varias instancias de Acumatica instaladas y listas para el siguiente paso, hablemos de nuestro objetivo. Lo que buscamos es hacer cambios iterativos en el archivo .csprog. csproj obviamente no es una extensión XML, pero si inspeccionas el archivo en el bloc de notas, verás que efectivamente es XML. Este archivo contiene información de configuración sobre el proyecto y dónde va a enviar el archivo .dll, entre muchos otros ajustes de configuración que se utilizan para el proyecto. Intentemos identificar los elementos que necesitamos actualizar. La forma más fácil de ayudar a identificar estos elementos es hacer los cambios manualmente, luego inspeccionar el archivo y buscar los deltas. Voy a hacer una copia de este archivo. A continuación, voy a hacer manualmente los cambios, a continuación, por último, voy a utilizar un CMDLET PowerShell llamado Compare-Objects para investigar lo que cambió.
Me gusta usar etiquetas de compilación condicional, particularmente cuando el código base de Acumatica ha cambiado de tal forma que requiere una versión diferente de código para diferentes versiones de Acumatica. Puede utilizar declaraciones pragma para indicar al compilador qué versión de código desea utilizar. Esto es útil porque consigues mantener todas las versiones de Acumatica dentro de una única rama de control de código fuente. Otra forma súper útil de usar la compilación condicional es si quieres añadir algún código de depuración y te gustaría mantener ese código de depuración. Puedes decirle al compilador que ignore completamente cualquier código de depuración en la compilación de producción. Este es un tema que tengo la intención de elaborar en el futuro, pero por ahora, nos ceñiremos a lo que estamos buscando lograr. En la mayoría de mis casos, necesito configurar estos símbolos cada vez que hago compilaciones para diferentes versiones.
Un último dato que me gusta configurar es el número de compilación. Me molesta ver números de compilación como 1.0.0.0 en esta configuración. Por lo general, me gusta que coincida con el número de compilación de Acumaticas y, a continuación, utilizar algo único para el último número, como un mes y un día. Esto incorpora información temporal que resulta útil para hacerse una idea de cuándo se creó la .dll. Créame, es una información muy útil saber cuándo se creó una .dll. Otro beneficio de hacer esta práctica es que se puede confirmar la construcción deseada en realidad llega a su destino dentro de una prueba de integración. Estoy seguro de que un montón de ustedes han golpeado el problema cuando se va a desplegar un paquete, y sus cambios no entran en su lugar. Después de hundir un montón de tiempo de solución de problemas en usted, darse cuenta de las actualizaciones que acaba de hacer nunca lo hizo en un paquete. Si adquieres el hábito de actualizar siempre este valor junto con escribir un script de prueba para asegurar que llega a su destino final. Con el tiempo ahorrarás tiempo ya que evitarás los problemas de regresión en primer lugar.
Guarde los cambios y ejecute este comando PowerShell:
Obtendrá los elementos que han cambiado en el archivo como resultado:
Hay algunas herramientas más elegantes para hacer el mismo objetivo, como Beyond compare. Pero eso requiere una instalación, y Compare-Objects siempre estará disponible si lo necesita. Sólo otro beneficio de tener el prompt de PowerShell cerca.
Ahora que sabemos qué elementos tenemos que cambiar vamos a ver cómo hacerlo utilizando las herramientas XML disponibles en PowerShell. Lo que vamos a aprovechar es en realidad un espacio de nombres .NET XML en lugar de un CMDLET PowerShell dedicado. Así que es probable que, si usted es un desarrollador .NET, usted puede leer y entender esto con poca explicación. La forma de acceder al XML es la siguiente. Basta con convertir el contenido del archivo en un objeto XML. La principal diferencia es que C# utiliza paréntesis de cierre (xml) para su objeto, y PowerShell utiliza corchetes [xml]. El resto es idéntico a lo que harías con C#.
Ahora que tenemos un script que actualizará automáticamente los archivos del proyecto, podemos empezar a autocompilar la librería de extensión. Para ello, utilizaremos la línea de comandos MSBuild.exe. Podemos hacerlo con el siguiente script PowerShell.
Algo realmente bueno que podemos hacer es cargar los resultados del proceso de compilación en una variable y examinarlos en busca de indicadores que nos permitan saber si las cosas han ido mal. Así que podríamos añadir lo siguiente al script para pedir al usuario instrucciones para construir manualmente el paquete si falla. De hecho, he utilizado esto por un corto período de tiempo como apuntando a la C: Windows Microsoft Framework 4.0.30319 MSBuild.exe ubicación de la MSBuild.exe dio lugar a errores. Por lo tanto, terminamos con una secuencia de comandos que no era perfecto, pero todavía automatizado una buena parte del trabajo. Este es el poder de ser capaz de cargar los resultados en una variable y comprobar cualquier indicador de éxito o fracaso. El prompt Read-Host para llamar a algún proceso manual es de nuevo otra dinámica útil para semi-automatizar tu proceso.
Finalmente, nos dimos cuenta de que no obtenemos el error si utilizamos el ejecutable que se encuentra en esta ruta C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin\amd64\MSBuild.exe
Y entonces todo fue bien con el mundo. Otro elemento digno de mención es el uso de Write-Host junto con el parámetro -Foreground Color. Es una gran manera de darle una rápida retroalimentación visual si las cosas van según lo planeado. El rojo es un gran color para hacerle saber que las cosas salieron mal. Es información que puede procesar mucho más rápido que leer los resultados.
El siguiente paso es poner las cosas en funciones para que sea más fácil llamar a estas cosas desde un bucle. Así que tenemos las siguientes funciones.
Utilizaremos el trabajo que hicimos para actualizar el archivo VS Project como
También traeremos nuestro script de la parte 1 y finalmente podremos combinar todos estos pasos en uno:
Ahora podemos construir un bucle con el siguiente script. Podríamos ejecutar todo esto como un único archivo de script, o puedes dividir tus funciones en archivos separados. Este último es el más ideal, pero el primero puede mantener todo en un gist para un procesamiento de lectura más fácil. Si divide los archivos, use la llamada Import-Module {Ruta Del Script}.
Con Scripting, generalmente declaras tus variables en la parte superior. Estas son las variables que tendrán que cambiar a medida que compile diferentes proyectos y apunte a diferentes versiones. Las primeras 4 variables son variables comunes que serán usadas en cada iteración. La quinta variable $BuildConfigArray, es la información que cambiará en cada iteración.
Todo el código anterior se puede encontrar aquí en el GIST público aquí:
https://gist.github.com/RobertWaite/0a1cbc8408a1b3a30017fbf3f80094e6
El futuro
Te habrás dado cuenta de que hemos puesto un interruptor para indicar o no al usuario que obtenga el archivo Package.zip de Acumatica. En la Parte 3 vamos a explorar la automatización de esto también para que no necesitemos tener ese paso manual. Esa es la belleza del cmdlet Read-Host. Puedes automatizar iterativamente distintas piezas a lo largo del tiempo. Usted no necesita tener todo automatizado a la vez.
Resumen
Hemos aprendido mucho en esta parte, y no es difícil imaginar cuánto tiempo hemos ahorrado creando este script. Modificar el archivo XML del proyecto es un trabajo cotidiano para un desarrollador. Hemos explorado cómo cargar y modificar este archivo XML utilizando PowerShell. También hemos utilizado el MSBuild.exe.
Para leer la parte 1 de Useful PowerShell Tidbits to Help Save You Time Every Day, vaya aquí: /blog/useful-powershell-tidbits-part-1/
¡Feliz codificación!
