CODEWITHSUNDEEP
axaptax++dynamics-ax-2009
Francis Ducharme
Francis Ducharme

Reputation: 4987

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 :|

Upvotes: 3

Views: 1778

Answers (4)

Michal
Michal

Reputation: 11

my experienced procedure with updating labels in AX 2009 is following:

  1. Copy the modified *.ald files (which contains labels and you should copy only the one you need-For example only EN-US + CS) from DEV to PROD. It doesn't depend whether AOS service is running or not.
  2. That is all! The rest is done automatically when no user is connected (and no backgroud job is running) to AX for minute or so. Of course you can restart the AOS service to have it updated sooner, but in my case it is not neccessary.

Good luck!

Upvotes: 1

Michael Brown
Michael Brown

Reputation: 2201

I have come across this issue a number of times. Please see the following blog entry in which I detail how to import labels as part of an XPO. http://blog.m1cr0sux0r.com/2011/04/exporting-labels-with-xpos-in-dynamics.html

Upvotes: 0

Klaas Deforche
Klaas Deforche

Reputation: 1151

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.

Upvotes: 4

Francis Ducharme
Francis Ducharme

Reputation: 4987

I ended up copying the label file (.ALD) to the application directory of the target environment. I guess if I added or deleted labels, some other files than the .ALD files would need to be copied.

Upvotes: 0

Related Questions