While the end user experience has changed dramatically from AX 2012 to D365FO, arguably the bigger changes are to the development side. This post will go through some of the highlights of this and hopefully give a better understanding of some of the changes that will impact developers in D365FO.
Overview of Development in AX 2012
Need to start by giving a baseline of where development of X++ code was in AX 2012.
AX is broken up into multiple coding layers, these layers allow for independent development and allow higher layers to make modifications to lower layers. Therefore modifications made at the USR level overrode customizations made at the CUS or lower levels.
There is also different levels of grouping your code and metadata together. At the lowest level is a XPO, which is as close to pure source code as you can get within X++, it represents objects and their attached metadata and source code. At the next level is a model which is a collection of source code that normally represents a full solution. These are normally created by clients and delivered by ISVs/VARs as the preferred method of making customizations to AX. These are added to your environment, modifications can then be made (if necessary), and then finally compiled together with the rest of your code for the customizations to take effect. At the highest level is the Model Store which contains all source code, metadata, p-code and CIL. Since this contains already compiled code you do not need to recompile when moved. This is as close as you could get to a compiled binary in AX 2012.
When developing X++ the source code was compiled into p-code which was interpreted by the X++ interpreter at runtime.
Where We’re Going in Dynamics 365 for Finance and Operations
With the release of Dynamics 365 Enterprise a number of changes to the development environment, lifecycle, and methodology have occurred.
Changes to X++
The X++ compiler has been completely rewritten and now generates .NET CIL (Common Interface Language) only, so there is no more p-code. This is step forward for a number of reasons:
- .NET CIL is normally faster than interpreted p-code
- Can interface easier with other managed languages (like C#)
- No need for the .NET Business Connector
Models File vs Deployable Package
A model file in AX is development object that contains source code and metadata, in AX 2012 this is the preferred method of transferring customizations and deploying code to clients. Client’s can see the actual source code and could make customizations to it before compiling it into their solution. A deployable package in Dynamics 365 Enterprise is a .NET CIL compiled version of your source code and metadata, it can contain multiple model files. This is the preferred method of transferring and deploying code in Dynamics 365 Enterprise, especially in production instances as you would not have access to the AOS or AOT to add a model file. One of the many benefits of this from an ISVs perspective is that the client can no longer see your source code as the source code is already compiled to .NET CIL, they can however still create extensions of your code (we will go into details of what this is in the next section).
Extensions vs Overlayering
In previous versions of AX, when a customization was added to an environment (either from a client or from a VAR/ISV) it was delivered in the form of a model file. This model file would be applied to the correct code layer and the customizations of this model could modify elements of code that were at a lower code level. This idea of modifying code at a lower code level is called overlayering and is a staple of development in AX. With the move to the cloud of Dynamics 365 Enterprise and the need for Microsoft to be able to control their source code (specifically for updating their platform on a periodic basis), the idea of overlayering has gone away and has been replaced with the idea of extensions.
Extensions are still customizations of objects but instead of making modifications to the actual object, you are leaving the default object functionality and creating new functionality to implement your customization. Extensions can be created by either subscribing to pre/post events on methods or by creating class extensions. It is vital for customizations to be moved over from the overlayering methodology to extensions because Microsoft is actually locking down all models from overlayering customizations. They are doing this in a two step process, first a model will be soft sealed and you will receive a warning during the compilation of your solution, then it will be hard sealed and you will receive an error during compilation of your solution and it will no longer build. The ‘tentative’ roadmap of this process is below.
Changes to Development Environment
All development is now done within a modified version of Visual Studio that lives in a virtual machine running Windows Server and an entirely contained instance of D365FO. For those who have written code in the old MorphX editor this is an absolutely huge improvement as you are now able to use all the tools and features already built into Visual Studio. These include:
- Native integration with Team Foundation Services (TFS)
- Merge tool features
- 3rd Party Addins (Resharper, etc)
- Other native functionality of Visual Studio
The version of Visual Studio installed on the VM includes a Dynamics 365 menu, this menu has a number of options that are needed for development and deployment of X++ solutions.
Deploy – if you need to create a deployable package from your solution
Model Management – where you can create a model or update a model’s parameters
Build models – where you can build any model that is currently in your environment
Synchronize database – If you create/modify/remove a database element (table, view, stored procedure, index, etc), or if you create/modify/remove a role, duty, or privilege you will need to run this process for your change to be synced to the database
One thing to note is that development environments should not (and cannot) be shared between developers, each should have their own VM environment to develop on. Developers should also be using some sort of code repository (TFS, Git, etc) to organize your code, and best practice is to use some sort of branching methodology (Dev/Main/Release etc) with your code check ins and releases.
Sources
Development Changed in Dynamics 365 Enterprise
Announcing Application Extensibility Plans
MorphX Development Tools for AX 2012
Customize with Extensions and Overlayering
Comprehensive 3 part series showing the shift from AX 2012 Development to Dynamics 365 Enterprise (written by Joris de Gruyter of Microsoft)
Design-Compile-Run Part 1: 2012 Paradigms
need d365 integration architecture diagram
Here’s the best overview of the architecture I could find:
Application stack and server architecture