Sunday, May 22, 2016

Microsoft Dynamics 365 for Operations - How Packages and Models live in Visual Studio

In continuation of my previous post on few major technical changes in the world of AX 7, this post is all about to understand the core components of AX 7 development before we jump into AX development IDE in visual studio. Yes, we will write X++ code into Visual Studio by using four components.

There are 4 main components to understand in Visual Studio include Elements, Models, Projects and Packages. To explore more let's have a look at a screenshot of the Application Explorer. Within it, there is an AOT node.

Model(s) and Packages(s) in Visual Studio environment

I am gonna dig dipper into what Model and Package mean?


  1. Model is a group of elements that represents the particular solution (Tables, Forms, and Classes e.t.c) 
  2. The definition of the Model is similar to what it was in AX 2012 (AX 2012 Models) 
  3. Model is a design time concept. For example A Fleet Management Model, A Project Account Model
  4. A Model may contains multiple Visual Studio projects. However, a project many only belong to one model
  5. All of the sub-nodes below the AOT node are different models, this is call Model View


  1. A Package is a more of a compilation unit and distribution unit to move binaries and any other runtime artefacts that your model need between environments during the development ALM process. For example; moving them from the development box to the Cloud to run.
  2. A Package typically is one or more Packages typically packages into one we called deployment package and this is the unit that you use to move code to Cloud.
  3. A Package is a deployment unit that may contain one ore more models. In addition to elements, it includes more metadata, which is a description data that defines the properties and behaviour of the model.
  4. A Package can be exported into a file which can then be deployed into a staging or production environment. 

Model in AX 2012 and in AX 7

Model concept in AX 7 is quite similar to what it was in AX 2012. These are the source code so ISV distributing their solutions to partners or to customers are typically giving the models, they don't provide Packages. They provide models that can be installed onto your box, customize them and the move them into your Cloud environment.

Package in AX 2012 and in AX 7
In the AX 2012 world, Package is closer to what we used to call the model store to what we used to call the model files. Because you know they are pre-compiled things that you can deploy to a production or to UAT environment. 

Visual Studio Project and Elements

I am gonna dig dipper into what Project and Element mean?

Visual Studio Projects

  1. Recommended way of development is to create Visual Studio project for all changes and the project always belongs to model, you can think of them is a subset of your model. Why do we have a different concept for model and project? The only reason we have two concepts of a model and a project is, typically AX 7 models are very large and its not a good practice to compile entire model for a simple code change activities during your development.
  2. Project always belongs to a particular model and is basically a subset of elements that belongs a model.
  3. One or more model can constitute a package, typically every package has one model. The reason sometimes we have one or more models in particular package when you customize during overlaying of source code.


Elements are AOT objects, for example; Base Enums, Extended Data Types, Tables, Classes, Forms, and Menu items and a lot more.

Stay tuned! I will be posting more on how we can use these four components in real development.

Happy Dax!ng