Merge-NAVApplicationObject - how reliable is it?

greatscott001

I have always been skeptical of automatic merge tools. I have used the Merge-NAVApplicationObject and it seems to work okay. My question is are there any horror stories out there about this process NOT working. I know about the VersionList issue and can deal with that. I also know that the online documentation is not completely accurate about what some of the options do. What I am wondering is, have there been any cases where the merged result was simply wrong. Wrong and doesn't compile I can at least resolve but wrong and compiles is a very bad thing. I have spotted checked the results I have gotten and it seems okay but I have a project coming up with some major modifications in a lot of base NAV objects (300+). Will the merge work and I can just stop worrying or are there instances where things are just broken afterwards?

Looking for a little reassurance here.

Kowa

I use it all the time for the monthly updates.
Make sure you always use the latest version, the early ones had some bugs.

The only big issue is with outcommenting with curly brackets in source code. Never used in standard objects, but if you merge an unknown database this might cause conflicts to be overlooked:
https://grumpynav.wordpress.com/2015/01/26/caution-the-merge-cmdlets-might-merge-incorrectly/

For the Version List there are lots of solutions around, some links here (German forum), I always use mine
http://www.msdynamics.de/viewtopic.php?f=17&t=25131&#p105917

lynge

I've been using it several times and have not seen any problems yet.

zohaibu95@hotmail.com

From which version to which version you want to upgrade?
I have upgraded from NAV 4.00 to NAV 2016 and my step by step guide is attached with this post.
I have used Merge Tool for this rather than Powershell utility. Trust me merge tool is great. at least you know what you are doing.

Mergetool is best if you have a lot of customization in Standard objects.

Please have a look and feel free to ask if you have query.

Kowa

I use it all the time for the monthly updates.
Make sure you always use the latest version, the early ones had some bugs.

The only big issue is with outcommenting with curly brackets in source code. Never used in standard objects, but if you merge an unknown database this might cause conflicts to be overlooked:
https://grumpynav.wordpress.com/2015/01/26/caution-the-merge-cmdlets-might-merge-incorrectly/

For the Version List there are lots of solutions around, some links here (German forum), I always use mine
http://www.msdynamics.de/viewtopic.php?f=17&t=25131&#p105917

tbkkl

I also have quite some "unexpected" behavior at least. Maybe some of you could confirm it:

I do have a Project NAV 2013 R2 up to 2017. So far so good. The solution currently running of course has some changes inside. So i do have the following things prepared for the merge:
ORIGINAL: NAV 2013 R2 (as it comes from the DVD)
MODIFIED: NAV 2013 R2 + OurSolution v.6 + Mods
(now the first Tricky one): TARGET: NAV 2017 + OurSolution v.8

This Works for the most of the Objects just fine. but now it happens: since 2013 has passed by for a long time the "OurSolution v.6" is not really a v.6 any longer it has been changed to a v.7 for example. now v.7 and v.8 share some Objects (let's call it stuff from v.8 had been downgraded to v.6/7).

So it happens that in the ORIGINAL Folder I do miss an Object (from OurSolution) as it simply does not exist there! While the TARGET and the MODIFIED have it.

The result is somewhat messed up. It looks like that the system "flips" TARGET and MODIFIED. The Result file looks more as the MODIFIED as the TARGET. in worst case it kicked away new functions from the TARGET File.

Can anybody try this out or confirm this? And if possible, does anybody has an idea/solution to it?
Would have a two step merge worked better? first go up to NAV 2017 basic and afterwards merge the result with OurSolution?

zohaibu95@hotmail.com

tbkkl wrote: »

I also have quite some "unexpected" behavior at least. Maybe some of you could confirm it:

I do have a Project NAV 2013 R2 up to 2017. So far so good. The solution currently running of course has some changes inside. So i do have the following things prepared for the merge:
ORIGINAL: NAV 2013 R2 (as it comes from the DVD)
MODIFIED: NAV 2013 R2 + OurSolution v.6 + Mods
(now the first Tricky one): TARGET: NAV 2017 + OurSolution v.8

This Works for the most of the Objects just fine. but now it happens: since 2013 has passed by for a long time the "OurSolution v.6" is not really a v.6 any longer it has been changed to a v.7 for example. now v.7 and v.8 share some Objects (let's call it stuff from v.8 had been downgraded to v.6/7).

So it happens that in the ORIGINAL Folder I do miss an Object (from OurSolution) as it simply does not exist there! While the TARGET and the MODIFIED have it.

The result is somewhat messed up. It looks like that the system "flips" TARGET and MODIFIED. The Result file looks more as the MODIFIED as the TARGET. in worst case it kicked away new functions from the TARGET File.

Can anybody try this out or confirm this? And if possible, does anybody has an idea/solution to it?
Would have a two step merge worked better? first go up to NAV 2017 basic and afterwards merge the result with OurSolution?

First of all make sure that your old version, customized version and target version all are of same region. Secondly, use merge tool for 3 way file comparison.

tbkkl

Well I do use the Merge-NAVApplicationObject if this is what you are talking about. I kindly ask you to phrase the stuff as it is called by MS so everybody understand

And as I wrote: i do NOT have a old version for the Objects in question (ORIGINAL is empty) I only have files in Target and Modified. and they are different. so the Merge has to do something.

janpieter

I've seen strange results on pages that were heavily customized by us where all custom page controls were grouped together. I think this was because a standard NAV control has moved to a different group, this totally confused the PS merge. I'd rather have the PS merge throwing me error's then trying to solve complex problems.

Other then that, currently no problems. We rely on it to update our modules with Microsoft rollups, and also to update our customers with newest version of our modules.

davmac1

The biggest problem is when Microsoft refactors the code - e.g. codeunit 80 - and the before and after from the Microsoft versions are too different.
In newer releases we can start using events more to remove custom code from the objects. Eventually extensions should allow complete removal of all customizations and still provide the developer view of the code in the extensions - I am guessing that will happen in the year 2020.

EvR

Actually, usually the biggest problem is the developer who's made customizations. It all depends on how cleanly you've customized in the past. If you've made a big mess and did not pay any attention to proper architecture and design, then it will most likely laugh at you If you've taken the time to do things properly then it will be of great help to you.