I’m seeing in these days that many NAV partners are starting “tests” in order to move some of their Microsoft Dynamics NAV customizations to the new Extensions V2 architecture (with AL) and this is a great sign for the entire NAV ecosystem.
However, problems are always present during a migration/rearchitecturing stage and the number 1 problem that I receive from partners is this: how can I move my implementations that uses DotNet types to the new Extensions V2 model?
Many NAV addins and implementations on the market now uses DotNet variables and for the on-premise world this was a great way for extending NAV.
Unfortunately, with the Extensions V2 architecture, DotNet types are not supported and you can’t use them with AL. You’ve no way actually…
The official Microsoft’s guidelines regarding DotNet types in AL NOW are:
- On-Premise environments : DotNet interop will be available at some point in the future but not in the NAV release this year.
- SaaS environments : DotNet interop is not available due to safety issues in running arbitrary .NET code on cloud servers.
In my opinion, Microsoft should allow DotNet types in AL for On-Premise as soon as possible. They can’t cut one of the main features in NAV and one of the core feature on every Windows system. In an On-Premise scenario we need the full .NET Framework power. SaaS scenarios could be different, I can agree…
So, what can I do NOW with my implementations/addins if they’re extremely important for me and my business? The answer are actually only these:
- In many “basic” scenarios, AL gives you native types that maps to .NET types, like Lists, Dictionary, Strings, XML, HTTP and so on. If this is your case, you can “switch” your DotNet variable to a native type in AL.
- For more “advanced” scenarios, where actually a DotNet type you’re using is not supported on AL, the only recommended way is to use Azure Functions. With Azure functions, you can “rehost” your .NET code in Azure and then call your functions from NAV by using AL objects like HttpContent, HttpClient and HttpResponse.
- Check the C/AL Open Library project on GitHub and here submit your DotNet variable needs. The purpose of this repository is to build a C/AL library based on community contributions that will serve as an accelerator for adoption of the Extensions V2 technology. The source code from this library will be included in the base application of ‘Dynamics 365 for Financials’ on a monthly basis.
Regarding point 2, when I say this to a developer the questions I receive is “So I have to activate an Azure subscription?”, “so I have to pay more for my code“?
1) Yes, you need an Azure subscription, but I hope that this will be a “standard” activation for every future NAV customer (also for the On-Premise world). Azure is “a must to have” in my opinion now. There are many cloud services offered by the platform that can help you to improve your NAV architecture and it’s the time to guide the customers on this direction.
2) Azure Functions have a very very low cost. As explained by Microsoft in the Azure Functions pricing page, usage is aggregated at the function app level and counts only the time that function code is executed.
Azure Functions consumption plan is billed based on per-second resource consumption and executions. Consumption plan pricing includes a monthly free grant of 1 million requests and 400,000 GB-s of resource consumption per month, but free grants apply to paid consumption subscriptions only.
A personal recommendation: please ask to the NAV team for more and more DotNet types support for the On-Premise. We need that, I agree with you! 🙂
Stefano Demiliani 