This article describes the main differences in the development environment between Microsoft Dynamics AX and Dynamics 365 and offers tips for using Visual Studio in your development efforts.
Originally published in Q3 2017 D365UG/AXUG Magazine
All new versions of Microsoft Dynamics AX both scare and delight me. The latest release of Microsoft Dynamics AX, Microsoft Dynamics 365 for Finance and Operations, Enterprise edition, is no exception! In this release, the application is entirely browser-based, there is no fat client, which means there isn’t the traditional Microsoft Dynamics AX development environment to get into. All development work for Dynamics 365 is done in Visual Studio (VS). As you might imagine, the migration to VS brings a lot of differences for developers. In this article, we will touch on some of those changes and hopefully jumpstart your learning adventure.
Models
Like Microsoft Dynamics AX 2012, the first thing you do in a Dynamics 365 environment is create a new model. Different from Microsoft Dynamics AX 2012, the dialog for creating a model has been expanded to prompt for a lot more information. In Dynamics 365, when you create a new model, the dialog/wizard for the new model prompts for these things:
- Standard model information, like the model’s name and publisher, along with the layer you want to work in (choose a layer you can access like usr, cus, or var)
- The package you want to work in. Packages are described later in this article
- The VS operations project you want to create
VS Project Types
When you finish filling out the fields in the model wizard, you click OK and are presented with a second prompt asking you to create a VS project. Your VS project will live inside of the model you just created. There are three Microsoft Dynamics project types that have been added to VS:
- Best Practice Rules – used for writing custom best practices checks for code and metadata
- Developer Tools Add-in – used for writing utilities to aid the development process
- Operations Project – main type for building customizations
The wizard for creating a model is asking what name should be given to your operations project. Once the model and project have been created, in VS’s Solution Explorer, you can see the layer and model next to your project name.
Packages
As previously mentioned, when you create a model, the wizard also prompts you for the package the model should live in. Packages are comprised of the models, binaries, and any additional files needed to deploy code. Packages are similar in concept to Microsoft Dynamics AX 2012 modelstores. The model wizard asks you whether you want to:
- Create a new package
- Select an existing package
The choice you make here is important. The first option, “Create a new package,” means you intend to create an extension project. In an extension project, you will be adding new methods, controls, fields, etc. to existing AOT elements along with building completely custom objects. If you want to add or alter existing logic, you will need to do this in a more “additive way” using events that have been added to
elements in the AOT. Think of an extension package as something like adding an assembly reference to a project in VS. You want to use the classes in the assembly you’ve referenced; you don’t wish to change their logic.
Choosing the second option in the model wizard, “Select an existing package,” means you intend to override or overlayer the existing logic. This is essentially what you did in all previous versions of Microsoft Dynamics AX because there weren’t other options. Think of this option as adding a VS project into an existing VS solution. The VS solution in this case being the existing package that I’m adding my model into. From the two choices of creating a new or selecting an existing package, if possible, you want to choose to create a new package. This option forces you to isolate your changes from the package you are extending which means you won’t run into merge issues whenever you apply hot fixes or code upgrades to the environment.
AXPP Files
Once you get beyond models, project types, and packages, there are other changes to get used to. Files ending in *.axpp are the VS replacement for *.xpo files. To export and import VS projects like what you would do with xpos on Microsoft Dynamics AX 2012:
- In the Solution Explorer, right-click on a project and choose Export project <ProjectName>
- The contents of your project get saved on the hard drive as a file with an extension of *.axpp.
• The model the project is created in is saved in the *.axpp file.
■ The model contains the details on which layer the model should exist.
• The *.axpp file cannot be read with a text editor. - To import an *.axpp file, in VS go to the Dynamics 365 menu (a new menu added to VS) and choose Import project.
• The project is created in the model and layer that were saved in the *.axpp file.
■ If the model does not exist in the imported environment, it will be generated for you. - Similar to importing an *.xpo in AX 2012, in Dynamics 365, you can do a compare between the contents of an *.axpp file and the current environment. To compare objects during the import:
• When you select Import project, a dialog opens asking you to select the location of the *.axpp file.
• Once you have selected the *.axpp file, at the bottom of the dialog there is a Details section.
• In the Details section, you can see the objects to be imported.
• When viewing the objects, right-click on one of them, and in the Context menu, choose Compare to bring up the Compare window.
Compare Tools
For the most part, in Dynamics 365, you will not need to use the compare tools which is a very big difference from Microsoft Dynamics AX 2012. In Dynamics 365, if your project is in an extension package, there are no potential conflicts because your code is entirely new, so a comparison is not necessary. If you are overlaying an existing package or importing an *.axpp that contains objects conflicting with what you have in your environment, you will still need to use the comparison tools. Fortunately, the tools for comparing changes are much better. The largest change in the comparison tools is that they have been split up, so metadata is compared in one tool, and code is compared in a separate compare tool. For example, if you have an overlaying project, in the Solution Explorer, right-click on an object, and you can see the following three options in the context menu:
- Compare Code with Baseline – compares your code to what was shipped in the sys or isv layer.
- Compare and Merge Code – compares your code to what was shipped in the sys or isv layer and allows you to merge the two if there is a conflict.
- Compare Metadata with Baseline – compares the pieces of the element that are not code like the properties or in a form design or the fields on a table with what was shipped in the sys or isv layers.
The changes described in this article for the development environment, models, packages, projects, project files, and comparison tools are just a fraction of the total changes. If you are an experienced Microsoft Dynamics AX developer, be patient with yourself. The changes will take some time to get used to. Regardless of your past experience with Microsoft Dynamics AX, if you would like a tour guide to lead you through development in Dynamics 365, D365UG/AXUG® periodically offers live online development courses. You can register for them in the D365UG/AXUG website under the Learn & Engage > Academy Courses.
Once you have had some experience with the environment, you will understand why Microsoft moved to VS. This is a huge step forward for the development platform! From now on, Microsoft Dynamics AX developers will get to take advantage of the vast number of truly awesome features in VS, and we will be able to innovate more rapidly than ever before.