AL (at least half of its heart) will love .NET

In one of my recent posts, I’ve talked about one of the main difficulties that many partners around the world now have when migrating their Microsoft Dynamics NAV solutions to the new Extensions V2 model: the missing of a full .NET support in AL.

I’ve shared an idea with the Team: why not enabling the full .NET usage in AL at least for the on-premise world? This post had a lot of views in the following days, many of my readers has shared comments and ideas on my socials (thanks for this!), someone of them agree with me and someone of them think that “one codebase” (for on-premise and SaaS) is the target we will be forced to have.

Regarding this topic, today I’ve received an interesting feedback to my previous post directly from the NAV Product Team and I think that it could be interesting to share it with all the communities (this is not under NDA):

We are actively working on the DotNet feature for AL. It will be enabled for OnPremise, same as access to all tables and API’s. The DotNet feature is big, and simply didn’t make it for NAV2018. It is actually going to be controlled from the app.json file by setting the “target” to “Internal”. On-Premise servers will by default accept AL code compiled with this setting. For On-Premise it will be possible to do with AL whatever is possible with C/AL and more. It is correct that Azure functions have solved the data center security part, but this constraint is about NAV security, resource governance, performance, and COGS. Extension code will normally be interwoven between code with different origin (platform, base, extensions). Allowing arbitrary .net in extensions would require a “machine” boundary between all code with different origin. Introducing a costly boundary between all code with different origin will slow down execution significantly. The Cloud restrictions for AL gives us a “language-sandbox” that is what allows us to execute AL efficiently.

This is a cool news isn’t it? 2018R2?