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

[Blog bot]

Источник: http://www.jaestevan.com/trabajando-...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:



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:



Después recargamos el proyecto:



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



Источник: http://www.jaestevan.com/trabajando-...for-operations