Code Upgrade: Merging Version Lists
Merging cumulative updates into your own Microsoft Dynamics NAV solutions has become a lot easier with the new merge utilities. They are based on the concept of three-way merge to reconcile two sets of changes made (independently) to a given base version. For example, when applying Microsoft Dynamics NAV 2015 Cumulative Update 1 to a customized database, the customized database and the cumulative update are both derived from Microsoft Dynamics NAV 2015 RTM, which is the shared based version in that case.
There is one aspect, though, that raised quite a few questions from the community and that is merging of the Version List object property. Out-of-the-box the merge command offers only very limited support to handle this. You can either choose to clear the version list or take the version list from the modified or target object. Since the Version List is just text, we couldn’t really assume how it is used generically and provide corresponding merge capabilities. However, the Merge-NAVApplicationObject Windows PowerShell cmdlet provides very rich output, and in combination with the command for setting object properties it is possible to deal with version lists any way you like.
What appears in the PowerShell console when the Merge-ApplicationObject cmdlet completes is just a summary. The cmdlet actually returns a collection of objects that each contain information about a merge. To inspect what information is available, you can assign the result to a variable and use the Get-Member comman, as shown in the following code snippet:
$m = Merge-NAVApplicationObject …
$m | Get-Member -MemberType Properties
TypeName: Microsoft.Dynamics.Nav.Model.Tools.MergeInfo
Name MemberType Definition
—- ———- ———-
PSPath NoteProperty System.String PSPath=
Conflict Property Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Conflict {get;}
Error Property Microsoft.Dynamics.Nav.Model.Tools.ErrorInfo Error {get;}
Id Property int Id {get;}
MergeResult Property Microsoft.Dynamics.Nav.Model.Tools.MergeResult MergeResult {get;}
Modified Property Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Modified {get;}
ObjectType Property string ObjectType {get;}
Original Property Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Original {get;}
Result Property Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Result {get;}
Target Property Microsoft.Dynamics.Nav.Model.Tools.ApplicationObjectFileInfo Target {get;}
The output of the merge is a collection of MergeInfo objects. Each MergeInfo object represents a merge operation for an application object and contains information about the original, modified, target and result objects. As such, the MergeInfo objects give us access to the original, modified, and target version list, such as:
$minfo = $m | select -first 1
$minfo.Modified.VersionList
Assuming that given the three input version lists we can determine the desired version list for the merge result, we can define a function that takes such a MergeInfo object to calculate the resulting version list:
function New-NAVVersionList($MergeInfo)
{
…
}
Before we implement this function, let’s first see how we could use it. The Set-NAVApplicationObjectProperty cmdlet updates the object properties (including the version list) for all application objects in a text file:
Set-NAVApplicationObjectProperty -TargetPath objects.txt -VersionListProperty ‘v1’
When we iterate over all MergeInfo objects, we can use this command together with the New-NAVVersionList function to update the version list for each object in the merge result:
foreach($mInfo in $m)
{
$versionList = New-NAVVersionList $mInfo
Set-NavApplicationObjectProperty -TargetPath $mInfo.Result -VersionListProperty $versionList
}
What remains is the implementation of the function that actually calculates the new version list based on the version list of the three inputs (original, modified, and target). For instance, to simply concatenate modified to target:
function New-NAVVersionList($MergeInfo)
{
# MyCustomVersion,TheirModifiedVersion
“$($MergeInfo.Target.VersionList),$($MergeInfo.Modified.VersionList)”
}
How version lists are often used is that for each add-on or customization for which an application object is changed a version tag is added (separated by comma). In turn, each version tag typically consists of some product code and a version number. For example a Microsoft Dynamics NAV 2015 W1 object that was customized for my add-on (MY) and their add-on (THEIR) could get version list: NAVW18.00.00,MY1.1,THEIR6.2. Note that the version number for the NAV version tag is composed of a major, minor, and build number. The build number is typically updated in the case of cumulative updates.
When merging an update into your code any version tag might be updated or new version tags might be added. The result of merging version lists should contain one tag for each product code that occurs in the modified and target version lists and it should be the tags with the highest version number for that product code. With these requirements our New-NAVVersionList function becomes this:
function New-NavVersionList($MergeInfo, [string[]]$ProductCode = ‘NAVW1’)
{
$allVersions = @() + $MergeInfo.modified.versionlist -split ‘,’
$allVersions += $mergeInfo.target.versionlist -split ‘,’
$mergedVersions = @()
foreach ($code in $ProductCode)
{
# keep the “highest” version tag for $code
$mergedVersions += $allVersions | where { $_ -like “$code*” } | sort | select -last 1
# remove all $code version tags
$allVersions = $allVersions | where { $_ -notlike “$code*” }
}
# return a ,-delimited string consisting of the “highest” versions for each $ProductCode and any other tags
$mergedVersions += $allVersions
$mergedVersions -join ‘,’
}
This function was brought to you by Bas Graaf.
On behalf of him and the rest of the Dynamics NAV team, your blog editor wishes you all Happy Holidays!
