C#

A lot of us still have a ton of C/AL code sitting around in existing databases that sooner or later will have to be moved into AL. A lot of us also have a ton of AL code using DotNet that we want to be able to run in Microsoft’s cloud (that is: not on-prem).

One elegant way of replacing your .NET interoperability code with something else is by using Azure Functions. Sounds good in theory, but what does it take in practice? And what are Azure Functions, anyway? Let me not take too much latitude, and let me just say that Azure Functions are a way of…

I said a word or two about progress last week. Apparently, VS Code is not the only place where we take a small step back to be able to make a huge leap forward; .NET might seem like another one. You know it, right?

FOBs, those pesky little files that we all take for granted, import into our databases, and live happily ever after. After you read this post, you’ll handle FOB files very, very carefully. Why is that? Well, if you haven’t already, then read this post first: From C/AL to executable: how NAV runs…

If you have followed the posts about how C/AL really executes in NAV, you know that C# and C/AL can sometimes be in a state where C/AL compiles, but C# does not, causing you some headaches during run time. However, what might not be obvious is that there are situations where C/AL does not compile…

A lot of folks write C/AL and never worry about what happens then. C/AL is written, NAV execute is, the story ends. The same way the story ends when you flush a toilet and the tank refills. How exactly? Who cares.

I’ve delved deep into design patterns story with my last two blog posts , but I am far from over. The patterns I discussed are the ones we could use up until NAV 2015 (we can still use them, of course!) but some more robust loose coupling (excuse the near-oxymoron) can be achieved with what NAV 2016 brought along: events.

When you spend more time in C# than C/AL, and you still tell yourself and the world around you that you are developing for NAV, then this post is for you. I already wrote a three-article series about “DLL hell” and how to resolve it, and in my last post in the series (…

Today at work I was trying to untangle one big bowl of spaghetti called DateTime. It’s the C/AL DateTime I am talking about, not System.DateTime from .NET. The problem with C/AL DateTime is that no matter what you do it’s, according to documentation , “always displayed as local time” .

If part of your daily job includes creating control add-ins for Microsoft Dynamics NAV, then you know that creating control add-ins that target all clients requires quite a lot manual work. There are a lot of small steps that you must do every time.