Author Archives: Soren Klemmensen

About Soren Klemmensen

Another NAV geek

Adding the Test App to the Artifacts

In my previous post (https://klemmensen.ca/2018/11/27/build-numbering-with-yaml/) I expanded the scripts Freddy has created with the ability to number the builds and the compiled app (artifacts) automatically.

Another little thing I noticed was that Freddy’s script doesn’t store the Test App in the Artifacts, however as many of us need to upload the finished product to AppSource we need the Test App too.

This can be accomplished by a simple little change to the “CI.yml” file.

Add this

– task: PublishBuildArtifacts@1
  displayName: ‘Publish Artifact: TestApp’
  inputs:
    PathtoPublish: ‘$(Build.ArtifactStagingDirectory)\test’
    ArtifactName: TestApp

right after the “Publish Artifact: App” task which currently is the second last task in Freddy’s version of the “CI.yml” file.

The test app will now show up under the Artifacts when you click the drop down arrow.

ArtifactsDropDownWithTestApp

As always I hope this helps you getting started with Azure DevOps and Source Code Management.

Enjoy,

Soren

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.

https://docs.microsoft.com/en-us/azure/devops/pipelines/build/options

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 “13.0.0.0” 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.’
  inputs:
    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.

Enjoy.

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
“C:\ProgramData\docker\windowsfilter\<container>\Files\Windows\SysWOW64”

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 http://timestamp.verisign.com/scripts/timestamp.dll $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:

“C:\Users\<username>\.vscode\extensions\Microsoft.al-0.14.17461”

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.

Enjoy