Development

Read more about the article AL Object ID Ninja

AL Object ID Ninja

  • Post comments:9 Comments
  • Reading time:13 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.

(more…)

Continue ReadingAL Object ID Ninja

State of .NET Affairs

  • Post comments:30 Comments
  • 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.

(more…)

Continue ReadingState of .NET Affairs

Is Visual Studio Code really an improvement

  • Post comments:17 Comments
  • 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.

(more…)

Continue ReadingIs Visual Studio Code really an improvement

A few thoughts around assembly naming and versioning for NAV

  • Post comments:3 Comments
  • 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.

(more…)

Continue ReadingA few thoughts around assembly naming and versioning for NAV