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.
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.
If you are developing .NET assemblies for use with NAV, then sooner or later you’ll figure out that the new database deployment of add-ins in NAV 2016 is broken.
I’ve just suffered through medieval torture of attempting to have my NAV forget about a database-deployed assembly.
First of all – if you are merely consuming an off-the-shelf assemblies developed by somebody out there, you’ll probably not need to worry at all. However, if you are developing your own assemblies, then sooner or later you’ll find yourself stretched in exactly the same torture rack.
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:
And I am currently sitting in a UTC+1 time zone, mind you.