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 (http://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 reading Dynamically loading assemblies at runtime
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:
And I am currently sitting in a UTC+1 time zone, mind you.
Continue reading Getting out of the DateTime mess, or how to get Utc DateTime in C/AL
If this was a joke, then it would be one of those good-news-bad-news jokes. So which one do you want first? To stay true to all jokes of this kind, I’ll start with good news first.
Good news is, you now have TryFunctions, that return true if no error happens, and false if an error happens inside them.
And the bad news? You’ll never want to use them.
Continue reading What’s New in NAV 2016: Splitting Atoms with TryFunction
Yesterday, as a part of Microsoft’s Road To Repeatability program, I delivered a live meeting session about server extensibility in NAV in which I focused on certain areas of .NET Interoperability and Web Services that in my opinion align well with the R2R message.
As promised, here are the materials from the presentation:
I provide this as-is, with no comments, documentation or anything – you are free to use any of these materials in your projects, and I welcome your questions here about presentation content and demos. I’ll do my best to answer them on my earliest convenience.
I hope you enjoyed the presentation yesterday (if you were attending) and that you find these materials useful.
When you reference a .NET class that exposes events, and you switch on the WithEvents property, C/SIDE creates the event triggers for you. If you later want to update the reference to the .NET class, for whatever reason (like, there is a newer version of the assembly), updating the reference will actually delete the event triggers with all the code in them.
To be fair to this non-feature, at least it warns you politely:
This is not something you experience once in a geologic era. When you are developing your own assemblies, this will happen fairly often – as often as you add or remove events to/from your classes, and you want to reflect that in the Development Environment. Or as often as you increase the version of your assembly.
Unfortunately, there is no way in the Development Environment to update the reference while actually retaining the event triggers or code in them.
But still, there is a way, and a fairly easy way at that.
Continue reading How To Update a Class Or Assembly Reference in C/AL And Retain Event Trigger Code