NAV Development Preview – Anniversary Update

Even though December is not over yet, we have another release for you! Welcome to our Anniversary Developer Preview - today marks exactly 1 year ago since we announced the first preview of the modern development tools - for a trip down memory lane, see our blog post from back then here. We hope that you will agree that our development tools have evolved and grown a lot since then. We still have a long way to go and we're very excited to continue this journey together with you. Thank you for all of your contributions to this project so far. Your suggestions, pull requests, questions, and issue reports are not only very helpful for guiding our work but also very motivating for the team. We continue working hard on improving the capabilities of the toolset as well as fixing incoming issues reported by you. Below you can see the changes that we're announcing for this update. To jump directly to an updated image, go to the sign up at

Please note, that the improvements announced in this blog post are not available in Dynamics NAV 2018 and the following cumulative updates of Dynamics NAV 2018.

Debugger changes

  • The Visual Studio Code debug adapter has been refactored to lazily evaluate globals and locals
  • Text constants are no longer shown as part of global symbols

Method overloading

The AL language now supports method overloading. It is possible to have one procedure with the same name, but with different parameter lists. The codeunit shown in the sample below has 3 procedures all named Add():

IntelliSense will now show the parameter lists for the different versions to browse through:

When hovering over a method call, the called version is shown:

More control add-ins available

A number of built-in control add-ins can now be used in AL extensions:

  • Microsoft.Dynamics.Nav.Client.VideoPlayer
  • Microsoft.Dynamics.Nav.Client.WebPageViewer
  • Microsoft.Dynamics.Nav.Client.PageReady
  • Microsoft.Dynamics.Nav.Client.BusinessChart

Note: Business chart can currently only be configured through table Business Chart Buffer (485), which internally uses .NET interop to set up the chart.

All new control add-ins are available in the newest Application symbols package, therefore they could be simply referenced in the user control field:

Working with camera

A new base page Camera Interaction (1910) has been added to encapsulate the interaction with the device camera (if available). .NET interop code is no longer needed to take a selfie in AL:

More system tables unblocked

A number of system and virtual tables have been unblocked for extension development:

  • License Permission
  • Permission Set
  • Permission
  • Aggregate Permission Set
  • All Profile
  • Profile
  • Profile Metadata
  • Add-in
  • Chart


That's it for now. As usual we encourage you to let us know how you like working with these additions and keep submitting suggestions and bugs. You can see all the filed bugs on our GitHub issues list ( 

We wish you a Merry Christmas and a Happy New Year!

For a list of our previous blog posts, see the links at the end of this post.


NAV Development Tools Preview - December Update

NAV Development Tools Preview - November Update

NAV Development Tools Preview - October Update

NAV Development Tools Preview - September Update

NAV Development Tools Preview - August Update

NAV Development Tools Preview - July Update

NAV Development Tools Preview - June Update

NAV Development Tools Preview - April Update

NAV Development Tools Preview - March Update

NAV Development Tools Preview - February Update

NAV Development Tools Preview - January Update

Announcing the Preview of Modern Development Tools for Dynamics NAV


Comments (5)

  1. Danis says:

    Happy birthday to the first anniversary – thank you for working with that much effort and energy on this great new development tools! You did really, really HUGE steps in this one year! I’m so exited to see what will be possible in near future 🙂

    Have great christmas days and a happy new year!

  2. Jeremy Vyska says:

    Looks amazing and has been a long an interesting year!

    You note these changes will not be in 2018 or any 2018 CUs. Will they be in 2018 R2?

  3. In additions to the AL functionality, adoption would be increased if these changes were released as part of NAV 2018 Cumulative updates.
    Developers are already having a difficult time managing the different symbol differences.

    If the AL functionality appears on Dynamics 365, then developers have to manage two versions.

  4. Bartel de Leeuw says:

    First off, big thank you to the MS devs for the hard work and dedication this past year. We are very excited with the direction of the AL language, and the new bits that are coming out every month. We also very much appreciate the opportunity to report our questions and issues here, and get feedback from the team.

    And now that NAV 2018 has been released, we get a chance to share the exciting new functionality with our customers. That brings me to my suggestion: Please keep NAV 2018 on par with the latest functionality. I’m not sure why only bug fixes would be released as part of the NAV 2018 CUs. It would seem to be a lot more work for everyone, coupled with more drawbacks, and no advantages. Especially in the 0.x versions, when so many crucial bits are being added. Those early important pieces of functionality make a considerable difference in being able to solve cases with extensions vs. having to utilize C/SIDE. And having to wait up to a year to get access to them is just too long.

    Advantages to monthly releases
    1. Easier on the MS devs. Unless I’m missing something, the MS devs have to spend extra time splitting out what is a bug vs. an improvement, and maintain multiple codesets to make this happen. Wouldn’t it be easier to just have a single codebase that gets updated for both D365 as well as NAV 2018?
    2. Easier on support. When you are dealing with multiple codebases, support becomes harder as well.
    Easier on ISVs and VARs. When writing solutions or code for two products, you have to maintain multiple versions, instead of just one.
    3. Easier for customers. We have a number of customers that are currently looking into migrating to the Cloud, but are held back by internet limitations. Our customers often use ERP-integrated shop floor solutions in multiple shifts, so they are dependent on NAV being up 24/7. They would like to go Cloud, but cannot, due to their internet situation. Especially our mid-size manufacturing and job-shop companies, that have chosen a rural location in order to take advantage of lower labor costs. The drawback of their location is often a poor internet connection. Slow speeds, no redundancy, frequent internet outages. We would like to get them on NAV 2018 with extensions, but due to the limitations in the extensions, we have to make changes to C/SIDE instead. If we can get them on NAV 2018 with extension, they can easily migrate to Cloud once their internet situation improves.

    The only reason I could come up with to not release the latest bits with NAV 2018 is in an ill-advised attempt to push people to go Cloud instead of on-premise. Speaking for most of our customers, if they could go Cloud, they would. And if we can keep them in the fold with NAV 2018 and an easy migration path to Cloud, they will migrate once the time is right. If the on-premise version starts to fall behind, I have customers that will start shopping elsewhere.

    1. Stanislaw Stempin says:

      Thank you for the detailed feedback. It reflects a similar discussion that we have internally had on this topic.
      We are well aware of the benefits of giving access to the latest version of the development tools on NAV 2018 and we would actually have liked to do it. However, features in the development tools often depend on corresponding server changes/capabilities. Therefore, in many cases, back-porting dev environment features would mean back-porting server features. If these in turn depend on other features we quickly get into fully fledged development effort for an additional product. (And the problem would keep growing over time, with each following On-Prem version to maintain).

      We have instead decided to focus the development efforts on a single, latest version of the product. This of course means that the new features light-up first in the cloud releases (which are shipped on a monthly basis) but eventually they will all be available in the next On-Prem release (NAV 2018 R2 in this case)

      As a bit of technical background – codebase between D365 and On-Prem is in fact the same but only at the time of the release. I.e. D365 as of December 1st corresponded to NAV 2018 and D365 as of Spring will correspond to NAV 2018 R2. However, after the release the On-Prem product is branched for maintenance mode. Therefore any feature development in the branched product version comes at an additional cost.

      The proposal to release On-Prem version on a more frequent basis, in sync with the cloud version is something that we are aware of but it is a bigger, product-wise decision that will not be retro-actively made for NAV 2018. Such a decision would also have significant support, upgrade and development process consequences that need to be considered in a context broader than dev tools.

      Having said that, we will back-port selected features to NAV 2018 but it will be a case by case decision dependent on the costs/benefits of doing so. It will mean finding a balance between fixing truly blocking issues on NAV 2018 vs completing new feature development for the latest version (for example, we will be back-porting the fix for #62 to NAV 2018).

      We hope this gives you some insight into why we made the current decision.

Skip to main content