1

I have a .NET winform installer application. Before installing, I'm doing a registry search to check if MS Access Runtime is installed on the machine.

Search Target Machine

Properties of Search Target Machine

Launch Conditions

Properties of Launch Condition

However i want to avoid hard coding the path like "C:\Program Files\Microsoft Office\Office15\" in the properties of launch condition. So far i have tried "[ProgramFilesFolder]\Microsoft Office\Office15\", "%ProgramFiles%\Microsoft Office\Office15\" but both the options are not working.

Sid
  • 123
  • 2
  • 10
  • Are you on 32-bit Windows? How `[ProgramFilesFolder]` was resolved? – montonero May 06 '19 at 14:50
  • Maybe use a file search instead of registry search. Than you can hard-code the path `Folder`: `[ProgramFilesFolder]\Microsoft Office\Root\Office15\ ` and `File`: `MSACCESS.EXE`. You could also do a version check. – Eliahu Aaron May 07 '19 at 10:29
  • Hi @montonero, yes i'm first testing on a 32-bit machine. But "[ProgramFilesFolder]\Microsoft Office\Office15\" is not working when i use it instead of "C:\Program Files\Microsoft Office\Office15\" – Sid May 07 '19 at 12:57
  • Have you checked a log of the installation? – montonero May 07 '19 at 13:03

2 Answers2

0

Correct Registry Search: Try to search the proper 32-bit section of the registry: SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths\MSACCESS.EXE

Crucial is the inclusion of Wow6432Node towards the beginning of the string.

Custom Action: It is not accepted best practice, but I like to use custom actions to inspect the system (I don't like them for making system updates). Inspection custom actions are read-only, do not require any rollback, are not dangerous to the system and you can relatively safely suppress errors.

The reason I like inspection custom actions is that you have full flexibility if system inspection requirements get more complicated. I find AppSearch gets very confusing at times. Custom actions are not easy to use with Visual Studio Installer Projects.

Bitness: I don't use App Search much, but is this an actual 32-bit machine (pretty vintage that) or a 64-bit machine with 32-bit components? In case of the latter, here is a reminder about the core bitness-dependent paths in the registry and on disk:

Registry:

  • 64-Bit: HKEY_LOCAL_MACHINE\SOFTWARE
  • 32-Bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node

Disk:

  • 64-Bit: C:\Program Files\
  • 32-Bit: C:\Program Files (x86)\
  • 64-Bit: C:\Windows\System32\ - (yes, really)
  • 32-Bit: C:\Windows\SysWOW64\ - (yes, really)

Links:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
0

So this is how i finally got this to work and tested successfully on both 32bit and 64bit Windows machines.

My application is dependent on two prerequisites. 1. Crystal Report Runtime. 2. Microsoft Access Runtime.

So created registry search for both the runtimes.

enter image description here enter image description here enter image description here

And Properties for each of the Search created.

enter image description here

enter image description here

enter image description here

enter image description here

Launch Condition for each of the runtimes.

enter image description here

enter image description here

enter image description here

If you observe between the two conditions for each of the runtime you would find the difference in the way the condition has been set.

For Microsoft Access Runtime, i have just mentioned the Property name that was set for the Registry Search. While for Crystal Report Runtime, i have specified the value which is a specific version of runtime that should be present. In my case i was specifically looking for version "13.0.4" to be present on the machine.

Sid
  • 123
  • 2
  • 10
  • I don't use App Search a lot (as I said I use custom actions for inspection - a controversial choice), but [please do have a quick read here](https://stackoverflow.com/questions/55351177/wix-compare-version-7-x-x-x-and-10-x-x-x). – Stein Åsmul May 08 '19 at 11:16