MODEL & MODEL STORE

What is Model?
A model is a set of elements in a given layer. Each layer consists of one or more models. Each layer contains one system-generated model that is specific to that layer. Every element in a layer belongs to only one model. In other words, no element can belong to two models in the same layer, and every element must belong to a model.

A default model owned by Microsoft exists in each layer. Default models cannot be modified.

A model is permanently associated with the layer that the model was created in. If you need to move one of your models from one layer to another, you must create a project from the model in the Application Object Tree (AOT), export the project as an xpo file, create a target model in the desired layer, delete the original model to avoid having to resolve layer conflicts, and import the xpo file to the target model. If you are moving elements between models in the same layer, you can use the Move to model command in the AOT.

What is Model Store?Models are stored in the model store. The model store is a database in which all application elements for Microsoft Dynamics AX are stored. Customizations are also stored in the model store. The model store replaces the Application Object Data (AOD) files that were used in earlier versions of Microsoft Dynamics AX. Models that have been installed in the model store are used at run time.

Note: In Microsoft Dynamics AX 2012 R2, the model store was moved into a database that is separate from the business database.

Models can be exported to files that have the .axmodel extension. These files are called model files. Model files are deployment artifacts. Model files can be signed with strong name signing and Microsoft Authenticode signing.

Differences between Model, Model store and XPOs in tabular form.

In Microsoft Dynamics AX 2012, label files, or ALD files, are part of models. A label file must be added to a model before the model can be installed. After a model has been installed, ALD files are pulled from the model store to the local of Application Object Server (AOS) instance when the AOS is started. When the AOS is shut down, the ALD files are pushed back to the model store.

ALD files from earlier versions of Microsoft Dynamics AX are not part of a model file. However, you can import these files into the model store from theLabel Files section of the AOT. Use the Create from file shortcut command.

If you install a model or .xpo, it’s not enough to compile the imported objects – the code may break some other objects or they just need to be recompiled to work correctly. Therefore the recommended approach is to compile AOT and generate full IL every time you did such import. Again, that’s shouldn’t be the case if installing model store.

 compiling just the imported objects is not enough – you will meet strange behavior or runtime errors (typically “wrong types in a variable assignment”) sooner or later, as others who still ignore this issue.

What should I be looking at to verify the CIL has been modified in the bin\XppIL path?

Regarding XppIL folder, you have several options, but you need to understand what it contains. IL generation creates a single assembly,Dynamics.Ax.Application. It composes of a single DLL (Dynamics.Ax.Application.dll) and many modules, namely Enums.netmodule, InterfaceTypes.netmodule, KernelTypes.netmodule and one thousand modules with other AX types (Dynamics.Ax.Application.dll0.netmodule –Dynamics.Ax.Application.dll999.netmodule). Dynamics.Ax.Application.dlldoesn’t contain any code, it only references the modules.

IL generations updates these modules, so one easy (but not completely reliable) approach is to check file sizes. For example, you may make a copy before generating IL and compare files by Powershell’s Compare-Object (e.g. Compare-Object (ls XppIL\*.netmodule) (ls XppILOld\*.netmodule) -Property Name, Length).

When you identify changed (or otherwise interested) modules, you can disassemble them (ildasm.exe) and check the content or even dump IL and compare it.

After importing the ModelStore I understand i need to do a table synchronization but what upgrade scripts need to be run? I had a look at the different checklists in AX and none of them are specific to importing a model store.

If data upgrade scripts, it all depends on what changes in data model were done. If no data upgrade is needed, updating code (by importing model store) is enough. Otherwise, upgrade scripts should be delivered with the change – either by Microsoft, a third-party vendor or you, depending on who made the change. For example, imagine that you’re an ISV and you decided to move a field from Table1 to Table2. Without data upgrade script, your customers would get a new empty field in Table2 and lose their data in Table1’s field, therefore you have to prepare a script to move the data. Obviously, you don’t want to do such things often, so this type of changes is usually done only as part of major upgrades. But sometimes you simply have to introduce a breaking change, e.g. by adding a missing unique index (data upgrade script is needed to handle duplicated values).

It is technically right about using Compile forward, but the complexity tends to rise very quickly (if you have more than few objects), it doesn’t verify that everything is really compilable in the target environment and Compile forward depends on some license, so I recommend to simply make full compilation