Dynamics NAV 2016: Codeunit 1: Version and Build No.

Each and every time Microsoft sends out a new version or cumulative update (CU), then there is always one object that has been changed and that’s codeunit 1. This is where Microsoft is hard coding the Dynamics NAV version and build no.

But it codeunit 1 is also where most ISV’s and sometimes the partner is putting their build no.’s. This caused that whenever you where merging your code, to upgrade your solution, the codeunit to show as a conflict.

This is how the three functions in question looked until Dynamics NAV 2015. Typically the ISV’s would also add their build and version directly to the text strings, just like Microsoft.


ApplicationVersion() : Text[80]
EXIT('DK Dynamics NAV 6.0 – MyApp 1.0');

ApplicationBuild() : Text[80]

BaseApplicationBuild() : Text[80]

Since the Dynamics NAV 2016 release, Microsoft have listened to the community voices and have changed the way this is done. You no longer have to change codeunit 1 to update the application version. The functions in codeunit 1, now looks like this: 


ApplicationVersion() : Text[80]
AppVersion := CustomApplicationVersion('DK Dynamics NAV 9.0');

LOCAL CustomApplicationVersion(BaseBuildVersion : Text[80]) : Text[80]

ApplicationBuild() : Text[80]

LOCAL CustomApplicationBuild(BaseBuildNumber : Text[80]) : Text[80]

Update application version via event subscriber

In NAV 2016, you can use an event to update the application version text showed in the “About” window. By creating a function in your own code, that subscribes to the OnAfterGetApplicationVersion event. That way you don’t have to change codeunit 1, when you have a new version of your product.

LOCAL [EventSubscriber] OnAfterGetApplicationVersion(VAR AppVersion : Text[80])
AppVersion += ' - MyApp 1.0';

The function subscribes to the OnAfterGetApplicationVersion event in codeunit one.




Update application build no. via Custom function

There is no event for updating the build no. So if you need to update the build, then there is no way around changing codeunit 1. My personal advise would be to drop your own build no. into the application version line and leave codeunit one alone. And if you still want to do it, then do you can use the CustomApplicationBuild function.

LOCAL CustomApplicationBuild(BaseBuildNumber : Text[80]) : Text[80]
EXIT(BaseBuildNumber + ‘/MA123);

By adding your own build no. to the CustomApplicationBuild function, instead of the ApplicationBuild function, the result is that there is no direct conflict when merging, even if you did change the codeunit. The merge tool will be able to handle it for you.

If you are adding your build no. using the custom function, then you cold also use the same method to update the application version. Here you see the CustomApplicationVersion function, that can be updated the same way.

Why is this important?

The less potential conflicts you have in the code, as a result of your customizations. The smoother and easier are your upgrades. Every time you have a conflict, when merging your customizations to the newest version of NAV, then you have to “manually” do something to resolve that conflict. If you code smart, then potentially you have no conflicts when upgrading, and can run a fully automated upgrade.