How best to use File Version and Assembly Version?

Question

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.

Answer 1

I keep them the same. But then, I don't have multifile assemblies, which is when the AssemblyVersion number becomes important. I use Microsoft-style date encoding for my build numbers, rather than auto-incrementing (I don't find the number of times that something has been built to be all that important).

Answer 2

In a scenario where I have multiple file assemblies (i.e. 1 exe and 5 dlls) I will use a different file version for each, but the same assembly version for all of them, allowing you to know which exe each of the dlls go with.

Answer 3

@Adam: Are you changing the file version with each build? Are you using version control (SYN or VSS) and using that information to link source back to the binaries?

Seems to make sense that the Assembly version stays the same. i.e. "2.0.0.0". That corresponds to the deployment of the product.

The file version changes to match the revision from the source control. "2.0.??.revision" This would provide a link from a specific dll (or exe) to the source that built it.

Answer 4

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= "3.0.216.0"; // 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.

Answer 5

The KB article mentions the most important distinction: File versions are only used for display purposes, whereas the assembly version plays an important part in the .NET loading behaviour.

If you change the assembly version number, then the identity of your assembly as a whole has changed. Developers will need to rebuild to reference your new version (unless you put some auto-versioning "policy" in place) and at runtime only assemblies with matching version numbers will be loaded.

This is important in my environment, where we need an incrementing, highly visible version number for audit purposes, but we don't want to force developers to rebuild or have many versions concurrently in production. In this case for backwardly-compatible minor changes we update the file version, but not the assembly version.

Answer 6

File versions are only used for display purposes, whereas the assembly version plays an important part in the .NET loading behaviour.

Not quite. The file version is also important for Windows Installer when you upgrade an existing version over a previous one.

Answer 7

With my current application, each VS project has a link to an "AssemblyBuildInfo" source file which has the following attributes:

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyCompany("Acme Corporationy")]
[assembly: AssemblyCopyright("Copyright ©  2009 Acme Corporation")]

This way, all the assemblies in my solution share same version and company information (meaning if I have to change it, I change it only one time). By excluding the FileVersion, it is automatically set to the AssemblyVersion.