Go Back

How Can I Programatically Extract the Version of the Runtime?

As it says on the tin, how can I programmatically extract the runtime that is currently installed on a Windows Machine?

The reason this is required is we are trying to setup our Bamboo CI Agents (https://confluence.atlassian.com/bamboo/configuring-remote-agent-capabilities-using-bamboo-capabilities-properties-289276849.html) to contain additional capabilities based on certain versions of Synergy. We are trying to write scripts to help us automate the configuration of these agents and need the ability to know what version of the runtime we have installed to shove into a text file similar to the following:


This information is then queried by Bamboo CI to understand what agents it can and cannot allocate to a particular task.

7 Answers
0   | Posted by Ace Olszowka to Installation on 9/24/2020 8:02 PM
Steve Ives
Does this help? It's a .NET console app that determines the location of 32-bit and 64-bit Synergy installs, then looks at the product version number string in DBR.EXE and reports them out to the console.

This was thrown together quickly, so in order for the registry lookups to work correctly it is important to build the code for X64.

If this is useful, you can grab the project at https://github.com/SteveIves/GetSynergyVersion
import System
import System.Diagnostics
import System.IO
import Microsoft.Win32

namespace GetFileVersion

    ;;; <summary>
    ;;; Report the installed version of Synergy/DE.
    ;;; IMPORTANT: For the registry code to work correctly, build this .NET Console application for 64-bit
    ;;; </summary>
        Console.WriteLine("32-bit Synergy: " + VersionTools.GetSynergy32Version())
        Console.WriteLine("64-bit Synergy: " + VersionTools.GetSynergy64Version())

    public static class VersionTools

        private static patchLetters, [#]string, new string[#] {"a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z"}

        public static method GetSynergy32Version, string
            mreturn GetSynergyVersion(Registry.GetValue("HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Synergex\Install","SDELOC",""))

        public static method GetSynergy64Version, string
            mreturn GetSynergyVersion(Registry.GetValue("HKEY_LOCAL_MACHINE\SOFTWARE\Synergex\Install","SDELOC",""))

        private static method GetSynergyVersion, string
            required in sdeLocation, @object
            if (sdeLocation==^null) then
                mreturn "Not installed!"
                data dbrpath = Path.Combine(sdeLocation.ToString(),"dbl\bin\dbr.exe")
                data fvi = FileVersionInfo.GetVersionInfo(dbrpath)
                mreturn String.Format("{0}.{1}.{2}{3}",fvi.ProductMajorPart,fvi.ProductMinorPart,fvi.ProductBuildPart,patchLetters[fvi.ProductPrivatePart])



10/1/2020 11:05 PM   0  
Jeff Gill
Hi Ace
We use the Synergy function %versn and parse the output
User-added image
Plus a whole heap of other stuff from within the system at runtime

10/2/2020 1:28 AM   0  
Steve Ives
Another option is the installers record the version in the registry also. The patch level is in numeric format, so it needs some parsing, but it’s another option.

10/2/2020 1:32 AM   0  
Ace Olszowka
Thank you all for the replies.

@Steve The Registry Key is probably the most idea, the numeric format is more than good enough, the agent just needs to know what version it is on. Can we rely on those registry keys being there in the future?

10/2/2020 1:08 PM   0  
Steve Ives
I have spoken to people in dev who have agreed to add in-code documentation recording that customers have tooling that depends on the presence and format of the version numbers in the registry, and that as a result the presence and format of the information should not change unless our entire versioning scheme changes.

Be aware though that we are considering a change in how we version label releases, possibly going to a build number scheme rather than patch letters. If that happens, the registry information would have to change accordingly.

10/2/2020 7:21 PM   0  
Ace Olszowka
That sounds great to me, the values in there really don't matter so long as they are unique, its just a string comparison.

Its important to have the location be known though that way the tooling can be standardized across versions.

10/2/2020 7:52 PM   0  
Steve Ives
User-added image

User-added image

10/3/2020 1:19 AM   0  
Please log in to comment or answer this question.