.net vs product - How best to use File Version and Assembly Version?

3 Answers

In solutions with multiple projects, one thing I've found very helpful is to have all the AssemblyInfo files point to a single project that governs the versioning. So my AssemblyInfos have a line:

[assembly: AssemblyVersion(Foo.StaticVersion.Bar)]

I have a project with a single file that declares the string:

namespace Foo
    public static class StaticVersion
         public const string Bar= ""; // 08/01/2008 17:28:35

My automated build process then just changes that string by pulling the most recent version from the database and incrementing the second last number.

I only change the Major build number when the featureset changes dramatically.

I don't change the file version at all.

managing versions of

In .NET there are two version numbers available when building a project, File Version and Assembly Version. How are you using these numbers? Keeping them the same? Auto-incrementing one, but manually changing the other?

Also what about the AssemblyInformationalVersion attribute?

I'd found this support Microsoft Knowledge Base (KB) article that provided some help: How to use Assembly Version and Assembly File Version.

What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?


Where other assemblies that reference your assembly will look. If this number changes, other assemblies have to update their references to your assembly! The AssemblyVersion is required.

I use the format: major.minor. This would result in:

[assembly: AssemblyVersion("1.0")]


Used for deployment. You can increase this number for every deployment. It is used by setup programs. Use it to mark assemblies that have the same AssemblyVersion, but are generated from different builds.

In Windows, it can be viewed in the file properties.

If possible, let it be generated by MSBuild. The AssemblyFileVersion is optional. If not given, the AssemblyVersion is used.

I use the format: major.minor.revision.build, where I use revision for development stage (Alpha, Beta, RC and RTM), service packs and hot fixes. This would result in:

[assembly: AssemblyFileVersion("1.0.3100.1242")]


The Product version of the assembly. This is the version you would use when talking to customers or for display on your website. This version can be a string, like '1.0 Release Candidate'.

Unfortunately, when you use a string, it will generate a false warning -- already reported to Microsoft (fixed in VS2010). Also the Code Analysis will complain about it (CA2243) -- reported to Microsoft (not fixed in VS2013).

The AssemblyInformationalVersion is optional. If not given, the AssemblyFileVersion is used.

I use the format: major.minor [revision as string]. This would result in:

[assembly: AssemblyInformationalVersion("1.0 RC1")]

AssemblyVersion pretty much stays internal to .NET, while AssemblyFileVersion is what Windows sees. If you go to the properties of an assembly sitting in a directory and switch to the version tab, the AssemblyFileVersion is what you'll see up top. If you sort files by version, this is what's used by Explorer.

The AssemblyInformationalVersion maps to the "Product Version" and is meant to be purely "human-used".

AssemblyVersion is certainly the most important, but I wouldn't skip AssemblyFileVersion, either. If you don't provide AssemblyInformationalVersion, the compiler adds it for you by stripping off the "revision" piece of your version number and leaving the major.minor.build.