Visual Studio Workspace mapping Dynamics 365

 In Development, Dynamics 365, Dynamics AX

Source version control

When we set up Visual Studio Team Services (VSTS) to work with Microsoft Dynamics for Finance and Operations Microsoft, and the AX community in general, recommend two mappings to track the changes with the version control system.

One of the recommended mappings is for Visual Studio projects, which store references to X ++ objects that are in the metadata directory. Having projects in the code repository allows us to work much more easily with other team members or even between environments. This way to link the projects between the development machine and the version server fulfills its function superbly.

Microsoft’s proposal is to link the folder of the server where the projects will reside (for the example of this blog is $/EmiralBlog/Trunk/Main/Projects) with the directory of the file system where the projects will be stored (in this example would be C:\Users\Administrator\Documents\Visual Studio 2015\Projects).

The other mapping is the meta-data directory used by the AOS (AX object server). Having the X ++ code in the code repository is precisely the main goal of VSTS. The customizations we make will be accessible to other members of the development team, we will have a “backup” of the work and we will have a history of code changes with which to trace any problem or from where to start a new improvement.

Microsoft’s proposal is to link the folder of the server where the models and application objects that will be developed will be saved (in this example it is $/EmiralBlog/Trunk/Main/Metadata) with the directory of the file system where the .xml files that define the objects will reside. That includes both those of the standard and those customized (this path is hardcoded by Microsoft C:\AOSService\PackagesLocalDirectory).

¡More than 50.000 changes!

If the meta-data mapping proposed by Microsoft is carried out, the information with which to work on changes to the customization is greatly reduced because all the files that are part of the Dynamics 365 for Finance and Operations standard models will appear as detected excluded changes. The following screenshot shows how fifty thousand changes of files added have been detected.

If 50,000 looks like a number too good to be true, it is because it is not true. It may be that Visual Studio or VSTS can only detect a maximum of fifty thousand detected changes outside the repository, or maybe it’s for some other reason, but the fact is that only the standard objects and the files generated from them add up to more than 200,000 files, as you can observe in the following screenshot.

Everything in its place.

A much more convenient option for daily work is to link each of the package folders (and their models inside) in the repository with the file system directory that hosts the package in the development machine. In the following screenshot you can see the example of three packages of customization models.

This way, no pending changes from the standard models appear in the code repository, as shown in the following screenshot.

Taking out the trash.

Not everything in the package directories is information for which you want a version control. There are files generated automatically with the compilation, logs or json files, for example. To exclude these files from version control and avoid being bothered by them as excluded changes or changes detected, a .tfignore file can be added to the directory of each customization package (in the blog example, one of the directories where the file would be placed would be C:\AOSService\ PackagesLocalDirectory\EAX_App) .

The .tfignore file informs VSTS to not take into account the files that conform to the patterns written inside.

A good starting point for the content of the file can be:

\*.xml
\*.log
\Resources
\WebContent
\XppMetadata
\bin
\Reports

 

Recent Posts

Leave a Comment