4

Consider the following scenario--

Let's assume you are writing an application that needs to use a specific Windows application. Specifically, it's an application that installs various API tools intended to provide application integration into some other Microsoft software or service.

Now, let's make a couple of other assumptions, which are as follows:

  • Your application doesn't care which version of this tool is installed since version changes tend to be only minor updates that fix bugs or are patches to get the components to properly install on different versions of Windows.
  • You are writing an international tool, so there is a chance that the Microsoft component tool that you need is installed on your end-users machine, but it could be installed under a non-English name.
  • Also, your application is distributed within a zip file. Your user does not install your software, so you can't create an installer perquisite. Instead, you must run your application and then check to see if the needed Microsoft tool has been installed.

Using C#, is there a standardized way of checking to see if an application has been installed. Specifically, is there some WMI call or registry query that when executed returns some form of unique identifier that is intended to represent a value uniquely representing the installed application, regardless of the applications installation name or version?

Every question on SO, or other places on the web, that I can find regarding checking for installed software recommends checking to see if the software has been installed by looking it up by name. This would work, however, our software is a global tool that is used on machines with various cultural settings. What we've found is that this naive check doesn't work, even after we provide the install file, because the localization settings in the Microsoft Installer are renaming the application on the machines that are setup for a different, non-English locale.

Is there a "formalized" solution to this problem? As in, is there a documented approach as to how one may check for such software, assuming the developer of the specific tool you are checking for has properly setup their installers to properly configure these ID values?

As an aside, we actually have a couple of Microsoft tools that we need to check for. I didn't want to include a list because I'm hoping there is a moderately straight-forward approach to solving this need for multiple, different tools.

RLH
  • 15,230
  • 22
  • 98
  • 182
  • Have you considered checking the registry in HKEY_CLASSES_ROOT? I believe there should be a unique CLSID for a particular class. I might be wrong though. For example, in my registry: `HKEY_CLASSES_ROOT\Microsoft.PhotoAcquire\CLSID` has a value of `{00f26e02-e9f2-4a9f-9fdd-5a962fb26a98}`. – rory.ap Feb 09 '17 at 18:50
  • @rory.ap Possibly, the problem with that is I can't find a confirmation, anywhere, whether that should likely be the same value across variations of versions of the same application. I've found a couple values that *look* like they could work, but there's no explicit documentation stating that a value like this could (or even should) be consistent. – RLH Feb 09 '17 at 18:54
  • I'd seriously consider re-visiting your first assumption. Of the *currently released* versions you know your code is safe working with any of them. But I'd be very wary of asserting that your code will work safely with all future versions that haven't even been written yet. – Damien_The_Unbeliever Feb 10 '17 at 07:33
  • @Damien_The_Unbeliever I normally understand that but this this is a very small, kind of obscure little tool and isn't much more than a hotfix. The problem is that some users could have minor variations and for one specific tool that we use, tracking down versions that will work properly (which is basically all of them so far) is tough to find because there isn't a good version list available with all of the details that we need. Also, our customer base is in the hundreds. We are trying to cover the 99% of cases. The other 1% can contact support and we can help them personally. – RLH Feb 13 '17 at 14:29

1 Answers1

2

Here are two relevant answers that will help you:

Finding installed applications

Finding UpgradeCode

Basically there are two GUID values you need to know about: ProductCode and UpgradeCode.

ProductCode identifies the exact installation package used, and should be completely different for each build (assuming the installer was programmed correctly).

UpgradeCode identifies the overall product itself, and should not change between versions (again, assuming the installer was programmed correctly). This is what you need to look for.

One thing you might want to check is whether the developer used different UpgradeCodes for different language versions of the product.

Community
  • 1
  • 1
smead
  • 1,768
  • 15
  • 23
  • 1
    And yes, the names ProductCode and UpgradeCode seem like they should've been chosen the other way around. Who knows what Microsoft was thinking :) – smead Feb 09 '17 at 19:51
  • Well, Foo 1.0 and Foo 2.0 Enterprise Edition are two different products. But for upgrade purposes, the Foo 2.0 EE installer should be able to find Foo 1.0/1.1/1.2 without needing an exhaustive list of all applicable products. So the names do make sense. – Zastai Feb 10 '17 at 08:24
  • ProductCode (stable) and ReleaseCode / VersionCode (changing) would make a lot more sense. Typical Microsoft. – Ondrej Tucny Feb 11 '17 at 11:30
  • FYI, this is likely the answer. I've been out of commission for a quite a while with a viral-cold AND strep throat. When I get the chance to experiment and look at these values, I will. Thank you. – RLH Feb 13 '17 at 14:31