It looks like models in Dynamics AX 2012 don’t support moving between layers. Code is not being moved to another layer every day, but it’s also not an exceptional situation. We still have our old tools like export and import of .xpo files, but models just complicate this process instead of simplifying it (because you have to handle model’s properties, e.g. name and version).
I’m going to show a simple workaround, although it’s not suitable for all teams and all situations. If you know a better way, please let me know.
Let’s say you have a model called “Move” containing some objects in USR layer and you would like to move it all to ISV layer. It can be achieved by the following procedure:
- Add the model to TFS version control
You need to create a subfolder in the repository folder, then click Version Control > Add model to version control in AX development workspace and set the model ID and the repository subfolder. - Uninstall the model
You can use this Powershell command:Uninstall-AXModel -Model Move
(Move is the name of the model) - Restart AOS
The following command restarts all local AOSes:Restart-Service aos*
- Change layer in model manifest file
Go to Source Control Explorer in Visual Studio, ensure yourself that you use the same workspace as Dynamics AX and locate the folder with the “Move” model. Then open Model.xml, find the layer and change the value from Usr to Isv.
You don’t have to check this modification in if it’s not a permanent change. (That makes sense if you are just releasing a model to a different layer in another application, not moving it.) - Synchronize AX with TFS
Run AX development workspace and choose Synchronize from Version Control menu. Check Force and pick the folder to synchronize with:
And that’s all – model and its definition, as well as all its objects, are in the ISV layer.
To be absolutely correct, we didn’t move the model. We deleted the model and when AX was started, it has read the (modified) manifest file, created a new model based on this file and the synchronization added all objects to this new model.
What happenned to data and object IDs after this operation?
Because AX2012 uses installation-specific IDs and the model is uninstalled in point 2., data dictionary IDs can change.
If you already have data in database objects defined in the moved model, you need to update data dictionary to the new values. It can be automated easily – I published the solution for you here.
Great stuff Martin.
I finally had a scenario where I used this script.
I found an issue where it didnt work for views.
All I did was change the line.
From
if (!dictTable.isSystemTable())
To
if (!dictTable.isSystemTable() && !dictTable.isView())
I deleted the views in question. Then it all worked fine.
I should clarify.
It didn’t work for the view because of a key issue. Another record in SQLDictionary had the same key.