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.
We only noticed this on newer versions of D365FO, while on older versions (PU24 included) the model ID from the imported model file (.axmodel) was preserved.
More vague rules apply when replacing (upgrading) a model: its model ID normally remains untouched. However, when testing model behavior extensively, we have already experienced that a model ID can change too. Unfortunately, we could not determine when and why exactly this happened.
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 Docentric AX via models, it would be perfectly adequate to just change Docentric’s conflicting model ID and recompile the code.
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 Docentric 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\DocentricAX\bin\DocentricAX_ModelInfo.md
Using a hex editor (https://hexed.it/) we can easily locate the model ID immediately after the name of the model:
Deployable packages installed on DEV environments
If a model is conflicting and installed via a deployable package, its model ID is much harder to change afterwards. Although we did not test this, we assume it would still be possible to do so with a HEX editor.