Assembly – Vjeko.com

A few thoughts around assembly naming and versioning for NAV

Post published:December 21, 2015
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…)

Sorting out the DLL hell, Part 3: The Code

Post published:November 10, 2015
Post comments:58 Comments
Reading time:16 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.

(more…)

Sorting out the DLL hell, Part 2: The Solution

Post published:November 9, 2015
Post comments:7 Comments
Reading time:5 mins read

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.

(more…)

Sorting out the DLL hell, Part 1: The Problem

Post published:November 6, 2015
Post comments:12 Comments
Reading time:6 mins read

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.

(more…)

How To Update a Class Or Assembly Reference in C/AL And Retain Event Trigger Code

Post published:April 16, 2015
Post comments:4 Comments
Reading time:5 mins read

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.

(more…)