Did you all see the newest addition to the Dynamics NAV family?

With the release of Cumulative Update 9 for Dynamics NAV 2013 R2 an entire new set of tools came out. These tools are all about merging of your objects. As many of you know I am a big advocate for Team Foundation Server for both Source Code Control and management of Product Development, so my first thought is: “How does this fit into my current setup?”

The answer is simple: “The tools fit just perfect.”

For those of you that remember far enough back in time many, attempts have been made to merge NAV efficiently by Microsoft/Navision. Back in time we had NDT (Navision Development Tool) yes it was not a success to say the least. Many have used tools like WinMerge, Araxis, and many others for doing pure text based merges. This is also what is standard in Team Foundation Server/Visual Studio. None where a huge success because none of them understand the Dynamics NAV object model or syntax, but they still made it work. Then of course we haveMergeTool which without a doubt has been the most successful tool of them all.

Microsoft is back…

With this new set of tools Microsoft is back in the game of creating tools to help the Microsoft Dynamics NAV partner channel creating outstanding and upgradable products. The biggest difference between all pasts and current attempt is that this tool understands the Dynamics NAV object model and syntax which opens up a range of possibilities we never could have dream of in the past.

So how does it work and how good is it?

Let’s look at what is included in and how it works.

File naming

First we need to understand what basis the tools works on. Yes the tools work on text based version of the object of course. No fob files here. Any type of merge needs a certain amount of human interaction and as binary (such as fob files) is pretty hard to read (yes that was a little bit of sarcasm) the better option is text based files.

The file naming from all output from these tools is pretty simple. The first 3 letters in the Object Type in upper case than the number followed by “.TXT” in uppercase. In other words Codeunit 1 is COD1.TXT, Table 15 is TAB15.TXT, Page 5050 is PAG5050.TXT and so on. If you don’t use this naming conversion today you should consider making a change unless you want to develop & run some renaming scripts in all future.

We can discuss the naming to death and I am sure people will complain, but just get on board. This is just a standard going forward and why should we not all follow the same standard?

Split & Join

The first 2 PowerShell cmdlets I am going to look at are Split-NAVApplicationObjectFile and Join-NAVApplicationObjectFile. Yes you properly guessed it. The 2 cmdlets are meant to split a text file export of NAV object into individual files or Join them back together.

Why is this important and a logic thing to do?

Well if you are doing any kind of Source Code Management you will need to have the individual objects on their own, so you can see the difference from check-in to check-in and between versions. This is just what Source Code Control systems do.

If you don’t, but want to know more about Source Code Management I would suggest you watch my 3 videos that introduce the cloud version of Team Foundation Server to any NAV developer. You can find them here:http://www.youtube.com/user/SorenKlemmensen/videos

When you split a file I always recommend that you strip it of the object properties as they have no value as part of a merge or a source code control system. These tools give you complete control of this which is a great improvement for developers.

Compare, Update & Merge

The 3 next cmdlets to look at are Compare-NAVApplicationObject, Update-NAVApplicationObject and Merge-NAVApplicationObject.

Compare-NAVApplicationObject looks at 2 sets of application objects and creates a set of delta files of the differences. One file per object that has differences. It can be very interesting to look at and will in many cases give you a good idea of the workload it will take to do the upgrade.

Update-NAVApplicationObject takes the set of delta files created by Compare-NAVApplicationObject and applies it to another version of objects. So basically it updates a new set of files with the changes found by the Compare-NAVApplicationObjects

Merge-NAVApplicationObject does the Compare and update in one command.

Both Update and Merge creates a set of files with merged objects. Any Conflicts are identified in conflict files with extension “.CONFLICT” which makes them easy to find and view in file explorer. It also gives us a wide range of options for getting the issues fixed by a distributed group of developers as these conflicts can be checked in to source control and assigned to individuals for resolution if that is what it calls for.

All of the commands above can take object input from a folder full of individual object or from a single file containing multiple objects. The tools don’t care but will always deliver the result in a folder as individual objects.

Get and Set Object Properties

The last 2 cmdlets are Get-NAVApplicationObejctProperty and Set-NAVApplicationObjectProperty and yes they are meant to get and set the individual objects Properties such as VersionList, Modified, Date and Time.

I always recommend that you don’t have or track the Object Properties in your source code control system. If you are building a product the only time you need to know the VersionList is if you run a build (and that can be discussed) or if you create a new version for release. In your daily work the developers don’t care and don’t need to know Date, Time, Modified and VersionList. They are just distractions that give them false differences when they compare and look for changes in the source code control system such as Team Foundation Server. The only thing the developers need to know is what version of the Source Code they are currently working on which in the world of Team Foundation Server means what ChangeSet are they currently on.

Conclusions

I have tested the tools and they are very fast. Full merges take minutes instead of hours. The conflicts are few and far between. The tools really have a great logic as to what needs to go where. What is more impressive is that many of the issues that typically killed you when you did merges before are now made easy. Dealing with Control ID issues. Who has not been pulling his hair trying to get that resolved and the files imported? Issues like splitting the object into individual files, which is a must if you want to do source code control, is now a standard tool in PowerShell and not a 3^rd party tool, like the vb script I have shared on my blog ,which again is just one of many others.

If you are serious about development and Source Code Control this tool is a huge step forward not only for the partners that are creating repeatable software, but for the entire partner channel.

You can read much more about the tools on the Microsoft Dynamics NAV Team Blog.