Duplicated Model IDs in D365FO

 We have researched the case of duplicated model IDs in D365FO you might encounter when importing a new model or replacing an existing one. Why does this happen?

Upon creating, every model gets a unique model ID (32-bit integer). This ID has to be unique for various reasons. When running overlayerings and extensions, kernel takes the layer and model IDs into account to determine the order of execution. Models with higher ID generally execute later – at least this holds true for models within the same layer. This way a model with higher ID could alter the behavior of a model with a lower model ID.

When does Model ID change

When importing a model, the system generates a new model ID and automatically assigns it to the model. It seems that this new model ID is typically the highest model ID in the environment. When replacing the model its model ID remains untouched.
(We have seen also deviations from these rules, but as we cannot reproduce it, it could be the testing error or some other reason.)

On the contrary, when we create a deployable package, its model ID remains fixed, stored in the compiled package and does not change at installation time.

Model ID – could it be a cause of conflicts?

We could typically run into problems when two models share the same model ID. This happens when we install different models via deployable packages, for instance models from different ISVs that would incidentally carry the same model ID.

The second possible source of conflicts could be upgrading D365FO. We could run into conflicts if Microsoft adds some new models to D365FO and one of them carries the same model ID as one of the custom models already installed. Conflicted model IDs results in a compile time error.

In such cases, you can manually reset the model ID of one of the conflicting custom models. For instance, if you installed model via models, it would be perfectly adequate to just change  conflicting model ID and recompile the code.

If you are not certain whether an explicit model ID is still available or perhaps already taken, you could try the following work-around. Create a new ‘dummy’ model, store its model ID and then delete this model. You could then assign the same model ID to your conflicting model.

Where can I check the model ID

If you open the Descriptor file in the Descriptor folder of a package, you will find an XML file in there - the  AX model's ID highlighted below:

But for models installed with a deployable package you do not have the source code nor the descriptor file. To view their model ID, just navigate into the /bin directory of the package and search for the .md file: PackagesLocalDirectory\model\bin\model_ModelInfo.md

Using a hex editor (https://hexed.it/) we can easily locate the model ID immediately after the name of the model: