tags:

views:

854

answers:

9

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?

+2  A: 

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?

ahockley
A: 

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.

alexmac
+2  A: 

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

Asher
A: 

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.

Gavin Miller
These are not .NET components - they are native win32 and are subject to "DLL hell." In .NET, the gac is used to provide versioning and allows subsequent DLLs to have the same physical name.
x0n
I'm not sure that citing 20 years of software archaeology is terribly relevant! Names from that era had to be 8.3, which tends to rather dominate the debate.
Will Dean
+10  A: 

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("1.1.0.256"]
[assembly: AssemblyFileVersion("1.1.0.256")]

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.

csexton
How do you increase the build number automatically after each build? Or do I have to manually open this file up and change the maj, min, build number each time?
ray247
use and * rather then a number and the build will auto increment the value. 1.1.*
Aaron Fischer
You could also set AssemblyInformationalVersion which ends up as the "ProductVersion" VERSIONINFO field.
Christian.K
ray247, that is a problem we have faced--and we handled it by using the svn number. A bit of a hack involving a pre build event, a vbs script, and finally a svn revert.
csexton
If you change the assembly name with the version, consumers of the assembly will need to update their references in order to use new versions instead of just recompiling.
CodeSavvyGeek
A: 

I don't see them but what would be the advantages of putting the version number in the file name?

TT
+6  A: 

Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams of Microsoft suggests assembly naming like

<Company>.<Component>.dll

I further support this (NOT using version #) because the GAC and dll file properties will show the version.

Anthony Mastrean
And, as stated, the assembly version can be accessed through the Assembly properties in AssemblyInfo.cs
Anthony Mastrean
+1  A: 

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

Redbeard 0x0A
+2  A: 

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.

Fadeproof
I do it for exactly that reason I have shared dll's on a network drive used by multiple programs and people. If there is a problem in uptime I can upgrade a dll and program relying on it without affecting users.
PeteT