Hopes, wishes and demands for Visual Studio Code for Dynamics 365

Now I have worked with the Visual Studio Code development environment for Dynamics 365 “Tenerife” for a while and like everybody else in “Dynamics NAV blog world” I am excited about the new environment.

However, there are a number of issues that must be fixed before it can be released in a live environment:

Limiting the development according to the Dynamics NAV license acquired

It is possible to publish and install an extension to a Dynamics 365 server as a super user regardless of the development level in the Dynamics NAV license file.

In “on premise” Dynamics NAV there are four levels of access to development:

  • Access to the object designers. It is possible to buy access to create new tables, pages, reports and other objects and to add fields and controls to existing objects.
  • Solution Development
  • Application Builder
  • Developers License

This licensing is totally ignored when developing solutions in Visual Studio Code.

I have spent the last 25+ years teaching developers how to create solutions in the Dynamics NAV development environment. This includes knowledge of:

  • The table structures
  • The naming conventions of fields, tables and variables
  • The C/AL code language
  • The design patterns of Dynamics NAV
  • And “best practice” of developing solutions for Dynamics NAV

Without knowledge of the “on premise” development environment, it will open up for creating solutions in Dynamics 365 without any quality assurance or standards, and we will see a repeat of what happened in 1990 when the first real development environment was released for the text-based IBM-Navigator 3.0. Everybody created solutions in the way they found the best, unfortunately destroying many good solutions.

Access to the standard development environment

As it is now, it is necessary to have the “on premise” development environment open in order to find the place to insert the code.

It is possible to see the functions and variables in a standard codeunit like codeunit 80 by creating a variable and then right-clicking the codeunit name to use the Go to Definition function:

That will give me a list of all the functions in codeunit 80:

But I cannot see the code in the Go to Definition page, only functions and variables, and I therefore have to guess what environment I just landed in, when I subscribe to an event.

The solution could be to get access to see (and not edit) the code in any given object of the standard Dynamics 365 development environment or to be able to browse different objects to see, where to interact with the code.


Oh, and by-the-way, thanks for all the new integration events in codeunit 80:

I am looking forward to seeing them in the “on premise” Dynamics NAV 2018 next week [:)] 

Making extensions on extensions

As it is now, I can only make extensions to the standard objects in Dynamics NAV.

It would be nice to be able to make a extension to an installed extension.

There is a property in the app.json called Dependencies, so maybe it is on its way:

Being able to make extensions on extensions would make it possible to make a "base" extension for my other extensions and that would save me a lot of time.

Execution sequence to the subscribers to an event

As from the first days, it is apparent that if two extensions subscribe to the same event in the same object, it is not possible to define the execution sequence of the subscriber events, it seems to use the objects number as a guideline. This could make sense because Microsoft have all object numbers from 0 up to 49.999, and they are therefore executed first. But the manufacturing solution resides in the range of 99.000.000 up to 99.999.999 so it does not make any sense after all.

Also, the customized objects are normally in the range of 50.000 to 99.999 and they would be executed before the installed add-on solutions.

So, a simple solution would be to add a priority parameter to the EventSubscriber call.

Also, it is not possible to see other subscribers from the Visual Studio Code editor.

In the Development Environment the list look like this:

An equivalent overview from the Visual Studio Code editor would be nice.

Audit-trail on which extensions have been installed and when

The most problematic part with the extensions, applies to both the “on premise” and Dynamics 365 extensions. It is possible to publish and install extensions to a database without it being evident that the solution has been active.

Let me make an example.

I create an extension with one codeunit and only two functions:

Now this will be possible to publish and install without anybody being able to see that it has been installed. Maybe except for the Extension Management page, but who looks there before exporting payments to a file?

But more seriously, it is possible to uninstall the extension and unpublish the extension without a trace.

Nobody can see that the extension was published in the database nor that it was installed on the tenant during the time of the export of the payments.

This has to be addressed somehow?

Maybe a log and a limitation that an extension that were once installed cannot be unpublished.


We are getting there.

The development environment gets more and more finished, and If we can get these issues fixed, I can see a bright future for the Visual Studio Code development not only for Dynamics 365, but also for Dynamics NAV in the future.