Delivering the Expected - Solteq Developer Blog

The story of a one (Microsoft Dynamics NAV) extension

Journey planning

You can read a lot about extensions on the web. Just note that if you start googling for “NAV Extensions” you will see some web sites describing Extensions in the first version — so called Extensions 1.0. Now we have Extensions 2.0 released. Although the main idea is the same, in practice the approach and tools are completely different. 2.0 is completely different approach. A recommended article to learn where to start with AL is Microsoft’s Getting Started with AL. Although it is referring to Dynamics 365, almost everything applies to Dynamics NAV 2018 as well.

Since Extensions is now a viral topic in Dynamics/NAV world, I also recommend to follow the twitter. Check #MSDynNAV, #Nav2018, @waldo1001, @msstanst

The moment you decide to start yours journey with the extensions, you must add this: to your bookmarks. It contains not only code samples (better to start with sample code, than starring at blank screen and figuring out how to make your own hello world extension), but what is perhaps even more valuable Issues and Wiki tabs from which you can search for frequently asked questions and find solution to the issue you are facing.

But then you really want to get your hands dirty with code, because as someone said:

“In theory, there is no difference between theory and practice. But, in practice, there is.” Jan L. A. van de Snepscheut

So that’s why we were encouraged to start learning by doing and this blog post describes briefly our journey to the first extensions.

The very first working extensions

Let’s start!

In Solteq we deliver tomorrow’s solutions today, so according to our mission and following the idea of learning by doing, we noticed that we had some NAV modifications that are frequently used by almost all of our customers and it would be great if we could convert them to extensions (2.0). Therefore we had identified few good candidates for extensions, created a team dedicated for that task and this is how our journey has began.

To be more precise, our old modifications had been implemented mainly in NAV 2015 (but also already moved to NAV 2016 and even NAV 2017), and targeted version was Extension 2.0 for NAV 2018 (on prem).

First task was to convert some reports. Having in mind that the extensions 2.0 programming concept is still in development, it is always worth reviewing old modifications and doing some research to find out whether it will be feasible to convert it to extension. Fortunately, reports are supported so we did not expect any major issues with that.

Get your hands dirty with code!

First things first. You need tools, so you install Microsoft Dynamics NAV 2018, then Visual Studio Code, and then what else? Actually nothing else is needed, you just clone repository from and open it in Visual Studio Code. You also might guess or know that to open this you need Visual Studio Code extension that supports new AL language. Chances are that following your intuition you try to search in the Extensions marketplace for AL language, but… just don’t do that!

AL extensions in VSC

If you are developing extension for NAV 2018, you must use the extension that was installed together with NAV 2018. By default it is located in C:\Program Files (x86)\Microsoft Dynamics NAV\110\Modern Development Environment\ALLanguage.vsix, so instead of installing app from the Marketplace, in the Visual Studio Code and in the Extensions panel, click on three dots in the right-upper corner and select Install from VSIX option.

The next important thing is to check and update launch.json file (located in the project folder, “.vscode” subfolder). If you have all default options when installing NAV, then launch.json should look like this:

    "version": "0.2.0",
    "configurations": [
            "type": "al",
            "request": "launch",
            "name": "Your own server",
            "server": "http://localhost",
            "serverInstance": "DynamicsNAV110",
            "authentication": "Windows"

Only after this is in place, symbols can be downloaded (most likely the message will pop up at the top of the VS code screen) and after symbols are downloaded you are ready to press F5 key to start debugging. It will actually: compile, publish, install extension and start web client in the debug mode.

If you see error message complaining about debugger, make sure NetFx40_LegacySecurityPolicy is enabled (more details here ).

Object Conversion

After the sample extension was successfully deployed, it is now time to do something useful. As mentioned before, our first task was to make extensions out of reports from NAV 2015. It turned out that normally if you don’t develop a brand new extension, but rather convert old code, the process is the same and it consists of the five following steps:

  1. Move objects to NAV 2018 development environment (txt or fob files). Use separate database, not the one where you are developing extensions.
  2. Export object(s) to text file using new syntax: (using NAV development shell): Export-NAVApplicationObject -ExportToNewSyntax -DatabaseName "Demo Database NAV (11-0)" -DatabaseServer "SQL_SERVER_NAME" -Filter "Type=Report;ID=50000..50004" -Path "C:\Users\Dawid\Documents\ReportsExt\reports2018.txt" This will export one txt file.
  3. Split objects to separate txt files: Split-NAVApplicationObjectFile -Source "C:\Users\Dawid\Documents\ReportsExt\reports2018.txt" -Destination "C:\Users\Dawid\Documents\ReportsExt\cal"
  4. Convert txt files to al files using txt2al (in Powershell): cd 'C:\Program Files (x86)\Microsoft Dynamics NAV\110\RoleTailored Client' .\Txt2Al.exe --source "C:\Users\Dawid\Documents\ReportsExt\cal\" --target "C:\Users\Dawid\Documents\ReportsExt\al\"
  5. Move all files from al folder to a new folder and open this folder in Visual Studio Code.

Perhaps it can be all done even in a one PowerShell script.

Rewrite the code, so it is supported by extensions

The next step is to make all the code and object changes working in extensions 2.0.

That sounds easy. Basically, all you have to do is:

However, when performing all above steps you must be aware (and you will notice it quickly), that not all the functions supported in C/AL are now supported in AL. This is where the challenge begins. You have to rethink the solution, or maybe apply some smart workarounds. Have fun!

In our case (reports), that was straightforward, and no major issues occurred. However, interesting thing was that in AL, you cannot modify MenuSuite objects, so you must do it in a different way. If you don’t want to add it to the List or Card page as an action, you can either extend one of the Role Center pages: usage category in AL

or make use of UsageCategory property:

usage category in AL

By adding this property, page will appear in Web Client in the search result box and also in windows client in the Extensions department.

Deploying to test

Once your extension is developed and if you want to deploy it to other database, just copy .app file and use PowerShell commands to publish and install it (Publish-NAVApp and Install-NAVApp).

That is the great benefit, comparing to the old approach – no TXT or FOB files and no code merging ! Only installation — this is how a proper add-on should work!

Our journey continues

That was really exciting experience and what is worth to mention — no major obstacles appeared on the way. We did not have to learn a new AL language syntax or whatsoever one can think is needed before. That was enjoyable task, but perhaps we can expect more challenges in the future as more difficult extensions are waiting for us.

Anyway, our journey continues and for sure we will blog about it again very soon!

Join us?

See what we have to offer - Careers