How do I programmatically get the product (not assembly) version of a running program using C#?

Question

I have a program that I have written and am trying to create an about box for. I recently updated my program's product version to 1.00.0003, and I want this to be reflected in the about window.

The default setup of the aboutBox shows a value of 1.0.0.0, which is the assembly version, not the product version. I have since been scouring the Internet to find how to get the product version to be shown. I have tried all of these:

{
    Assembly assembly = Assembly.GetExecutingAssembly();
    FileVersionInfo fileVersionInfo = FileVersionInfo.GetVersionInfo(assembly.Location);
    string version = fileVersionInfo.ProductVersion;

    Debug.WriteLine(version);
    Debug.WriteLine(assembly.GetName().Version);
    string v = VersionNumber;
    Debug.WriteLine(v);
    Debug.WriteLine( fileVersionInfo.FileVersion);
    Debug.WriteLine(Application.ProductVersion);
    Debug.WriteLine(AssemblyProductVersion);


    Assembly assembly2 = Assembly.GetEntryAssembly();
    FileVersionInfo fileVersionInfo2 = FileVersionInfo.GetVersionInfo(assembly.Location);
    string version2 = fileVersionInfo2.ProductVersion;
    Debug.WriteLine(version2);
    Debug.WriteLine(assembly2.GetName().Version);

    return version;
}

private string _ourVersion = "Version: v";

private string VersionNumber
{
    get
    {
        System.Reflection.Assembly _assemblyInfo =
        System.Reflection.Assembly.GetExecutingAssembly();
        if (System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed)
            _ourVersion += ApplicationDeployment.CurrentDeployment.CurrentVersion.ToString();
        else
        {
            if (_assemblyInfo != null)
                _ourVersion += _assemblyInfo.GetName().Version.ToString();
        }
        return _ourVersion;
    }
}

private static string AssemblyProductVersion
{
    get
    {
        object[] attributes = Assembly.GetExecutingAssembly()
            .GetCustomAttributes(typeof(AssemblyInformationalVersionAttribute), false);
        return attributes.Length == 0 ?
            "" :
            ((AssemblyInformationalVersionAttribute)attributes[0]).InformationalVersion;
    }
}

Every single one of these returns 1.0.0.0 (yes, I did look for their output in the console, not what was actually displayed), instead 1.00.0003 like I need. The product version is set in the General Information tab of the InstallShield setup. When it is installed, going to Programs and Features shows a Product Version of 1.00.0003, so I cannot figure out why this is so hard to programmatically retrieve this value. Any ideas?

Caesalpiniaceous

If the first place that you're setting this version information is in the installer, you shouldn't expect any of the compiled files to contain this information. Apparently, as you've set things up, only the installer knows about its version. – Vo

@Vo How would I set it so that if I change the version in the installer, everything else changes accordingly? – Caesalpiniaceous

you're thinking about it the wrong way around. You should be manually updating the assembly information and having the installer pick up that change, as per devdigital's answer. – Vo

Answer 1

Your product version should match the assembly version - have a look at How to make Product Version property match executable's version number automatically

Grown

Correct me if I am wrong, but doesn't that require manually updating the command line argument for each build? – Caesalpiniaceous

Well typically you'd have a source code repository and a build server to automate this. For example TeamCity would have its own build number and when you commit a change or want to do a release, it would automatically apply that number to all assemblies and you'd have another build step which applied the number to your installshield build. This allows you to inspect the assembly for the build number and track it all the way back to the source code revision. – Grown

Being a single developer and still in school, those seem a little out of my reach. – Caesalpiniaceous

You can either perform this manually, configure a source repository and CI sever locally (they can be your development machine, TeamCity is free up to a certain number of build configs) or you could have a look at online services which provide these features for you (e.g. Bitbucket) – Grown

Is there not just some simple way to keep the two numbers in sync? That seems like a lot of work for something so simple. – Caesalpiniaceous

@Caesalpiniaceous - yes, there is a simple way to keep them in sync. Every time you go and edit one of them, remind yourself that you need to go and edit the other one. Maybe a post-it note attached to your monitor? – Vo

@Garrett- Consider this an excellent opportunity to learn some very critical CM skills. Skills they probably aren't teaching you in school. You can get free TFS as a service at www.visualstudio.net and even use their cloud to do your builds. You just have to set up your builds. – Mezzanine

Answer 2

The version 1.00.0003 you want to retrieve is the version of the installer of your product. To get this version programmatically you need to inspect the installer (MSI file), not the installed files. I'm not sure that is what you want to do but there is a answer to the question Checking ProductVersion of an MSI programatically that explains how to do that.

If you want your executable files to contain the same version number you need to store the version number in some way either using a .NET attribute like AssemblyFileVersion or a Windows VERSIONINFO resource.

InstallShield allows you to specify the product version on the command line. This allows you to store your product version in a single file and then use that as the source of both the product version embedded in your installer as well as AssemblyFileVersion of your assemblies.

Playroom

Answer 3

If only the installer knows about this version information, the only place you could retrieve it from would be the registry.

Uninstall Registry Key:

The following installer properties give the values written under the registry key:

VersionMinor Derived from ProductVersion property

VersionMajor Derived from ProductVersion property

Version Derived from ProductVersion property

But I'd go with @devdigital's (implied) suggestion - you ought to have one of the assembly versions actually matching your installer version.

Vo