Author Archives: Soren Klemmensen

About Soren Klemmensen

Another Microsoft Dynamics 365 Business Central geek

Build Numbering with Yaml

Many of you might have read some great blog posts from Freddy Kristensen on his blog. If not I can highly recommend reading through this blog series on how to get Azure DevOps setup to work with your Extension/App development for Microsoft Dynamics 365 Business Central.

Here is a list of the blogs released at this time:

Part 1Part 2Part 3Part 4Part 5

One of the things I was missing my self in this serie was to be able to change the way the build numbers are generated. Freddy used the default numbering which is YYYYMMDD.R where YYYY is the Year, MM the Month, DD the Day and R the revision number for any given date. This is the stamp the build is getting inside Microsoft Azure DevOps.

You can change this very simple with adding the following to the IC.yml file at the very top.

name: $(Build.BuildID)

Here I set the naming to the internal build ID generated by Azure DevOps, but you can of course also set it to something of your own choosing. The link blow gives you a huge selection of options for setting the build number differently.

This only resolves half the problem. If you are like me you would want to update the version number in the app.json file too.

I did that by adding a new script called “SetVersionNo.ps1” in the scripts folder.

$AppJsonFile = “.\app\app.json”
$AppJsonObject = Get-Content -Raw -Path $AppJsonFile | ConvertFrom-Json
$AppJsonObject.Version = $AppJsonObject.Version -replace “.{3}$”
$AppJsonObject.Version = $AppJsonObject.Version+$env:Build_BuildID + ‘.0’
$AppJsonObject | ConvertTo-Json | set-content $AppJsonFile

$TestAppJsonFile = “.\test\app.json”
$TestAppJsonObject = Get-Content -Raw -Path $TestAppJsonFile | ConvertFrom-Json
$TestAppJsonObject.Version = $TestAppJsonObject.Version -replace “.{3}$”
$TestAppJsonObject.Version = $TestAppJsonObject.Version+$env:Build_BuildID + ‘.0’
$TestAppJsonObject | ConvertTo-Json | set-content $TestAppJsonFile

This script updates the current version number I use “” by removing the last 3 digits and replacing them by the BuildID and “.0”

In other words if the BuildID is 1234 than the version number is set to “13.0.1234.0.

Again you can do your own thing here by using the link from above and build the version number in a different way.

The only missing is to add a task to the CI.yml file to execute the PowerShell Script as the first task. This is done by adding the following right after the “steps:” in the CI.yml file.

– task: PowerShell@2
  displayName: ‘Set Version No.’
    targetType: filePath
    filePath: ‘scripts\SetVersionNo.ps1’
    failOnStderr: true

This will run the PowerShell Script from earlier and automatically set the correct version number before building the Extension. One less thing for the developer to do manually.

We can agree or disagree if that is the right way of numbering an extension, however it works for me and I hope it inspire all of you to do your own thing.


Building Part 5: Updating your Build Definition for code signing

To update your build definition to also sign your code you need to edit it and add one more PowerShell task.

Here it is called SignApp and runs the new PowerShell script we added in Part 4

As soon as this is done and saved all future apps that are created via this build definition are signed and ready to deploy.

A special thanks to Mike Glue for sharing his great knowledge with me.

Building Part 4: Preparing your Build Server for Code Signing

In part 1 to 3 we have gone through all the steps needed in order to setup a build server to fully automatic build your app on commits from any developer.

Now we will prepare the build server so it can sign your app too.

On the build server download the Microsoft Windows SDK and install it.

If you don’t have a Code Signing Certificate you will need to go and get one.

Copy your Code Signing Certificate to your “ALBuild” folder as created in Part 2 of this blog series.

Now Copy the “SipDlls” folder and “RegisterNavSipForSigningNoContainer.ps1” from

“C:\ProgramData\docker\windowsfilter\<container>\Files\Windows\System32” or

on a development machine installed with docker to the “ALBuild” folder created in Part 2

Run “RegisterNavSipForSigningNoContainer.ps1” once to the dlls registered.

If these dll’s change in later releases this might need to be done again.

Now add a “signapp.ps1” to the script folder created in Part 2.

$filename = Get-ChildItem $env:Build_StagingDirectory -Filter *.app | Select-Object -First 1

$fileToSign = Join-Path -Path $env:Build_StagingDirectory -ChildPath $filename

Set-Location ‘C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64\’

.\SignTool.exe sign /f ‘C:\ALBuild\Scripts\<codesigningcertificate>.pfx’ /p <passwordforcodesigningcertificate> /t $fileToSign

This completes the needed changes to code sign your app on on your build server.

A special thanks to Mike Glue for sharing his great knowledge with me.

Building Part 3: Creating a Build Definition

In this blog I will describe the steps you need to take in order to setup a build definition in VSTS that will run on the Build Agent installed in Part 1 and 2 on a Build Server.

All you need here is a browser.

Login to your VSTS Team Project and click on Build and Releases.

Now click on “New” to create a new build definition.

Make sure to select the correct sources to be used for building your app.

Click on Continue and select “Empty process”

Now you can start editing your build definition.

The first thing to get done is adding a PowerShell script to “Phase 1”

You do this by clicking the “+” sign

Search for “powershell” and add a PowerShell task

Click on the new PowerShell tasks on your left and populate the task as seen in this screen shoot.

You are now almost done.

We just need to publish the Artifacts from the build definition which can be done the following way.

Add a new task to Phase 1 called “Publish Build Artifact” the same way we added the PowerShell task and populate it with the following parameters.

Now we are missing one more thing and that is to decide what triggers a build.

Personally I prefer Continuous Integration which means as soon as a developer commits any code into the branch selected for this build it will trigger a fresh build of the application.

You can set that up by clicking on “Triggers” and “Enable continuous Integration”

Save your build definition.

You are now done. Every time anyone does a commit to the git repository in VSTS a new build will happen.

Here is a screen shot of the first build for this scrip while it was running.

and after a successful build you can download your app from the Artifact tab under the build

The life as a developer just got a lot easier.

Have fun setting up your own Build Server.

A special thanks to Mike Glue for sharing his great knowledge with me.

Building Part 2: Prepping your build server for creating Apps from source

In this blog I will try and explain the minimum setups needed to prepare a build server to create builds.

In order to setup a build server, so a build script can assemble an app I do the following steps:

Create a folder called “ALBuild” on the C drive in the root.

Make a folder called “Scripts” folder under “ALBuild”

Create a PowerShell file in the Script folder called “build.ps1”.

Put the following code in the build.ps1 file:

$ExtensionAppJsonFile = “.\app.json”

$ExtensionAppJsonObject = Get-Content -Raw -Path $ExtensionAppJsonFile | ConvertFrom-Json

$Publisher = $ExtensionAppJsonObject.Publisher

$Name = $ExtensionAppJsonObject.Name

$ExtensionAppJsonObject.Version = ‘1.0.’+$env:Build_BuildID + ‘.0’

$ExtensionName = $Publisher + ‘_’ + $Name + ‘_’ + $ExtensionAppJsonObject.Version + ‘.app’

$ExtensionAppJsonObject.Version = ‘1.0.’+$env:Build_BuildID + ‘.0’

$ExtensionAppJsonObject | ConvertTo-Json | set-content $ExtensionAppJsonFile

$ALProjectFolder = $env:System_DefaultWorkingDirectory

$ALPackageCachePath = ‘C:\ALBuild\Symbols’

Write-Host “Using Symbols Folder: ” $ALPackageCachePath

$ALCompilerPath = ‘C:\ALBuild\bin’

Write-Host “Using Compiler: ” $ALCompilerPath

$AlPackageOutPath = Join-Path -Path $env:Build_StagingDirectory -ChildPath $ExtensionName

Write-Host “Using Output Folder: ” $AlPackageOutPath

Set-Location -Path $ALCompilerPath

.\alc.exe /project:$ALProjectFolder /packagecachepath:$ALPackageCachePath /out:$AlPackageOutPath


Make a “Symbols” folder under the “ALBuild” folder.

Copy the latest Symbols files from the build you are currently developing on. I assume everyone knows how to find these at this point.

You will need to update these as new builds are released.

Copy the bin folder normally found here:


on your development machine to the “ALBuild” folder on your build server.

The version might be different, but this is part of the extension installed in VSCode. You will need to update this when a new version is released of the AL extension for VS Code.

This is it. The build server is now complete and has all the components needed to run builds. In Part 3 we will show you how you can configure a build in VSTS via your browser

A special thanks to Mike Glue for sharing his great knowledge with me.

Building Part 1: How to setup a Build Agent in VSTS

If you are already using Visual Studio Team Services (or VSTS) for your Source code management you can setup a Build Agent to create automated build.

In this blog I will try and explain how.

Starting from a freshly installed Windows 2016 Server (Nothing else installed) log into your Team Project and click the settings

Than select “Agent Queues”

An option to download the Agent will now show.

Download the Agent

Now install the agent by following the instructions

A few things to know and find before you do the install.

You will need a token which you can find by clicking on you picture

Followed by Clicking on Security

Now click Add and create a new Token.

Make sure you save the token value in a safe space as you will not be able to see it again.

This is it. If you followed the instructions you should now have a working Build Agent installed on your build machine ready to create builds for you on demand.


Building Intro: Getting started with automated builds

For several years I have been talking about Source Code Management and its many benefits. Luc van Vugt has been doing similar things and lately another brother in arms Mike Glue who I have know for many years from my time at IndustryBuilt has joined.

This intro is to kick of a series of blog posts around the area of Building, signing, testing, deploying with more of your code.

We want to show off some of the many things you can make happen and automate for your development team.

We hope you enjoy and look forward to hear all your feedback.


Dynamics NAV SCM in Visual Studio Code

Ever since last year I have wanted to do something inside Visual Studio Code for Source Code Management of Standard Dynamics NAV development.

Why? (You might ask.)

Well Microsoft has introduced Visual Studio Code as the next generation editor at several conferences in 2016. Creating tools in Visual Studio Code that can help manage your Source Code for the existing version might help migrate developers to Visual Studio Code and get use to it before the next version is released.

That said I have also been looking at how to make the entry in to Source Code Management as easy as possible. Many developers are still not using any kind of SCM, something I really have wanted to change for several years, and I think the main reason is the knowledge and time to get started and get setup is just too high. Developers simply give up before they get started.

So what to do about it?

In the last months I got talking to a few developers at Elbek & Vejrup in Denmark that were looking to explore SCM and get their teams up to speed. We discussed the options and we agreed on VS Code as the way forward.

This project has been underway for a while now and we are almost ready to release version 1.

If you are interested in reading about it, contributing or following please feel free to follow the project hosted by my friends at Cloud Ready Software on GitHub

You can also install and play with what is already there by installing the following extension for Visual Studio Code.

When done we hope you just need to install VS Code and the extension and with minimal knowledge of Source Code Management you are up and running with your Code in place in a Git Repository.

We look forward to every ones contributions.

Happy Code. Safe Code.



Moving to WordPress

So it happened. I moved my blog to WordPress. Not that I did not like Office 365’s public site and all the great options that it gave me. Quite the opposite. The simple fact is that Microsoft is about to retire this option, so I just need to get it done before that happens.

I hope you will continue to enjoy my blog.