Should .NET Assembly names include a version number?
We currently have a heated internal debate as to whether the actual .NET assembly name should include the code's version number (e.g. CodeName02.exe or CompanyName.CodeName02.dll). Does anyone know of an authoritative source, like Microsoft, that provides guidance on this issue?
This is what the Properties/AssemblyInfo.cs file is for.
There are two versions within that file, the file version and the assembly version:
[assembly: AssemblyVersion("126.96.36.1996"] [assembly: AssemblyFileVersion("188.8.131.526")]
Once these are set you can use them to track the versions of you binaries. It is easily viewed in explorer with right click->properties.
None of the dll or exe names included in Microsoft's applications (and OS) use that convention.
Other systems will use these numbers to resolve dependencies and verify the version. For example the MSI system will update binaries based on the version properties.
I further support this (NOT using version #) because the GAC and dll file properties will show the version.
I'm not aware of anything authoritative, but it would seem to me that using a consistent name would simplify everything from the process of installation scripts to documentation. Given that one can store the version as metadata on the file, I don't know why it would be needed in the filename. Why set yourself up for the hassle of having to account for differently-named files?
just look at the .NET framework or any other microsoft product for that matter. putting a version number as part of the assembly name sounds like a bad idea.
There is a place for this (and other information) in the assembly's meta-data section. (AssemblyInfo.cs)
This information can be view in Windows Explorer (properties dialog,status bar, tooltip - they all show this information).
I know DevExpress website use version indicators as part of their assembly names such as XtraEditors8.2.dll. I guess the reason is that you want to be able to have multiple versions of the assembly located in the same directory. For example we have about 15 smartclients that are distributed as part of the same shell/client. Each smartclient can have a different version of DevExpress controls and therefore we need to be able to have XtraEditors7.1.dll and XtraEditors8.2 existing in the same directory.
I would say that if you have common libraries that are dependencies of reusable modules and can exist in multiple versions 1.0, 1.1, 1.2 etc. then it would be a valid argument that version numbers could be included in the name to avoid collisions. Given that the common libs are not living in the GAC.
I think the main idea of putting a version number in the filename of a DLL is brought over from DLL Hell, where having multiple versions of the DLL, all with the same name caused problems (i.e. which actual version of a DLL do you have and does it have the required functions, etc).
The .NET Framework handles dependencies completely different compared to the C/C++ DLL files that are more traditional, it is possible to have multiple versions of a library in the GAC, mainly because the GAC is a 'fake' folder that links to other files on the filesystem, in addition to being able to have the assemblies included with your executable install (same folder deploy, etc).
The version information can be contained in assemblyInfo file and can then be queried via reflection etc.
Some vendors include the version number in the name to make it easier to see at a glance what it is. The Microsoft dll names dont contain a version number in framework directory.
Since the version can be set as a property isn't this semi redundant?
I'd also go on a limb and suggest MS doesn't have a standard given a quick look at their DLL names: user32.dll, tcpmon.dll, winsock.dll, etc.
Microsoft used a suffix of 32 to denote 32 bit DLL versions so that those DLL's could coexist with the existing 16 bit DLL files.