Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Dec 31, 2012 07:47 PM by adamturner34
Dec 31, 2012 07:29 PM|LINK
Can someone please explain the difference between the AssemblyVersion and AssemblyFileVersion attributes in the AssemblyInfo.cs file? My company needs to come up with a versioning policy and right now it seems every developer is doing it differently which
is becoming a problem.
I see this:
// Version information for an assembly consists of the following four values:
// Major Version
// Minor Version
// Build Number
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
I understand what Major Version, Minor Version, Build Number, and Revision means. I personally have been using using the default build and revision numbers (using "*"), but it seems for a lot of our projects the AssemblyFileVersion isn't even specified.
I've looked this up and I can never get a straight answer. For blogs/posts/etc. where there is feedback, there is usually a lot of disagreement with what the original author says.
We have to provide release notes with every deployment to production and I know the version number is essentially meaningless to the end users, but for the development team these numbers matter. We are using TFS but at this time only for source control;
we are not using the build server that comes with it.
From the looks of it, there is also an AssemblyInformationalVersion attribute but I don't know if I should be concerned about that. We aren't selling software; everything is used within the company.
Dec 31, 2012 07:35 PM|LINK
It only matters how you use the attribute/property really.
If you identify the assembly by AssemblyVersion, then AssemblyFileVersion is meaningless unless "you" find your own definition of it.
Honestly, these properties/attributes are really designed for "you" to use however you see fit. It is your decision not the authors.
For all intents and purposes, you could call it a WidgetVersion.
Dec 31, 2012 07:39 PM|LINK
We need to start tagging releases in TFS so we need some convention to identify these. We've had too many cases in the past where we had two DLLs with the same version number having completely different contents and thus were not interchangeable.
Dec 31, 2012 07:47 PM|LINK
Again, it's up to how you want to use them as identity features. However, bear in mind the display of the properties in windows7: