Microsoft Dynamics NAV Extensions and the add-in pains

In these days I was in contact with many partners trying to migrate their NAV solutions to the new Extensions V2 architecture. As you can imagine, in many cases this is not only a simple “migration” but this task needs re-engineering the solution or some parts of it.

The real “mountain” I’ve found during the movement of many NAV solutions to Extensions V2 and AL is one: porting custom NAV add-ins to AL.

There are many customers that actually have add-ins written in C# and deployed to NAV for handling complex tasks; actually these add-ins cannot be migrated to AL mainly because:

1. We don’t have DotNet variables in AL
2. Standard .NET wrappers in AL are actually not enough
3. The C/AL Open Library is not enough to handle all scenarios

The last point I add to this list (point 4) is that many add-ins are actually DLLs with visual actions (WPF add-ins) and porting all the features to Javascript is quite impossible (but this is not the main issue we want to discuss now).

So, the real problem that many partners actually have is essentially this: how can I do the jump to AL and Extensions V2 if my add-in (that’s a core part of my solution) can’t be ported to the new platform at 100% full features that we have actually and that customers needs?

There’s no a clear answer on that. Actually, you’ve forced to adapt it to what the AL platform actually is offering you, and I can agree that in many many cases this is absolutely not enough. We need the actual full power of .NET also in AL!

How Microsoft could give us the power? 🙂

Essentially, I have in mind two ideas that I would like to share with the MS team, only with the intention to be a starting point of discussion.

Point 1:

Actually DotNet variables and .NET add-ins are deprecated due to security reasons in the cloud. But what about on-premise? If my business is 100% for the on-premise platform, why I can’t have the full power of the .NET Framework (one of the main features that actually NAV has)?

I think that could be interesting, when starting a new AL project with NAV and Visual Studio Code, having the possibility to choose for what platform I want to create an Extension. If the platform is Dynamics 365, then .NET usage is deprecated. If the target platform is NAV on-premise, Microsoft could “open the doors” and give us the access to the entire .NET stack exactly like in the actual C/AL.

To do so, why not simply add a new option on app.json file where we can set the target NAV platform? Something like:

If the platform parameter is on-premise, the extension is considered for the on-premise NAV platform (so I want to be able to use the full .NET Framework), otherwise it will be considered for the cloud environment (SaaS NAV proposition, with all the actual limitations).

Point 2:

As said previously and many many times before in other posts, in AL you can’t use DotNet variables due to security reasons in the datacenters. Despite this sentence, Microsoft with its Azure cloud platform offers services like Azure App Service or Azure Web Jobs where you can have an isolated cloud environments where you can run your .NET application or task.

Why not having something similar for using .NET add-ins (dll) with AL and Dynamics 365? I think it could be useful to have the possibilty to deploy a .NET dll on an isolated environment (App Service based?) and then call this add-in from NAV/Dynamics 365.

Azure Functions are not enough for handling all scenarios actually covered by NAV add-ins.

Am I dreaming? I don’t think so… .NET is a core framework for all the Microsoft’s ecosystem now and AL can’t ignore this. Ok, engineering all the Dynamics 365 architecture to handle these scenarios is not immediate but I’m sure we will have a solution in the near future. We don’t want a Ferrari without wheels…