0

Having just completed the painful process of upgrading all our custom code from AX 2012 RTM to AX 2012 R2, we are now in the process of applying CU7.

When running the 'Detect Code Upgrade Conflicts' process, it has reported a large number of 'Deletion Conflicts' on our custom AOT objects (mainly tables, classes, and strangely configuration keys).

These custom objects only exist in the VAR layer, and therefore we would assume have no conflicts with sys / syp layers. Some of the methods it reports as conflicting, are simply a class declaration !

I should add - I understand that I can simply mark them as resolved, but I'd like to get to the bottom of why the system thinks there are conflicts on these objects, in case we have some kind of underlying problem with the models and/or we might hit this again with next CU / Hotfix installation.

Does anyone have any ideas ?

Thanks in advance !

Jan B. Kjeldsen
  • 17,817
  • 5
  • 32
  • 50
ac_cam
  • 9
  • 3
  • Can you show examples or be more specific at all? – AnthonyBlake Mar 03 '14 at 10:30
  • 1
    Show the exact messages from `axutil`. – Jan B. Kjeldsen Mar 04 '14 at 09:30
  • @AnthonyBlake Basically, as an example, we've added an entirely new class in the VAR layer. There should therefore be no conflicts with sys/syp. The conflict detection shows a 'deletion conflict' on the class declaration method. Does this help at all ? – ac_cam Mar 04 '14 at 10:19
  • @JanB.Kjeldsen Apologies, I'm not sure how to use axutil to view results of the conflict detection as part of a hotfix install. Can you elaborate ? Thanks. – ac_cam Mar 04 '14 at 10:20
  • So, I think I can see what the problem is, but no idea how this has happened. Comparing our custom class, it appears that it wants to compare with the same class name in the syp layer (which when you look at the code, is actually a completely different class). I can only assume these are new classes added as part of CU7 which have the same IDs ? – ac_cam Mar 04 '14 at 10:59
  • Then your VAR class has SYS/SYP id? You will have to export/delete/import your class to have it reassigned its id. – Jan B. Kjeldsen Mar 04 '14 at 13:28
  • Hi Jan. After various attempts at conflict detection, it turns out the reason I was getting strange ID conflicts was due to the baseline database (which was populated by the impact analysis). In the end I removed the baseline database from my AOS configuration, but since was unable to run a conflict project (without baseline/old objects), used the compare layers tool to create a project comparing syp and var layers (which listed all objects in both layers rather than just conflicts). – ac_cam Mar 05 '14 at 22:08
  • To enable me to make this an 'upgrade' project, I exported previous upgrade project definition to XPO and edited the XPOs in notepad (to change properties of the new project created from compare layers tool). This allowed me to imported my new syp/var project back into AOT and it was fooled into being an 'upgrade' project, allowing me to re-run the conflicts detection on all objects that existed in both layers. A bit of a hack, but it has worked and allowed me to solve the conflicts for CU7 ! Thank you all for your comments and suggestions. – ac_cam Mar 05 '14 at 22:09

1 Answers1

0

Migrate app between versions and then apply a XXX (SP or Cumulative Update or HotFix Rollup or anything else) is a bad idea. You will have to migrate again all develoments to that XXX new version.

I would make a standard app with all XXX, well compiled, against a empty data DDBB, and then import development layers with AxUtil (or with import option in AOS, but this can be slooow and set some standards pre-versions objects as custom developments), one per one (this will require a good development layer-focused design), and then upgrade developments to new versions. Partial imports of objects via AOT->import can be sometimes useful in some cases.

In your case, I would backup the _model database, and apply directly CU7 (this is, I would not use Detect Code Upgrade Conflicts' process), then compare SYP vs Old SYP layers (remember to input old objectos into BaseLine database, it is like the "Old" folder in app of previous versions. In the resulting project, focus in objects that are in development layers too, and solve differences via compare layers tool. One per one, ouch what a pain... then compile app, solve compile errors... then recompile app, recompile all CIL, sinchronize DDBB, and you should have it done.

Bull
  • 748
  • 1
  • 11
  • 24