Over the course of creating my videos, I have created a number of demos, and massive amount of code (well, massive in relation to the duration of videos). So, with Microsoft’s agreement, I have published all of the demonstrated C# and PowerShell code to my GitHub repository.
If you haven’t watched the videos yet, then please do.
And then, just visit this:
Over the past month or so I was very busy with the Microsoft Dynamics NAV Managed Service for Partners. One part was in line of my work, where we were busy around the clock bringing our solution to Managed Service. The other part was creating a handful of videos for Microsoft to promote Managed Service.
Both were quite a ride, and now I have to show for some results.
If you are developing .NET assemblies for use with NAV, then sooner or later you’ll figure out that the new database deployment of add-ins in NAV 2016 is broken.
I’ve just suffered through medieval torture of attempting to have my NAV forget about a database-deployed assembly.
First of all – if you are merely consuming an off-the-shelf assemblies developed by somebody out there, you’ll probably not need to worry at all. However, if you are developing your own assemblies, then sooner or later you’ll find yourself stretched in exactly the same torture rack.
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.
If you didn’t have a chance to attend NAV TechDays 2015 in Antwerp last month, don’t worry – you won’t miss much, at least as the conference content goes. As…