How to display ClickOnce Version number on Windows Forms

I have a windows forms application that is deployed to two different locations.

• Intranet - ClickOnce
• Internet - Installed on a citrix farm through Windows installer

I display ClickOnce version number for click-once deployed versionApplicationDeployment.IsNetworkDeployed.

if (ApplicationDeployment.IsNetworkDeployed)
        return ApplicationDeployment.CurrentDeployment.CurrentVersion;

But for the non-click application, I am not sure how to retrieve clickonce version unless I hardcode the version number in assembly info.

Is there an automatic way of retrieve ClickOnce version number for non-clickonce deployed version?

1. Add an assembly reference to System.Deployment to your project.

2. Import the namespace in your class file:

VB.NET:

    Imports System.Deployment.Application

C#:

    using System.Deployment.Application;

3. Retrieve the ClickOnce version from the CurrentVersion property.

You can obtain the current version from the ApplicationDeployment.CurrentDeployment.CurrentVersion property. This returns a System.Version object.

Note (from MSDN):

> CurrentVersion will differ from UpdatedVersion if a new update has > been installed but you have not yet called Restart. If the deployment > manifest is configured to perform automatic updates, you can compare > these two values to determine if you should restart the application.

NOTE: The CurrentDeployment static property is only valid when the application has been deployed with ClickOnce. Therefore before you access this property, you should check the ApplicationDeployment.IsNetworkDeployed property first. It will always return a false in the debug environment.

VB.NET:

    Dim myVersion as Version

    If ApplicationDeployment.IsNetworkDeployed Then
       myVersion = ApplicationDeployment.CurrentDeployment.CurrentVersion
    End If

C#:

    Version myVersion;

    if (ApplicationDeployment.IsNetworkDeployed)
       myVersion = ApplicationDeployment.CurrentDeployment.CurrentVersion;

4. Use the Version object:

From here on you can use the version information in a label, say on an "About" form, in this way:

VB.NET:

    versionLabel.Text = String.Concat("ClickOnce published Version: v", myVersion)

C#:

    versionLabel.Text = string.Concat("ClickOnce published Version: v", myVersion);

(Version objects are formatted as a four-part number (major.minor.build.revision).)

No I do not believe that there is a way. I believe the ClickOnce information comes from the manifest which will only be available in a ClickOnce deployment. I think that hard coding the version number is your best option.

I would simply make the assembly version of the main assembly the same as the CLickOnce version every time you put out a new version. Then when it runs as a non-clickonce application, just use Reflection to pick up the assembly version.

Try thread verification:

if (ApplicationDeployment.IsNetworkDeployed)
{
	if (ApplicationDeployment.CurrentDeployment.CurrentVersion != ApplicationDeployment.CurrentDeployment.UpdatedVersion)
	{
		Application.ExitThread();
		Application.Restart();
	}
}

To expand on RobinDotNet's solution:

Protip: You can automatically run a program or script to do this for you from inside the .csproj file MSBuild configuration every time you build. I did this for one Web application that I am currently maintaining, executing a Cygwin bash shell script to do some version control h4x to calculate a version number from Git history, then pre-process the assembly information source file compiled into the build output.

A similar thing could be done to parse the ClickOnce version number out of the project file i.e., Project.PropertyGroup.ApplicationRevision and Project.PropertyGroup.ApplicationVersion (albeit I don't know what the version string means, but you can just guess until it breaks and fix it then) and insert that version information into the assembly information.

I don't know when the ClickOnce version is bumped, but probably after the build process so you may need to tinker with this solution to get the new number compiled in. I guess there's always /*h4x*/ +1.

I used Cygwin because *nix scripting is so much better than Windows and interpreted code saves you the trouble of building your pre-build program before building, but you could write the program using whatever technology you wanted (including C#/.NET). The command line for the pre-processor goes inside the PreBuildEvent:

<PropertyGroup>
  <PreBuildEvent>
    $(CYGWIN_ROOT)bin\bash.exe --login -c refresh-version
  </PreBuildEvent>
</PropertyGroup>

As you'd imagine, this happens before the build stage so you can effectively pre-process your source code just before compiling it. I didn't want to be automatically editing the Properties\AssemblyInfo.cs file so to play it safe what I did was create a Properties\VersionInfo.base.cs file that contained a text template of a class with version information and was marked as BuildAction=None in the project settings so that it wasn't compiled with the project:

using System.Reflection;
using EngiCan.Common.Properties;

[assembly: AssemblyVersion("0.$REVNUM_DIV(100)$.$REVNUM_MOD(100)$.$DIRTY$")]
[assembly: AssemblyRevisionIdentifier("$REVID$")]

(A very dirty, poor-man's placeholder syntax resembling Windows' environment variables with some additional h4x thrown in was used for simplicity's/complexity's sake)

AssemblyRevisionIdentifierAttribute was a custom attribute that I created to hold the Git SHA1 since it is much more meaningful to developers than a.b.c.d.

My refresh-version program would then copy that file to Properties\VersionInfo.cs, and then do the substitution of the version information that it already calculated/parsed (I used sed(1) for the substitution, which was another benefit to using Cygwin). Properties\VersionInfo.cs was compiled into the program. That file can start out empty and you should ignore it by your version control system because it is automatically changing and the information to generate it is already stored elsewhere.

Hard code, or... Keep track on your versions (File, Assembly, Deploy) in a database. Make a call to the database with your Assembly and get the Deploy version.

This assumes that you are incrementing your versions in a logical way such that each version type has a relationship. It's a lot of work for such a minor problem. I'd personally go with Jared's solution; although I hate hard coding anything.

Using a build component, you could read the click-once version from the project file and write it automatically to the assembly info so both of them are in sync.

not that it matters three years later, but I ended up just parsing the manifest file with xml reader.

Do a thread verification, insert harded code...