Working with the local development VM in Dynamics 365 for Operations
I’m not going to write a post about how to set up a local VM for Dynamics 365 for Operations development, because there have already been plenty of since the product launch a few months ago. It’s also clearly explained in the official documentation, so it would just be repeating what’s already been explained a thousand times.
The most important thing is to properly configure the connection with the Visual Studio Team Services project and the branch you are using, mapping the local folders accordingly. For example:
- The Metadata folder should point to where the Dynamics 365 packages are stored on disk. Depending on the VM version, they may be in
C:\AOSService\PackagesLocalDirectoryor inC:\Packages(in older versions). - The Projects folder is usually set to the default folder where Visual Studio stores projects (in My Documents), but this will depend on the structure each team uses to store projects, which, remember, are not part of AX metadata in this version, unlike AOT projects in previous versions.
There are also a number of properties you can modify to make the machine behave more naturally for an AX developer and even to improve performance a bit.
Continuing with our series on introducing development for Dynamics 365 for Operations, I’m going to comment on some scenarios that happen a lot and seem problematic for developers who are starting to use the new tools. Small details that are worth remembering. I may update this post in the future to keep them all in one place:
My project doesn’t load on a newly deployed machine
In projects involving multiple developers, which is very common, each one needs their own virtual machine to develop in the new version. Sometimes the cost of keeping all those machines updated isn’t worth the simplicity of just downloading a new machine with the new version and starting from there. And the same when you need to update many machines—it’s usually easier to update or download one and make as many copies as needed (renaming them). After all, you sync the code from TFS and can start working almost immediately.
The problem is that when you sync the code for the first time, the projects don’t seem to load in Visual Studio:
To fix this, we need to go to Dynamics 365 > Model Management > Refresh models, which will update the current instance with the models downloaded from the code repository:
Then reload the project:
And you’re ready to work!
The Descriptor!
Let’s suppose we’ve created a new model (in a new package) to create an extension. This is quite common, since we’re all working with extensions now, right? :)
Once the extension is created, we go to the solution and do Add Solution to Source Control to add all our changes to version control. What we get is a pending change set that looks like this, containing the extension we just created, the project, and the solution:
This would be normal for a .NET project in Visual Studio, but when it comes to Dynamics 365 for Operations, there’s an important detail missing. Since we’ve just created a model in this project, this model doesn’t exist in VSTS yet. So, if we upload these objects and another developer syncs the changes, there will be problems because that developer will be using a model that doesn’t exist.
To upload the model itself to source control, you need to add the Descriptor, that .xml file named after the model and located in the model’s own \Descriptor folder.
To upload it, go to the source control explorer, and in the model or package folder, do Add Items to Folder:
There are many files here that we don’t care about; the important thing is to find the .xml file in the \Descriptor folder of the models we just created:
Now this change set looks complete. It’s important to make sure our pending change sets have this structure (changes in the Packages folder and in the Projects folder, as we said at the beginning), and to make sure we don’t forget to manually add the model Descriptors when creating them. You only have to do it once, but if you forget, you’ll cause errors on your colleagues’ machines or on the BUILD machine, which we’ll talk about another day:
Do you have any more tips? Message me in social media! :)