Microsoft Dynamics NAV Extensions – Yesterday, Today, Tomorrow (1/3)

Directions EMEA has just ended .. and how great that was! Let’s see if I will come to writing up a “final thoughts” .. . That’s not for today.

After some “Extensive-Extension-writing” recently, I wanted to put out my own thoughts. My first version was a very long blogpost. But since I just bothered you with an insanely long post (for which I apologize ;-)), I decided to do this in three posts :-):

  • First, I’ll give my view on the evolution of Microsoft Dynamics NAV Extensions. (This blogpost)
  • Next, I’ll address a few concerns. Basically give my view on it
  • And to conclude, I’ll give you my view on what to do next. When and what I think you should do with Extensions now.

In this post, I’ll have a look at what we had, have and might expect.


Microsoft Dynamics NAV 2016 gave us Extensions. From day zero (when still in beta), I have been diving into it – creating a “kick-ass” (not really..) Rental Extension for demo-purposes together with Gary. And when you looked at it, you had the impression that everything was possible!

Well – not really. It was quite a pain to develop this Extension. Like:

  • You had to restructure code
  • Not all object types were possible – only pages, Tables, Codeunits
  • No Add-Ins
  • No Web services
  • No Job Queues
  • No Reports
  • No Translations
  • … (and a lot more)

Also, to be able to create an extension, you needed to manage the fact you have original and modified, compare them, create deltas and so on. Although – if you put a bit of time into PowerShell, this didn’t have to be painful at all.. .

That was the situation in the past. In my opinion, this was a prototype.


In NAV2017, we see an immense improvement in the capabilities, which I blogged about here. About all is possible now! Sure, we’re still working with Extensions as being mainly a collection of deltas (and some other files that include other things like web services, permission sets, add-ins,… ). But, thanks to the fact Microsoft already released a version of Extensions in NAV2016 (the prototype), we all have been diving into it, right? So the PowerShell scripts are still there! I had to do limited changes on my scripts to facilitate NAV2017 Extensions. And now, it takes me literally 5 clicks to start developing a new Extension, or to set up a DEV environment out of my GitHub to continue developing on an existing one. Like I have now put WaldoNAVPad into an Extension. (If you want to see this example, it’s all on GitHub. Powershell, NAV code, AddIn, everything .. feel free to have a look).

To be honest, I can hardly see any limitations to develop Extensions. Sure, sometimes you have to rethink your code-structure a bit … but that’s because we’re so used to change objects rather than extend them.

I mean .. think of it .. there are design patterns that facilitate upgrade .. which many of us embraced as being good practice! These patterns basically minimize the footprint in code. We all know that these patterns do not facilitate readability. But we accept them, because we want easier upgrades. Right?

Well, guess what. Extensions facilitate upgrades as well .. even better than any existing design pattern .. so let’s implement design patterns that facilitate Extensions .. . This is not so different.

That does not mean that I think this current version is ready for on premise customizations or verticals. Simply by the fact that at this time, there just aren’t enough events. And of course, Microsoft is on it: codeunits like 80, 90, 229, … are completely restructured .. and we will be able to see more and more events in the near future. Probably already in CU’s.

There is only one conclusion: look at the giant leap Microsoft has taken towards an Extension-only development model (if I may call it like that..).

If you’re still denying Extensions .. you’re just plain wrong.

If you’re still avoid diving into it .. you’re just plain wrong.

And that’s only my opinion. 🙂

Future – The ultimate dream

As said, I strongly believe that Microsoft is working towards an “Extensions Only” model. All customizations, all customizations on top of customizations – it’s going to be all Extensions. And that’s a good thing.

Just think about this:

The entire default database is a reference model. In your development environment you reference to this model (like you can create references in Visual Studio to any kind of libraries). By referencing, you get your objects, functions .. whatever you can program against, like codeunit 80, pages, … whatever. AND you get your events, to be able to use to hook into code. So in a way, I would be only creating new objects, by using references to existing classes. I would create new “classes” (let’s call them Extension Objects) to extend existing objects. This is exactly what I believe Microsoft is working on. Arend-Jan Kauffman already talked about this in his blog. Please read – it makes all the sense!

.Net people would say: uhm, ok, duh, that’s how we do stuff, indeed. But for NAV developers, this is a big change.

Because we are used to change any existing piece of code.

Some people hide behind the fact that this is an “Open Source” model. In my opinion, this absolutely has nothing to do with Open Source. “Open Source” is a community model where the community works on one code base. We don’t do that. We can read a certain codebase, created by Microsoft, and we modify it for every customer. It’s the complete opposite of open source – and can’t be compared with any orthodox software development environment. Call it a “Copy/Paste/Modify”-model. We’re not extending, we’re changing .. and in many cases, we are “breaking”. I call it “job protection”.

So why not work towards a model that is AS flexible AND we solve the upgrade-issue as well? Let’s not copy-paste-modify .. but just “reference-and-extend”.

Will it come with new pain points? Maybe so, but it will also solve a lot of other ones.


I truly believe that Extensions is going to be the solution for many pain points we have today. May be they are not already .. . But in the future they will! For On Premise, for customizations, for your private and public cloud. And guess what .. for Dynamics365 they already are!

4.00 avg. rating (82% score) - 5 votes

Permanent link to this article:

9 pings

Skip to comment form

  1. […] Microsoft Dynamics NAV Extensions – Yesterday, Today, Tomorrow (1/3) […]

  2. […] I hear sometimes regarding Extensions. If you haven’t read the first one, here you can find […]

  3. […] Microsoft Dynamics NAV Extensions – Yesterday, Today, Tomorrow (1/3) […]

  4. […] Extensions, These articles should answer most of questions – Read From Waldo – a. Extend existing objects With Extensions     Yesterday, Today, Tomorrowb. Concerns With Extensions     […]

  5. […] Bron : Waldo’s Blog Lees meer… […]

  6. […] of doing the work myself, I waited for him to post number three, and give you the links in here: Part 1, Part 2, and Part […]

  7. […] out Waldo’s first post on this […]

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.