To import the old base version, follow these steps:

We will now import our old customized database, that is, the OldCustom.txt file:

When importing the old custom version, we have selected a version in the Based on Navision Version Code and Compare Old Version fields and have also selected Delete Equal Objects because this will allow us to concentrate only on the customizations done on the base code.

By selecting Based on Navision Version Code, the import process will skip those objects in our custom version that do not exist in the base version. The objects that exist in a custom version but do not exist in its base version are objects that have been created for the customization. You don't need to compare them to anything; you will just import those in the new custom database. That's why we skip them.

By selecting Compare Old Version and Delete Equal Objects, the import process will first compare the custom objects against those in the base version and, if they have not changed at all, will skip them. As we saw in the first import process, a Microsoft Dynamics NAV database has thousands of objects. In a customization, probably not all of them have been customized. Probably only a few dozens or even some hundreds of objects have been modified, but all 7,000 objects are not customized. We want to skip objects that have not been modified because we want to concentrate only on those that have actually been modified.

Once the old custom version has been imported, compared against the old base version, and equal objects have been deleted, our old custom version has only 927 objects. Only 927! We don't need to go through all 4,232 objects for the application code upgrade. We only need to concentrate on those 927 that have actually been modified. That's great! That will save us a lot of time!

But we can further reduce these 927 objects by a little. How is that? Well, sometimes it happens that you open an object in the design mode through the Object Designer page because you want to check something. You finally leave the object without modifying anything at all, but the editor asks you whether you want to save the changes made to the object or not. If you say yes, the object properties such as Date and Time will be modified. Since there is something that has changed, even if it's just those object properties, MergeTool determines that you will have to compare and merge those objects. Wouldn't it be great to be able to delete those objects from comparison so that only real modifications have to be compared and merged?

This is possible with MergeTool. That's cool, right?

Let's see how to delete objects that have only object property changes (date, time, and version list):

Now it is time to import the new base version, that is, the NewBase.txt file.

Let's first compare the old base and new base versions:

Take a new look at the Versions list. Contrast fields have been updated. A contrast is a group of code lines that have some differences (change in code, added code, or deleted code) respective to the two versions. MergeTool does not treat modifications on a line-by-line basis. It actually treats modifications as groups of line codes.

Imagine that the modification in an object consists of creating a new function with hundreds of code lines and a call to that function from within the same object. There aren't hundreds of modifications for the hundreds of code lines added. There are only two modifications: added code for the definition of the function and added code for the call to that function. It's easier to deal with two modifications than with hundreds of modifications. And that's what MergeTool does.

MergeTool groups contrasts in Contrast Headers. There is one contrast header per object in the new base version. Each contrast header may have several contrasts inside.

NEWBASE was compared against OLDBASE and it tells us that there are 182 contrasts:

We can navigate to the contrast to analyze the differences. To do so, click on the type of contrast you want to analyze (for all, click on the Contrast Headers field; for equal contrasts, click on the Equal Contrast Headers fields; for changed contrasts, click on the Changed Contrast Headers field; for new contrasts, click on the New Contrast Headers field) and the list of contrasts will be shown. Select then the specific contrast you want to analyze and click on Lines (log), which can be found on the ribbon bar.

We can see what a contrast looks like. The code lines in green remain the same in both the versions (Line Status is Equal). The code lines in red tell us what the code was in the old version (Line Status is Before). The code lines in orange tell us what the code is in the new version (Line Status is After).

In the example, a line of code has been replaced by three lines of code. The three lines of code are involved in the change but there is only one change—a local variable has been defined for an action in Page 143 Posted Sales Invoices.

In the Contrast Headers list, we can see how many groups of changes exist between the two versions. In the example, we have 182 contrast headers (objects) with a total of 4,018 groups of changes: 330 changes in properties groups, 2,368 changed groups, 893 inserted groups, and 427 deleted groups.

We definitely do not want to deal with all 4,018 groups of changes by manually looking at all the differences in code. We want MergeTool to deal with them automatically and just let us decide on those that cannot be merged automatically by the application. That's what we are going to do in the last part of this section.

We will go back to the version list page of MergeTool and we will follow these steps:

The first subpage corresponds to the old base code. Earlier, we had the assignation of a value to a field, then a record was inserted into the database, and finally the call to a function to store document dimensions.

The second subpage corresponds to the new base code. In the new application code, there is an extra code line between the assignation of a value to a field and the insertion into the database, and the call to a function to store document dimensions has disappeared.

The third subpage corresponds to the old custom base code. To see the whole customization, we will have to scroll through the subpage. The customization consists of a group of 11 code lines added between the assignation of a value to a field and the insertion of the record into the database.

The fourth subpage corresponds to the new custom code. There is a conflict. The custom code inserts the code lines in a specific place and the new code inserts different code lines in the same place. MergeTool cannot automatically merge this because the tool cannot decide if only the custom-added code lines have to be inserted, if only the new code lines have to be inserted, or if both the added code lines have to be inserted in the new custom version; and, in this case, in which order.

Let's take a better look at the fourth subpage, at the proposal made by MergeTool in the following screenshot:

As you can see, the merge proposal consists of using only the customized code. Even the old call to the StoreDocDim() function has been used in the custom-merged code. MergeTool has made this proposal because of the option Default Manual Merge Lines used in the merge options, which we left to its default value, Custom. That is, we have actually told MergeTool to use the custom version for the first proposal when merging lines manually.

In this particular example, we actually want both the groups of added lines (the ones coming from the old customization version and the ones coming from the new base version) to be added to the new customized version, and we want the call to the function to be deleted from the new customized version, as this function is no longer available in Microsoft Dynamics NAV 2013 because of the dimension functionality redesign.

The way to move the code lines from any version to the new customized version in MergeTool is through the New Line Number field that can be found in any of the subpages. If there is a number in the New Line Number field in any line code of the three first subpages, which correspond to the three code versions used for the merge process, that line will show up on the fourth subpage, in the new customized code. The number used in this field will determine the order in which the code lines will be shown in the fourth subpage.

In this particular example, we want to do the following:

Once we are done with the whole merge process and we have a good new custom version, we can go back to the MergeTool versions list and export this version as a .txt file. To do so, there is an action in the Actions tab of the ribbon bar, called Export Object Text File. Select NEWCUSTOM as the version to export and select a destination folder and file name.

The last part of the merge process is to get a new database, with all the new objects, and import into that database the .txt file we have just exported with the customizations merged into the new code version. After importing the .txt file, we will have to compile all the objects and solve any additional issues that may exist.

And that's it! We have a brand new full application code with standard objects for all those objects that we have not modified in the old version and with the customizations carried out to this new version.

We still have to import into this new database the new objects created in our customization. To do so, we will first have to do the following: