Estoy seguro de que muchos de nosotros hemos tenido que desarrollar algún tipo de librería en .NET para solucionar algo en Dynamics 365 Finance and Operations. Creas un proyecto de C#, lo compilas y añades la referencia en tu proyecto de FnO. ¡Ya no tienes que hacer eso! Puedes añadir el proyecto a tu repositorio de código, compilarlo en tu pipeline y ¡la DLL se añade al deployable package!
He estado haciendo estas pruebas a raíz de una conversación en Yammer, y a pesar de que he conseguido compilar .NET y X++ en la misma pipeline sin problemas, he encontrado algun problema o limitación.
Si quieres leer más sobre builds, releases y el ALM de desarrollo de Dynamics 365 puedes leer mi guía sobre MSDyn365 y Azure DevOps ALM.
Compila .NET en tu pipeline
Nota: lo que muestro aquí está hecho con la pipeline hospedada en Azure pero debería ser posible hacerlo con el agente self-hosted (la vieja máquina de build vaya).
El paso de compilar de las pipelines llama a msbuild.exe que también puede compilar .NET. Si comprobamos los logs del paso lo veremos:
Hay que recordar que X++ es ahora parte de la familia de .NET… un primo segundo o algo asi.
Si has leído mi post sobre las builds hospedadas en Azure habréis visto que pongo las soluciones que referencian todos mis modelos en una carpeta llamada Build en la raíz de mi árbol de código (imágen izquierda).
Esto es solo una preferencia personal que me ayuda a mantener los archivos .config y la solución que uso para compilar los modelos en un sitio único.
Al usar una solución y decirle al proceso de build que use sólo esa tengo todo más bajo control.
Añadir un proyecto de C# a FnO
El primer paso será crear un proyecto de Finance and Operations. Cuando lo tengamos hacemos clic derecho en la solución y seleccionamos «Add new project». Luego seleccionamos un proyecto de tipo Visual C# y Class Library:
Ahora deberíamos tener una solución con un proyecto de FnO y otro de C# (imágen derecha).
Para hacer esta demo crearé una clase llamada Calculator con un único método con 2 parámetros de tipo decimal que devuelve su suma. Un método suma.
public class Calculator
{
public decimal Add(decimal a, decimal b)
{
return a + b;
}
}Ahora compilamos el proyecto de C# únicamente, no toda la solución. Esto creará la DLL en la carpeta bin del proyecto. Tenemos que hacerlo antes de añadir la referencia al proyecto de Dynamics 365.
Hacemos click derecho en el nodo References del proyecto de FnO y seleccionamos «Add Reference…»:
Se abrirá una ventana y tendríamos que ver el proyecto de C# en la pestaña «Projects»:
Lo seleccionamos y hacemos clic en el botón Ok. Esto añadirá el proyecto de C# como referencia a nuestro proyecto de FnO, pero todavía tenemos que hacer una cosita o la pipeline no compilará. Tenemos que añadir a mano la referencia que acabamos de crear. Así que hacemos clic derecho en la referencia y seleccionamos «Add to source control»:
En el proyecto de FnO añadimos una Runnable Class, llamaremos a la librería de C# ahí:
using AASBuildNetDemoLibrary;
class AASBuildNetTest
{
public static void main(Args _args)
{
var calc = new Calculator();
calc.Add(4, 5);
}
}Añadimos la solución al control de código si no lo hemos hecho y nos aseguramos que todos los objetos están añadidos también antes de hacer el check-in.
Build pipeline
Si voy a mi repositorio de Azure DevOps veremos esto:
Podéis ver que he puesto la solución en la carpeta Build. Como decía al principio esto es mi preferencia personal, y lo hago para tener las soluciones que se usan para compilar el código bajo control y ordenaditas.
En mi pipeline de build me aseguro de que estoy usando esa solución:
Ejecuto la pipeline y cuando termina podemos ver una línea en el log del paso de compilar en la que pone:
Copying file from "D:\a\9\s\Build\AASBuildNetDemo\AASBuildNetDemoLibrary\bin\Debug\AASBuildNetDemoLibrary.dll" to "D:\a\9\b\AASDemo\bin\AASBuildNetDemoLibrary.dll".Y si nos descargamos el DP, lo descomprimimos, vamos a AOSService\Packages\files y descomprimimos el archivo que hay ahí y abrimos su carpeta bin, veremos nuestra DLL:
¡Trabajo hecho!
Cosas que no me gustan/entiendo/tengo que investigar
Siempre he hecho esto con una única solución y un único proyecto de C#. Tengo algunas dudas sobre cómo funcionará esto con varios proyectos de C#, modelos, soluciones, etc.
Por ejemplo, si un modelo tiene una dependecia de una DLL, pero se compila antes que se genere la DLL, la compilación fallará. Estoy seguro que hay una forma de resolver estas dependencias igual que la hay para las dependencias entre proyectos de FnO dentro de una solución.
O igual podría intentar compilar todo el código C#/.NET primero, empaquetarlo en un nuget y usar las DLLs más tarde en la build de FnO, algo parecido a lo que explica Paul Heisterkamp en su blog.
De todas formas, es vuestra elección el decidir como gestionar vuestros proyectos de C# y qué solución se ajusta más a vuestra forma de trabajar, pero por lo menos ya tenéis algo por lo que empezar 🙂
