C#

How to replace DotNet in AL

  • Reading time:7 mins read

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). And I guess most of us don’t want to maintain a DotNet-less and DotNet-ful versions of our code.

Sooner or later, you’ll want all of DotNet out of your AL. Even if you are a seasoned .NET developer, you’ll want all DotNet out of AL.

Anyway, when you need to replace DotNet, what options do you have? Let’s take a look at all possible paths.

Continue ReadingHow to replace DotNet in AL

Invoking Azure Functions from AL

  • Reading time:5 mins read

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 running simple pieces of code as a service that you can invoke like any other RESTful web services. And of course, they run in Azure. To learn more about them, follow this link: https://docs.microsoft.com/en-us/azure/azure-functions/functions-overview

Creating them is as simple, as invoking them, so let’s get started with an extremely simple demo that will illustrate how amazingly powerful they are, and why they are a perfect solution for replacing your .NET code with something better.

Continue ReadingInvoking Azure Functions from AL

State of .NET Affairs

  • Reading time:17 mins read

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? You know that if you want to run your .NET code in D365 for Financials, you are out of luck, and you do know that this applies to as much to Microsoft .NET Framework out-of-the-box types as it does to your own, custom-built .NET assemblies. If you don’t know that yet, then let me bring you up to date: In your D365 apps built on Extensions “v2” technology, you won’t be able to use anything .NET; you simply won’t be able to compile AL code that includes a DotNet variable declaration.

This is neither fake news, nor is it news per se. It has been known at least since October last year when Microsoft first presented AL Language extension for VS Code during Directions US in Phoenix. Soon after the VS Code session there was a round table (in all honesty, I have never seen a table, let alone a round one, at any of round table sessions at any conference) on the topic of .NET future, and the mood was grim. At first everyone thought it was a bad joke, then all held hopes high that Microsoft is simply “feeling the pulse” to see how the channel would react to such a disturbing change. But soon it became obvious that .NET interoperability is on its way to be gently ushered out of the (relevant) technology stack of NAV and that we should start getting ready for the day when it’s not there anymore.

So, what is the current state of .NET in NAV, what is the future of it, and what can you do about it?

Let’s take them one by one.

Continue ReadingState of .NET Affairs

C# Injection: Don’t trust FOB

  • Reading time:3 mins read

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 your C/AL code

Good, now that we are on the same page, let me explain why you must never, ever, ever trust a FOB file.

Continue ReadingC# Injection: Don’t trust FOB

C/AL internals: Some more invalid object states

  • Reading time:6 mins read

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 anymore (typically due to a changed dependency signature, or due to an object that went AWOL) but C# not only compiles, but also happily runs as if nothing is wrong in the first place.

These situations can be confusing, and after having read my original post, my friend Heinz has pointed out to those situations and asked me if I can explain them. So, here it goes.

Continue ReadingC/AL internals: Some more invalid object states

From C/AL to executable: how NAV runs your C/AL code

  • Reading time:10 mins read

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.

While understanding the inner workings of a toilet flush tank doesn’t necessarily make you more efficient at whatever it was that made you press the flush button in the first place, having a better understanding of exactly how NAV uses your C/AL code throughout its lifecycle is of arguably higher practical value.

Have you ever wondered what exactly happens to your C/AL code when you write it? How exactly does NAV run that stuff? Does it do any run-time interpretation, or does it compile C/AL into native code that runs on a processor? What does just-in-time compilation  mean and does it happen with C/AL? If so, when and why?

If any of these questions bother you, read on. If they don’t bother you, read on because they should bother you. If they don’t bother you because you know the answers, read on still, and then brag by poking holes in my explanation.

Continue ReadingFrom C/AL to executable: how NAV runs your C/AL code

Gentlemen’s agreement pattern, or handling the “Handled” pattern

  • Reading time:11 mins read

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.

It’s the “Handled” pattern. This pattern comes from Thomas Hejlsberg, a chief architect and CTO of Microsoft Dynamics NAV, and was first described by Mark Brummel on his blog. It’s a powerful loose-coupling pattern that successfully addresses the shortcomings of all design patterns I discussed earlier. I would prefer calling this pattern Event Façade rather than “Handled”, but it’s not my baby to christen.

Let’s take a look.

Continue ReadingGentlemen’s agreement pattern, or handling the “Handled” pattern

Dynamically loading assemblies at runtime

  • Reading time:6 mins read

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 (https://vjeko.com/sorting-out-the-dll-hell-part-3-the-code) I delivered some code that help you take control of your .NET assemblies.

This time, I am delivering an updated solution, one that solves all the problems others, and myself, have encountered in the meantime.

So, fasten the seatbelt, and let’s embark on another .NET interoperability black belt ride.

Continue ReadingDynamically loading assemblies at runtime

Getting out of the DateTime mess, or how to get Utc DateTime in C/AL

  • Reading time:3 mins read

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”.

Another problem with C/AL DateTime is that C/AL is a bit rude when it comes to System.DateTime: whenever C/AL compiler (or runtime) encounters a value of System.DateTime it’s automatically converted to C/AL DateTime.

When you combine those two problems, you get the following problem: even though System.DateTime is perfectly capable of handling time in both UTC or local kind, C/AL isn’t.

To prove this point, just run this:

MESSAGE(‘Current local time: %1\Current UTC time: %2’,SystemDateTime.Now,SystemDateTime.UtcNow);

It will show this:

image

And I am currently sitting in a UTC+1 time zone, mind you.

Continue ReadingGetting out of the DateTime mess, or how to get Utc DateTime in C/AL

Visual Studio Control Add-in Project Template

  • Reading time:2 mins read

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.

To avoid all that work that adds no value, only frustration, here’s a Visual Studio project template that you can use to automate the process of creating a new control add-in.

Continue ReadingVisual Studio Control Add-in Project Template