Naming your Objects when coding AL for Business Central

Some tips and tricks in naming your objects well while developing code for Business Central.

First you need a pre/post fix from Microsoft. Well you only need this if you are developing things that go into AppSource, however just get it, so we don’t have conflicting objects out there.

So why is this important. Well if 2 objects have the same name one of the 2 extensions cannot install and we will have an issue.

So lets look at how you should name your objects.

First you get your pre/post fix from Microsoft. In my case this could be IB. You would than think I can create an object named IBSetup or SetupIB and I would never have a conflict. Well they assumption is that you likely would develop more extensions at your company, so this is not quite enough. Let’s say I am developing a Label extension. Well in that case I could reserve IBLBL as my prefix IB required my Microsoft and LBL I can track internally as my Label extension. If I now have a Setup object I can call it IBLBLSetup and I know it is unique.

Well that is a little hard to read in my book so I prefer IBLBL_Setup. Why underscore is a good idea is because I don’t need quotes around the name as you would if you selected to use a dot. “IBLBL.Setup” If you use underscore you can also quickly double click the variable to mark it up if needed something that doesn’t work if you use a dot. I use that all the time when I need to copy a variable.

Last but not least prefix or post fix. Why not call it Setup_LBLIB. (Beaware the IB must be first or last.) Personally I prefer post fixes but it is just something you need to agree on company wide as mixing these up just creates total confusion.

We use prefixes because that was decided at some point and we are not about to change it.

Field names should be treated the same however you only need to follow the standard for fieldnames that are extending existing objects. If the object is all yours pre or post fixes are not needed.

Hopefully this helps some of  you in naming your objects in good ways when you start extension development.


Developer Preview – February 2019 – Full AL – Love it.

Some great news. The new Developer Preview is fresh out and this time there is BIG news.

The biggest announcement this month is that we are publishing a preview of the base application fully on AL language.

Yes it is finally here. I know I will be setting this up tomorrow and testing all builds and test scripts are running like a charm so we can move our development over to this version right away.

Amazing work Microsoft and looking forward to get this one rolled out to our teams.

If you want to read more take a look here:

What else is new:

Rapid Application Development RAD. A way to quickly publish and test during development.

New schema update mode – ForceSync

Debug without publiching

Debugger info for http, json with more

Code Actions – this looks pretty amazing and something I need to test right away. If what I read is accurate this will help a lot in our code converting projects.

TableRelation Extensibility… Oh yes something we have needed often

Views and Defining views in AL. Looking at this for the first time it does seem not to be the kind of views I was hoping for, but still an interesting concept.

There is a number of other minor things, but all in all we are moving quickly and fast towards the future.

See you back to the future we go.

Adding the Test App to the Artifacts

In my previous post ( 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’
    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.


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



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.