3

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

Filip
  • 3,257
  • 2
  • 22
  • 38
Francis Ducharme
  • 4,848
  • 6
  • 43
  • 81

4 Answers4

4

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.

Klaas Deforche
  • 1,151
  • 5
  • 9
1

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!

Michal
  • 11
  • 1
0

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.

Francis Ducharme
  • 4,848
  • 6
  • 43
  • 81
  • Maybe you forgot to specify the target label-file on import? – Jan B. Kjeldsen Feb 07 '14 at 07:00
  • 1
    Hi Francis, with AX 2009, I always move labels by copying the ALD from one environment to the other like you did now. When importing and xpo, then import it without labels. That works much better imo. When copying ald files, remove the ali, alt and alc files in your target environment and make sure the AOS is stopped when you do it. No files other than the ALD need to be copied to deploy the labels. – Klaas Deforche Feb 07 '14 at 09:28
  • @KlaasDeforche At this point, would you recommend not using labels in AX2009 ? I find label management quite craptastic and prone to manual errors. – Francis Ducharme Feb 07 '14 at 21:28
  • No no, definitely use labels, it's best practice (always follow best practice). But deploy them using the ald files instead of using XPO's. This will keep all id's in sync over all your environments and make sure you don't make manual errors. That's how I did it with 2009 and it worked great. I'm not a fan of xpo files, I never use them to deploy code, not on AX2009 and not on AX2012. – Klaas Deforche Feb 07 '14 at 23:27
  • @KlaasDeforche No XPOs ? So you copy entire layer files ? How could XPOs be a problem ? Thx. – Francis Ducharme Feb 08 '14 at 15:17
  • 1
    XPOs are evil :) Every time code gets merged manually this can introduce bugs, especially if you have to manage multiple layers. The good practice would be to release the entire application from your QA/UAT environment. As KlaasDeforche mentioned, TFS can help automate this. –  Feb 24 '14 at 12:09
0

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

Michael Brown
  • 2,221
  • 2
  • 17
  • 34