1

Using windows, I can uninstall software via script/command line as follows:

msiexec /x {00000000-0000-0000-0000-000000000000}

Is there a method to just test for the existence of the given package, without affecting it?

I'm interested in a true/false or any other input, indicating whether the package exists on the machine, and can be removed using Windows installer with the given command.

For context: I'm using NSIS, and need to modify my installer behavior in case a specific package is found. Command-line can be used as it can return values, and VBScript can be used via cmd as well.

Absolutely no affect on the package is mandatory, and also no indication of the process to the user, so repair isn't acceptable for example.

Selfish
  • 6,023
  • 4
  • 44
  • 63
  • What are your criteria? Command-line only vs. VBScript vs. write a C++ program? Hack vs. future-proof? Absolutely no affect on the package, or just nominally no effect (is running repair on a package acceptable)? – Michael Urman Jan 06 '16 at 13:03
  • @MichaelUrman - I have updated the question with a response. As for creating a dedicated utility, this would be a total overkill for my needs, and for that I will no have needed a stack overflow question. :) – Selfish Jan 06 '16 at 13:43
  • Adding just for reference: [Detecting VC++ Runtime](https://stackoverflow.com/questions/53638587/wix-per-user-installer-to-detect-the-visual-c-2015-redistributable/53639128#53639128). And a direct link too: [MSDN: How to programmatically check for the presence of a Windows Installer-based product by using its product code](https://support.microsoft.com/de-ch/help/974653/how-to-programmatically-check-for-the-presence-of-a-windows-installer). – Stein Åsmul Sep 18 '19 at 10:29

1 Answers1

2

The "proper" way to find this out is to call a function such as MsiQueryProductState. This is available in various other fashions including the VB-accessible Installer.ProductState property. If instead you're trying to generate a list of what is on the machine, MsiEnumProducts or Installer.Products (or their Ex variants) are more appropriate. It appears that PowerShell can access equivalent information through WMI calls.

Less proper approaches would include calling msiexec /f {PROD-UCT-CODE} to either repair the product or fail to find it, or querying the registry directly for the presence of the product's Uninstall key entry, (it's subkey name matches the {PROD-UCT-CODE}; check both 32-bit and 64-bit keys as well as both per-machine and per-user installations as required) for example with reg query.

Community
  • 1
  • 1
Michael Urman
  • 15,737
  • 2
  • 28
  • 44
  • Thank you for the detailed response. As for the first paragraph, it seems to be C++ specific, isn't it? My context isn't C++, so this is an overkill for me. I could easily created a dedicated utility, but I'm looking to avoid doing that. – Selfish Jan 06 '16 at 13:45
  • It includes both c/c++ api calls and vb equivalents. You mention that vb works for you so check out the installer object properties. – Michael Urman Jan 06 '16 at 14:50