Assembly

Programming is not a 20th century invention. Ideas behind what we call programming have existed since at least the 9th century. The very term “algorithm” comes from the name of Muhammad ibn Musa al-Khwarizmi, a mathematician born around 780 somewhere in modern-day Uzbekistan.

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.

[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.

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.

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.

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.