Search code examples
axaptax++dynamics-ax-2009

Updating labels via XPO export

I have modified labels in my dev. environment along with other code changes but when I export this XPO and then import it in another environment, the labels in the target AOT are not updated.

If I open the XPO in Notepad, I indeed can see the newly modified labels. But at the time of import, the dialog does not detect changes it seems.

All labels ID's which I would want to be updated in the target are set to "Do not import" in the Details part of the import dialog.

If I have, 10, 20, 30 labels that changed, I would like to think AX would be smart enough to select "Use an existing label".

Any way to achieve this?

Thanks!

EDIT: Even when I manually set to "Use an existing label" and set the ID of the label to use, labels are not updated in the target :|

Solution

  • For AX 2009, instead of importing label using XPO's, I would recommend the following:

    • Use a version version system such as TFS (especially when working with multiple devs)
    • Setup up a build. (This could be an environment where you connect to your version control system and do a sync of all code that was checked in. Or create a script that uses combinexpo to compbine all xpo's for your version system and imports it)
    • You should now have a stable build environment -> copy the ald and aod files from here
    • Stop the aoses of you target environment, delete all .aoi, .ali, .alc and .alt files and copy/paste your ald file from your build into the target environment. I would suggest you do the same for aod files to move code.

    The reason why you shouldn't be using xpo's for deployement is that it is prone to human error. XPO's should work so they aren't a problem themselves but they can cause problems because importing xpo's is a manual action.

    The advantage of using source control is that you have traceability (you know what code is being delivered) and that it opens the door to having an automated build procedure (which will result in less errors form manually tranfering xpo's). With this build you can set up a daily build for your test environment, which again will improve the quality due to better testing. When all tests pass for a build, you have a tested build which you can then deliver using .aod files to your customer (no xpo's are used, so you are delivering the exact code you have tested).

    Of course, it could be that setting up an automated build and such is overkill for you (I do think you should you version control always though) you can leave this out, the important thing is that you deliver code and labels from dev to test and all the way to you customer using aod and ald files.