Creating a .NET Assembly, the importance of versioning
Everyone who has ever created a .NET DLL for his NAV project will probably have run into different kind of issues concerning versioning.
- Either unable to overwrite without stopping the Server Instance
- Not having the right assembly loaded
- Having to replace your assembly in code and losing your events
In this post, I’ll have some information about versioning, the importance of versioning and some tricks.
Difference between the versions
Well, let’s start with the 2 types of versions we have in .NET:
– Assembly Version
– File Version
Both do something completely different, I’ll show you what a bit further.
But basically, the file version is merely the version show in File Details, while the assembly version is the version which is used by NAV as reference.
The basics
Let’s have a look at this sample:
I have created a simple Class Library with 1 function:
After building, this is the result:
I copy my DLL into my server Add-Ins folder and create a simple codeunit:
And this is the result:
Alright, let’s start playing with the versions. First I have added an extra function:
Then I copied my DLL to my Add-in Folder and guess what:
This means my DLL was referenced since the start of my NST and is in use. The only option is to stop my Instance and delete it before overwrite. By the way, this could result in all sorts of funky stuff, as Vjeko has already blogged about: Read here.
Here is where versioning will come handy.
Changing Assembly Version
And this is what the file details show:
Next I change my assembly version and build:
So, what do we see in the File Details? Exactly, still showing 1.0.0.0.
I overwrite my file in the addin folder and this is what NAV shows when trying to view the available Assemblies:
Only the lastest version is available, being the 1.1.0.0 assembly version (I had overwritten my previous file).
If I don’t change my code to the new assembly, and run it, I’ll get an error that assembly version 1.0.0.0 is not found.
Changing the File Version
This time, I’ll change only the file version:
Leaving the assembly on 1.1 and changing the file version to 1.2.
This is what the File Details say:
Still as expected right?
This time, I change my DLL name to add 1.2 in the name, and copy it in my Addin folder.
NAV still only shows 1 line, with assembly version 1.1. Which it will actually execute, you can only guess…
My code doesn’t need to be changed though. It will still run because the assembly version is the same
If I had overwritten the file, the new file should be used, without needing to change my codeunit reference, but… I might need to restart the Service Tier. Or all Service Tiers, if there on the same executable…
Wanted? Definitely not.
Changing both Assembly & File Version
Also copied into the addin folder again, this is what NAV shows:
2 versions. Which can be used at the same time.
Versioning Conclusion
Keep your file / assembly version the same. It is much easier to know which version the file represents.
DO version… Keep your version in a folder per version.
This way, we can put a newer version into the production environment without having to stop it when in use.
This way, we can test the new assembly if the Service Tiers are on the same executable, but with different instances.
What are the issues?
Well, let’s check this: I have created version 1.4 with an event in it:
In NAV I did the following:
This creates my event, and I have changed my code as following:
Let’s assume I have made little mistake in my .NET code and only change the sleep to 5000 milliseconds:
When in NAV I select version 1.5.0.0. This happens:
If I choose yes, this happens:
The event is created again, but my code is gone…
When I select no, the assembly isn’t changed.
It is a bit annoying…
It is possible to export as text, and change the assembly version, so the code will take the correct version without losing your code, but your signatures will not update if they were changed.
To make this easier, you should keep you DLL references in a single codeunit, and use this codeunit everywhere you wish to use the assembly. This makes it easier for you to update all your assembly references.
A solution for the changing signature is to create a custom EventArguments class. Just a simple class with properties. Always return this in the signature. This way, you could add properties in the class, and use them in NAV without changing the signature.
*This post is locked for comments