Category Archives: Dynamics 365

Get the Modern Development Experience in Sublime Text

(Disclaimer, everything in this post is a hack, at this point, it’s all about making it work, then we can use nice folder names etc. later, read the name of my website πŸ™‚ )

So Visual Studio Code is great, and an awesome tool, but for some deep primal reasons, the choice of text editors has always been very personal for developers. My personal choice is SublimeText.

So why not try to get the new developer tool to run with Sublime?

First, let’s look at what we get in VS Code right now with the “AL Extension”:

  • Source highlighting
  • Intellisense
  • Compiler
  • Deploy

Let’s start with source highlighting

Source highlighting is the process that renders your code in specific colors based on text types and word. It looks like this in VS Code


VS Code uses TextMate format to describe the text. TextMate has become the defacto standard for syntax highlighting andΒ  (big surprise) Sublime Text also uses TextMate.

So the following copy command: (executed from the \users\you folder, and replace xxxx with the version number of your AL dev extension).

xcopy .vscode\extensions\\syntaxes\*.* AppData\Roaming\Sublime Text 3\Packages\User\AL\*.*

That will copy the AL Code syntax into Sublime Text’s setup. After that, when you open an .AL file, you’ll get this:


Notice that even though the colors are not the same, the coloring scheme is the same. Keywords are colored, numbers are colored, the text string in the message command is colored.

That was easy πŸ™‚

Let’s compile from Sublime Text

Next on the list is the compiler, let’s see if we can get Sublime Text to compile for us. But wait, first, let’s locate the compiler.

The compiler is called ALC.EXE and is located in the bin folder of the VS Code AL Extension (Under C:\Users\you\.vscode\extensions\)

You can supply the following parameters to ALC:

-project:<root path of source tree> (This is where app.json is located)
-out:<name of navx file>

So to build an extension, you call

ALC -project:<folder> -out:module.navx

And if everything compiles, you got a NAVX file, ready for deploy.

In Sublime Text go to Tools->Build System->New Build System…


And let’s just create one simple command: (again replace xxx with the correct version):

Β Β  Β "shell_cmd": "C:\\Users\\vmadmin\\.vscode\\extensions\\\\bin\\alc.exe -project:$file_path -out:extension.navx"

Save the file as “AL” something, navigate to one of your AL files, and press F7 (Build in Sublime Text)


Success, the AL Compiler is called from Sublime Text and an extension is created (screenshot is from a test where I checked how errors were presented).

Next chapter, deployment πŸ™‚

The conundrum of NAV and Open Source

There is a lot of talk about NAV and “Open Source” these days. Lots of the talk is related to the new Extension model that Microsoft Dynamics 365 and Dynamics NAV 2016/2017 shares.


Let’s first get a few definitions in place:

Open Source” – A piece of software where the source code is available to view and perhaps modify, but the original owner still controls vital aspects of the software.

Free Software” – A piece of software where the source code is available for anybody to use, modify, give away, do anything you want, apart from taking ownership of the software.

Object” – Every piece in NAV/365 is an object. That can translate to a table, a UI page, a report or other internal pieces. Each Object has an ID and the NAV/365 license defines access to the Object.

Business Logic” – The part of NAV that is built with Objects. This is the customer table, the general journal, the sales invoice posting routine.

Runtime” – The system that actually runs on the computers, the runtime executes the objects and makes it all comes to life.

The source code for the business logic in Dynamics NAV is available for those who has a license to that. There are several levels of source access:

  1. Customers can access partial sources if they have designer access to reports and pages
  2. Customers can access most sources if they have brought the “big” designer license.
  3. Partners have access nearly everything if they have a partner license.
  4. ISVs have access to their own “area” and can decide who (other partners) can access their objects.

That is neither open source or free software. This is privileged access to part of the source code of a closed sourced application.Β  And the privileged is only “given” to the select few that either buy access or through employment at a NAV partner.

So stop calling it Open Source, please πŸ™‚

There are even plenty of NAV pieces that has never been “open sourced” to anybody outside Microsoft. That includes the development environment, the runtime, the different add-ins, add-ons, ADCS, Toolbars, portals etc.

But from a practical perspective, the amount of source code access in NAV has historical been more than enough to give NAV its unique ability to be transformed into 1000s of industry solutions. And this has been a huge factor in making NAV the big success it is today, because, for many years, NAV lacked in functionality but made that up by being customizable.

Looking in from other software development platforms, the first question we are asked is: Why is source code access necessary for this? If we look at DotNet, COM Objects or other ways of building software, customization can be performed without accessing and recompiling the original code?

The answer is found the programming model, NAVs two main issues:

  1. NAV has (until 2016) been missing an extension framework, meaning that there has never been an official way to trigger custom code from the standard application.
  2. NAV does not have an “official” API layer. There is no well defined public interface to NAV processes.

With NAV 2016 we got events that can be used for triggering custom code, and with NAV 2017, we have most of the trigger points that were missing in NAV 2016. Triggers can only be accessed from NAV code; there is no abstract public API layer giving us the ability to trigger NAV business logic from external code. In the old days, we had a library called C/Front which gave us database access to the native database but no business logic, and now we have web service access, but that only give us access to data a limited set of business logic.

So the solution has always been, to dig into the source, and modify NAV to fit the current customer’s requirements.

Wielding this sword has proven a powerful weapon for many NAV developers, a good NAV developer is well traversed in the source of the standard application and can make very cools customizations in a short time frame.

Losing the “Open Source” aspect of NAV, could easily sound as you have to return the sword to Microsoft and be left with a dull little dagger that can’t even glow in the dark when there are orcs around.


But wait? Are you losing anything? Some NAV developers are worried that they will lose the ability to fix bugs in the core product, which in fairness, used to be an awesome power often wielded ten years ago. But with the rapid CU’ing going on, most bugs that I have discovered turned out to be fixed already looking at the latest CU’s change log or they turned out to be bugs in the runtime environment that I never had access to fix anyway.

The current problem with extensions is that they are objects, but do not expose an API, does not give any public interface, they just sit there in the runtime like a ghost. You can’t address them from code in any way. But the new development environment shown at Directions seems to solve this. I cannot wait for the preview at Christmas!

So, going to a “closed source, open model” world, what do I need to serve my customers?

I need access to view and address the model, the same we today can view and reference the public interface of a .NET assembly.
I need a way to modify the standard application behavior, adjust the UI, update the database schema and add my own business logic.

If I can do that, I don’t need your source to do my job πŸ™‚



Dynamics NAV abandons Windows Phone 8 in 2017

As part of the change log for the Microsoft Dynamics NAV Windows Phone client a small, but important message, has surfaced:

NOTIFICATION: With the introduction of Windows 10 Mobile, we will be discontinuing support for Windows Phone 8.1 in an upcoming update during early 2017.


Is this a problem? It could be. I’m certain Microsoft has some telemetry to back up their decision, but many businesses are using Windows Phones, and several models did not get the Windows 10 Mobile update, the Lumia 1020 is just one examples of phones that are left on Windows Phone 8.1

Is this a good thing? Hopefully, because NAV support on Windows 10 Mobile for Continuum is still lacking, and at present, that is the (single) biggest feature on Windows 10 Mobile, the feature that the entire platform is riding on. And having a Microsoft core offering not supporting it, is “less” than optimal.