The New Developer Experience for Extensions

Interesting title, isn’t it? At Directions US last week, there was a session called ‘Modern Development Experience and Improvement for Developers’. And of course, that session will be held next week at Directions EMEA as well. See here, here and here. Two session slots and an interactive discussion about the same topic, that must be an important one!

And yes, it is absolutely a game changer. Microsoft not only push Extensions in favor of old-school customizations. They also change the way we create Extensions. And eventually, it will be the most preferred way (to not say the only way), to create customizations.

Small detail: they are currently talking about ‘developer experience’. While we are used to the term ‘development environment’. I think, for this moment, it is correct to talk about experience rather than development environment. Over the next period (don’t ask me how long that period exactly will be) we will say good-bye to the development environment as we know it today (good old finsql.exe) and welcome Visual Studio Code. Which is not only a new development environment for the NAV developers, but a complete new experience. We all need to learn new stuff.

VS Code is a lightweight source code editor, running on Windows, Mac and Linux. (Developing for NAV on your Linux box, doesn’t sound cool?). It has built-in support for JavaScript, TypeScript and Node.js. And it supports extensions (no, not NAV Extensions!) for other languages, like C#, Python or PHP. The NAV team have created a new VS Code extension that enables the creation of objects in AL language. And beware, it is not just simple plain forward, to create a VS Code extension for a complete new language! It involves the creation of a model to support intellisense and the creation of a new compiler. That sounds easy, but it is not.

Here is a photo that I took last week during the session at Directions US in Phoenix, AZ. (Click on it to open a large picture in a new tab)

What can we see on this picture?

On the left hand side, you see a number of files. VS Code is file based, so we have to learn to work with files instead of objects in a database. You can see files ending with the al extension. These are the files that contain our objects.

The package.navm file is the compile result. It contains the compiled set of al files and can be deployed to the NAV server. How this exactly works, how to get it into the app source, is yet unclear. The demo during the session just deployed it to a NAV server. It is also unclear yet if the .navm package can be deployed to an on-premise NAV server or only to Dynamics 365. My educated guess is that both environments can be used for deployment. But I don’t know yet what’s in scope for the first release of this tool.

At the right hand side, you see the code itself. On the first line you see pageextension 50088 CustomerCardExtension extends “Customer Card”. What can we learn from this?

First thing is that an extension on an existing object is not a delta file. It is a new object type, called pageextension or tableextension. It also gets its own number and name, separating it from other objects. Then the keyword extends tells the compiler that this object is extending an existing object that is named after. On my question why it does not have an object number here, like extends Page 21 I received the answer that they are looking at using names in favor of numbers. Interesting, huh?

Take a look at the code. As you can see, it is possible to change the layout and to change actions. Pretty similar to what you can do today with Extensions and delta files. The difference is that you are not creating delta files here, but you create a new object, an extension object. By the way, the AL module for VS Code contains code snippets that inserts the correct code layout for you when you start creating a new object.

Is it possible to create new objects? Yes it is. Look at the next picture, which shows the difference between creating a new table and creating a tableextensions. Take a moment to look at the code and try to figure out the differences.

This picture also raises some questions. Like: will it now be possible to add code in the OnValidate trigger of an tableextension? Didn’t ask, sorry… What I did ask is a question about the OnInsert trigger on the tableextension: it is called as an event, but is it OnBefore or OnAfter? The answer was: work in progress…

How much do we currently know about this upcoming tool? Let me just list here what I have heard, please feel free to add more info in the comments.

• The editor supports intellisense, so it is aware of available fields, controls, etc., in the base product that you are extending. This is the ‘model’. You can set the model with a setting in the app.json file (see first picture). In this file you change the version of the base database that you create your extension on. This also implies that there must be a tool to create such a model. For example, W1, DE, UK or NL version. Or 2017 RTM, CU1 version. And I expect that it will be possible to create your own model file, based on an ISV database. (This is my interpretation, I asked but didn’t get a clear answer on that).
• The language is AL language and pretty much the same language as we are used today with C/AL. It has been extended with keywords to support the layout of the objects, like fields, triggers, etc.
• Everything is text based. So declaration of variables, functions, fields, triggers, you name it, is done in text. For developers who know Visual Studio this is nothing special, it’s the same as with C#.
• Those extension objects are successors to delta files. Eventually the delta files will fade away.
• A tool is expected to migrate Extensions (based on delta files) into extension objects. This tool will not transform delta files, but will migrate extension source into new extension format. No further details here, but I expect something like Compare-NAVApplicationObject with an extra parameter to create the new extension format. Or maybe a new cmdlet like New-NAVExtensionObject -Original -Modified. (Don’t pin me down on this!)
• The .navm file is more or less similar to the .navx file that we can create today with Extensions.
• Don’t expect the AL language to support native .Net integration. E.g. create .Net objects in a C# way, or to use .Net features like LINQ. However, the architecture supports doing this eventually.
• The VS Code editor will become the preferred way of doing modifications in the future. Eventually, it will enable us to do any kind of modification that we can do today. This may take years to achieve, there is a lot of work to do. At least 2 or 3 years is my best guess. But that also means that we don’t have a big bang scenario, we will have the opportunity to learn this new tool over time.

Besides the code editor, there is also a new visual designer. Based on a comment I received, you could expect the page designer and code editor to work side-by-side.

What is that visual designer about? It’s a new feature in the Web Client that puts the page into design mode. Let’s have a quick look:

The button in the right hand upper corner enables design mode. After that you can move fields around to a position that you like.

And what’s more, you can insert fields on the page that are already existing in the database, but not yet available on the page.

For example, the field Name 2 is available and ready to be placed on the page.

And if that’s not enough, you can also create new fields!

Finally, the changes that you done in the page designer can be saved.

And you may already have guessed it: the changes are saved in the same format as you create extensions with VS Code. Do you see the big picture?

Well, that’s pretty much what we know today. Interesting times ahead, that’s for sure. Nothing is carved in stone, everything you see on this page is subject to change (so, that’s my disclaimer, nobody can say that didn’t warn you…). However, one thing is clear: Extensions as we know it in NAV 2016 got more possibilities in NAV 2017. But it is an intermediate solution, we will eventually go with the new experience. The challenge for Microsoft will be to move forward with a modern and appealing development environment while not sacrificing the flexibility we have today in changing the look-and-feel and behavior of Dynamics NAV. That’s not a simple task, it will take years rather than months to finish it completely. But the first impression is that it is going in the correct direction.

Oh, one asks when we will get our hands on this tool. I have been told that you can expect this as a Christmas present this year. Want to see it in action somewhat earlier? Come to the sessions at Directions EMEA in Prague next week, or visit NAV Techdays in November in Antwerp!

Tip: download VS Code, watch the introductory videos and get used to it before it hits your NAV development environment!