AL Object ID Ninja

Zero-configuration, dead-simple, lightning fast, no-collision object ID assignment for multi-user repositories

No collisions, ever: Real-time, conflict-free ID assignment that always gives every developer a guaranteed unique object ID.
Lightning-fast: Get your conflict-free object IDs instantly, with IntelliSense integration.
Zero-configuration: No setup, no onboarding, no settings — you work exactly like before, and it silently keeps your IDs clean.

From the blog

Sorting out the DLL hell, Part 2: The Solution

Deploying .NET assemblies to clients and servers in need is no simple affair. In my last post I have explained the problem, and announced the solution.

As promised, in this post I bring you the solution.

To be fully honest, this post only brings the conceptual solution, just a little brain game for you to train your .NET brain muscles a bit. The actual code I’ll deliver in the next post.

Sorting out the DLL hell, Part 1: The Problem

Let me tell you right away if you need to read this post at all. If you never wrote a single .NET class library intended to be used as a .NET interoperability assembly from C/AL, or if you never ever deployed a .dll file into the Add-ins folder of either Service or RoleTailored Client, then you probably don’t want to read this post.

Good, since you are still reading it means that you either deployed your own or somebody else’s .NET stuff into NAV’s client or server’s Add-ins folders. If you ever did so, you probably did not enjoy the experience too much. If you did enjoy the experience, maybe you should not read any further either.

Even better! Since you are still here it means that you didn’t enjoy deploying assemblies. Let me break some good news – all your problems are now gone! And I am not talking NAV 2016, I am talking NAV 2013 and anything newer.

Fixing Preview Posting: Part 2

In my two last posts, I laid out the technical design of the Preview Posting feature, and then showed how to simplify its design to get around the unwanted behavior of TryFunction. One thing is obvious from these posts: Preview Posting wants to simulate posting of a document (or journal) to show what the results would be, but without leaving any actual trace in the database. In database lingo – we want the transaction to be rolled back. Rolling back is no brainer. Simply throw an error, or do a silent abort, Except if there is COMMIT. In that case, no rolling back helps. I have announced earlier that my today’s post will be about how to nest transactions in C/AL so that an inner COMMIT has no effect on the transaction as a whole, which can still be successfully rolled back. That’s what this post is about.