Trabajando con la máquina virtual de desarrollo local en Dynamics 365 for Operations

No voy a escribir una entrada sobre cómo configurar una MV local de Dynamics 365 for Operations para desarrollo, porque ya se han publicado muchísimas desde el lanzamiento del producto hace unos meses. También está publicado en la documentación oficial de forma bastante clara, así que sería repetir lo que ya se ha explicado mil veces.

Lo más importante es configurar bien la conexión con el proyecto de Visual Studio Team Services y con la rama que estemos utilizando, mapeando de forma acorde las carpetas locales. Por ejemplo:

  • La carpeta Metadata debe apuntar a donde están almacenados los paquetes de Dynamics 365 en el disco. Dependiendo de la versión de la máquina virtual pueden estar en C:\AOSService\PackagesLocalDirectory o en C:\Packages (en las versiones antiguas).
  • La carpeta Projects normalmente se configura en la carpeta por defecto donde Visual Studio almacena los proyectos (en Mis Documentos), pero esto dependerá de la estructura que siga cada equipo para almacenar los proyectos que, recordemos, no forman parte de los metadatos de AX en esta versión, como sí hacían los proyectos del AOT de versiones anteriores.

También hay una serie de propiedades que se pueden modificar para que la máquina se comporte de una forma más natural para un desarrollador de AX e incluso para mejorar un poco el rendimiento.

Siguiendo con nuestra cadena respecto a la introducción al desarrollo para Dynamics 365 for Operations, voy a comentar algunos escenarios que suceden mucho y parecen ser problemáticos para programadores que empiezan a utilizar las nuevas herramientas. Pequeños detalles que conviene no olvidar. Es posible que actualice este post en el futuro para tenerlos todos localizados:

 

Mi proyecto no se carga en una máquina recién desplegada

En proyectos donde intervengan múltiples programadores, lo que es muy común, cada uno necesita su propia máquina virtual para desarrollar en la nueva versión. A veces el coste de mantener todas esas máquinas actualizadas no compensa la sencillez de descargar una máquina nueva con la nueva versión y empezar desde ahí. Y lo mismo cuando es necesario actualizar muchas máquinas, normalmente es más facil actualizar o descargar una y hacer tantas copias como haga falta (cambiándoles el nombre). Al fin y al cabo sincronizas el código desde TFS y puedes empezar a trabajar casi de inmediato.

El problema es que cuando sincronizas el código la primera vez los proyectos parecen no poder cargarse en Visual Studio:

VS Load Failed

Para arreglarlo tenemos que ir a Dynamics 365 > Model Management > Refresh models, lo que actualizará la instancia actual con los modelos que se han descargado desde el repositorio de código:

Refresh Models

Después recargamos el proyecto:

Reload Project

Y a trabajar!

 

¡El Descriptor!

Vamos a suponer que hemos creado un modelo nuevo (en un paquete nuevo) para crear una extensión. Esto es bastante común, porque ya todos estamos trabajando con extensiones, ¿Verdad? 🙂

Cuando la extensión ya está creada, vamos a la solución y hacemos Add Solution to Source Control para añadir todos nuestros cambios al control de versiones. Y lo que obtenemos es un change set pendiente que se parece a este, y contiene la extensión que acabamos de crear, el proyecto y la solución:

Esto sería lo normal para un proyecto .NET en Visual Studio, pero cuando hablamos de Dynamics 365 for Operations, falta un detalle importante. Como acabamos de crear un modelo en este proyecto, este modelo todavía no existe en VSTS. Por tanto, si subimos estos objetos y otro programador sincroniza los cambios, habrá problemas, porque ese programador estará usando un modelo que no existe.

Para subir al source control el modelo en sí mismo, hay que añadir el Descriptor, ese fichero .xml que se llama igual que el modelo y se encuentra en la carpeta \Descriptor del propio modelo.

Para subirlo vamos al explorador de código fuente, y en la carpeta del modelo o en la del paquete hacemos Add Items to Folder:

Hay muchos ficheros aquí que no nos interesan, lo importante es localizar el fichero .xml en la carpeta \Descriptor de los modelos que acabamos de crear:

Ahora este change set parece completo. Es importante buscar que nuestros conjuntos de cambios pendientes tienen esta estructura (cambios en la carpeta de Packages, y en la carpeta de Projects, como hemos dicho al principio), y buscar que no nos olvidemos de añadir manualmente los Descriptor de los modelos al crearlos. Sólo hay que hacerlo una vez pero si se nos olvida provocaremos errores en las máquinas de otros compañeros o en la máquina de BUILD de la que hablaremos otro día:

¿Tienes algún truco más? Añádelo en los comentarios 🙂

4 comentarios
  • jaestevan
    septiembre 2, 2017

    En principio la configuración de TFS no puede afectar ni para bien ni para mal en que los cambios se vean en el cliente web. Al extender un formulario, los cambios pueden verse en el la vista previa de Visual Studio y al ejecutarlo pulsando F5 o “Start”, pero eso no significa que ya se hayan guardado en la model store.

    Si los cambios no se reflejan es porque el proceso de compilado no está actualizando correctamente los ensamblados, al fin y al cabo es una aplicación .NET lo que estamos creando. Yo probaría a hacer un build completo (desde el menu Dynamics 365 en Visual Studio) para a ver si arroja algún error.

    Es dificil saberlo sin ver el entorno.

  • Diego
    septiembre 1, 2017

    Gracias Estevan, en la comunidad dynamics ya creé un tema, a ver si me responden, la de español no conocia.
    Siendo un poquito mas especifico: resulta que hace unos dias descargué la virtual de desarrollo dynamics365, hice los pasos para conectar al team services, hice el mapping de los directorios y todo lo que me indicaban los tutoriales, y para probar si funciona extendí un formulario le agregué un boton y compile y recompile y el cambio no se reflejó en el cliente web, ni siquiera se recargó el cliente web al momento que estaba recompilando el formulario. Mi logica me dice que probablemente falta alguna configuración en el visual studio. Que te parece a vos Estevan?

  • jaestevan
    septiembre 1, 2017

    Hola Diego, vas a tener ser un poco más específico.

    Buenos sitios para buscar ayuda son la comunidad oficial (https://community.dynamics.com/) y El Rincón Dynamics en castellano (http://www.elrincondynamics.es)

    Saludos.

  • Diego
    septiembre 1, 2017

    Hola Estevan, ya probé de todo un poco para configurar mi visual y no logro hacerlo funcionar correctamente, vos me podrías ayudar con esto por favor? Ya no se que tocar en serio.

Comentarios

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sólo se aprovarán comentarios relativos a este artículo.
Para cualquier otra cosa por favor utiliza el formulario de contacto.