Development

Read more about the article AL Object ID Ninja

AL Object ID Ninja

  • Reading time:9 mins read

One of the biggest obstacles to AL team development (is there any other kind?) is object IDs. IDs are supposed to be easy: just pick the next free one and off you go. AL Language even helps by suggesting the next available one through IntelliSense. But you are most likely not the only developer on your team. As soon as you add another developer to equation, and both of you use the built-in AL IntelliSense auto-suggest feature, you are inevitably heading towards object ID collision. The more developers there are, the more active your repository is, the more likely the collision.

Obviously, without some kind of a back-end that coordinates object ID assignment – preferably in real time – is absolutely necessary. And teams have come up with various solutions to this problem. They include:

  • “Who cares!”: the most heroic one, no object ID collision will ruin your day. Bring it on – you say! I’ll handle you – you say! These teams spend a lot of time resolving collisions post-factum.
  • Object “reservations”: you create an empty object of the desired type, push just that, create a PR that does nothing by that, and launch into the Hail Mary mode until your PR gets merged. The slower your validation pipeline is, the more likely it is that more than one developer will be saying their Hail Marys at the same time, and guess what – Mary will help one of them.
  • “Hey, folks”: you yell to announce to everyone that you are about to take an object ID. Or, in more advanced teams, you run a Teams team (uh, did I mention “team?”). This approach is not too robust, but generally yields better results than the above two.
  • Excel: the ways this tool gets used, geez. It’s a spreadsheet calculator, for Pete’s sake, but people have been using it for everything ranging from shopping lists to, well, object ID assignment sheets.
  • “When you have a hammer, every problem you see is a…” BC! The ways this tool gets used, too! Well, heck, yeah, isn’t it so freaking obvious that people will just create a BC app and deploy it internally so that everyone can use it. BC has nearly all facilities you need (that none of the above approaches does): primary key validation and concurrency. This is a very advanced stage in the evolution of object ID collision management solutions.
  • Automation. Yeah, baby! Now that there is a BC back end, and BC has APIs, let’s build an API that gives you next number, and then let’s do some front-end that fetches that from the back end, and then let’s somehow embed into VS Code. There is at least one tool that I know of, that does exactly this. And good that I didn’t know of it that Saturday morning nine days ago, because I would have zero motivation to take this evolution one big step further.

This is where AL Object ID Ninja joins the show! It’s zero-configuration, crazy-fast, mind-bogglingly simple solution for no-collision object ID assignment in AL. If you haven’t already (and if you are using Waldo’s AL Extension Pack, chances are you already have) go fetch yourself a copy.

Continue ReadingAL Object ID Ninja

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

Is Visual Studio Code really an improvement

  • Reading time:8 mins read

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 ReadingIs Visual Studio Code really an improvement

Dynamic certificate validation when calling Web services

  • Reading time:1 min read

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

Continue ReadingDynamic certificate validation when calling Web services

A few thoughts around assembly naming and versioning for NAV

  • Reading time:5 mins read

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 ReadingA few thoughts around assembly naming and versioning for NAV

Sorting out the DLL hell, Part 3: The Code

  • Reading time:11 mins read

[Update, February 8, 2016: there is a new version of code from this post. Please check https://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 ReadingSorting out the DLL hell, Part 3: The Code

Client Extensibility Demos

  • Reading time:2 mins read

On Monday, June 15th I have delivered another session in Microsoft’s Road to Repeatability series of online demos about technical NAV features, this time covering Client Extensibility. The session went through both the .NET and JavaScript aspects of client extensibility, and again – I promised to post all of the demos and content from the session on my blog.

So, here it is, given as-is, with no guarantees or strings attached, just the plain content for you to see if you can make any sense out of it.

Now my to-do list has grown quite big with the stuff that I want to blog, and it includes presenting and explaining most of the concepts I showed in my presentation. So, keep your fingers crossed that I find just enough time to blog about all those small things that have found their way into my presentation, but never into real blog posts that take them inside out and explain in-depth what they are and how really they work.

Of course, you are still free to use any of this in any real, or unreal life scenarios.

Continue ReadingClient Extensibility Demos

Passing JSON from JavaScript to C/AL

  • Reading time:4 mins read

Yesterday, I said I was closing this year of blogging, but I wasn’t really. Closing a year with 39 posts, and leaving a question lingering, wouldn’t be too fair, would it? If you read my last postabout how to pass objects from C/AL to JavaScript, you must have wondered if it’s possible to also pass objects from JavaScript back to C/AL.

Wonder no more. It is. And here’s how.

Continue ReadingPassing JSON from JavaScript to C/AL

Passing strongly typed data to a JavaScript control add-in

  • Reading time:3 mins read

Many cool things often go undocumented. I’ve just stumbled upon one of those, and it comes in handy to close this year of blogging.

Imagine this situation: you have a server-side .NET object, that you want to pass on to the client. With the .NET System.Windows.Forms-based objects, you have to make the object serializable, deploy the object to the client-side Add-in folder, and then set the RunOnClient property on the C/AL variable to Yes.

However, if the client is not .NET-based, if it is a cross-client JavaScript-based one. You may think that it’s not possible to pass the custom object on to JavaScript code. And you may be wrong.

Continue ReadingPassing strongly typed data to a JavaScript control add-in