Tag Archives: Development

State of .NET Affairs

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 reading State of .NET Affairs

Is Visual Studio Code really an improvement

Progress often doesn’t look like progress at all when it first arrives.

When on July 3, 1886, Daimler Benz presented his first car, it had a 0.75 horse-power engine that could reach a top speed of 16 km/h. It was able to cover 45 km on a single fuel tank, and it could only take two passengers. Compared to best horse-driven carriages of the day, especially taking the availability of stuff you could use as fuel, this was hardly a progress. Horse-driven carriages bested this car on all fronts, and by large margins.

Imagine what the world would look like today should Daimler Benz heeded the naysayers and mockers of his day, and they were not in short supply.

Continue reading Is Visual Studio Code really an improvement

Dynamic certificate validation when calling Web services

There are situations when you’ll want to call Web services from C/AL, and those Web services might be protected by certificate that your local machine cannot validate directly. Web service might be secured with a self-signed certificate, or by a certificate obtained from an authority that is not globally trusted.

In all those situations, you might need to have a facility to validate certificates yourself. That’s something that’s at the fingertips of all C# developers through the ServerCertificateValidationCallback delegate. However, in C/AL, delegates are unfortunately not (yet) supported.

A friend of mine had this specific problem today, so I remembered that a short while ago I made a “how do I” video on this specific topic. Thanks, Mathias, for giving me a prod, and reminding me of a quick blog topic.

Here’s the link: https://youtu.be/NW_ZiW6J790

A few thoughts around assembly naming and versioning for NAV

Are you developing .NET assemblies intended to be used from C/AL? If so, then you must have realized that keeping proper track of them and managing them on the server (or client, in case you still do that) is not a simple affair.

Assemblies in .NET are identified through their fully qualified name, and that’s how NAV tells one assembly from another, as well. Fully qualified name contains the assembly name, version, public key token, and culture information. A good practice in .NET development is that when you update assembly’s functionality, you also version that assembly up, essentially resulting in a completely new assembly, which doesn’t have the same fully qualified name as the older version did.

However, this kind of change is a breaking change. In .NET, it’s not all that breaking – you simply reference the new version and this applies to whole project. Or whole solution, depending on how you configure the MSBuild behavior.

But in NAV, it’s a completely different story. Versioning an assembly up is a very breaking change. In NAV, we cannot simply replace a reference once, and then have it apply to the whole database. Unfortunately, we have to update a reference on every single variable, and if you ever had to do it, chances are you don’t keep any happy memories about this experience.

That’s why NAV developers, when working in .NET, prefer not versioning up. And that’s wrong.

Continue reading A few thoughts around assembly naming and versioning for NAV

Sorting out the DLL hell, Part 3: The Code

[Update, February 8, 2016: there is a new version of code from this post. Please check http://vjeko.com/dynamically-loading-assemblies-at-runtime]

Okay here we go. In this post I deliver the promised code that handles automatic deployment of all your assemblies to client and server, as needed.

For any of you who haven’t read the last two posts, I am talking about automatically deploying .NET assemblies to clients and server, from the database, on demand, at runtime.

This will be heavy on code, so fasten your seatbelt and brace for impact.

Continue reading Sorting out the DLL hell, Part 3: The Code