Custom Action Registry Condition not working

[FunkyDexter]

A bit of background:-

Our application has a dependency on the 32 bit Access Database Engine.  I know there's an option to create a prq file from the access msi but we're only using the express edition of install shield so that's not an option.  (Would love the premier edition but management aren't interested I'm afraid).  Instead I've simply included the access msi in a sub folder and created a custom action to run it at the end of the install.  That basically works OK but, if the access engine is already present, the access installer offers to do a repair or uninstall which isn't ideal.

The problem:-

I've tried putting a condition on that custom action to check for the access engine in the registry and only run the custom action if the key's not found.  However, the action is actually running regardless of whether the key's there or not so I guess I've configured the condition incorrectly and the key is simply not being found.

The full path of the key is:-

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ODBC\ODBCINST.INI\Microsoft Access Driver (*.mdb, *.accdb)

I've set up my condition as follows:-

Registry Root: HKEY_LOCAL_MACHINE

Registry Key: SOFTWARE\WOW6432Node\ODBC\ODBCINST.INI\Microsoft Access Driver (*.mdb, *.accdb)

Registry Value: I've left this empty

Search the 64 bit portion of the registry: Unchecked (I've also tested it with checked)

Any idea what I'm doing wrong?

As a bit of a test I designed a check based on the existence of a file and that worked fine so I'm pretty sure this is something specific to registry based conditions.

[MarkusLatz]

And your msi package is it 32-Bit or a 64-Bit package ?

regards

Markus

[FunkyDexter]

Hi, thanks for the response.

I  believe it's a 32 bit but I don't see that setting in Install Shield.  Under Summary Information Stream I have: Title, Subject, Author, Keywords, Summary Information Stream Content, Schema and Require Administrative Privileges.  Is there somewhere else I could check that setting?

[MarkusLatz]

How to define your msi package as 32-Bit or 64-Bit see here:

InstallShield 2019 Express Edition Help Library - Challenges of Supporting Both 32-Bit and 64-Bit Target Operating Systems (revenera.com)

And default is 32-Bit, if you have not changed. In that case you have to search for

SOFTWARE\ODBC\ODBCINST.INI\Microsoft Access Driver (*.mdb, *.accdb)

without the "WOW6432Node" part. Try it and let me know.

regards

Markus

[FunkyDexter]

Thank you very much. I should get a chance to try it this afternoon.

[FunkyDexter]

That hasn't worked I'm afraid.  It still runs the access installer every time.  I made the following observations that might help:-

1. When I run the access installer directly (not through my own msi) the contents of the SOFTWARE\ODBC\ODBCINST.INI path are unaffected.  The Microsoft Access Driver (*.mdb, *.accdb) key is present whether I have the access engine installed or not.

2. When I run the access installer directly (not through my own msi) the contents of the SOFTWARE\WOW6432Node\ODBC\ODBCINST.INI are affected.  The Microsoft Access Driver (*.mdb, *.accdb) key is present when the access engine is installed and absent when it is not.

3. I've double checked and believe I am building a 32 bit installer, this is based on the fact that nothing is written to the CommonFiles64Folder, ProgramFiles64Folder, or System64Folder and nothing is written to the Software (64 bit) section of the registry (the section does appear in the Destination Computers Registry view but nothing is written to it).

4. I'm confident I'm using the 32 bit Access installer. Downloaded from here.  I'm using AccessDatabaseEngine.exe, not AccessDatabaseEngine_X64.exe.

So from 1 and 2 I would have thought that the WOW6432Bit node was the right place to look as that's what's being affected by installing and uninstalling the access engine.  However, I would have expected the expected the key to be removed from the non-WOW  node when I uninstalled the access engine since it's a 32 bit version I'm using.  I'm aware that the WOW6432 is basically a redirect  but I'm outside my comfort zone with the registry and I am probably miss-understanding this.

Further, it appears that the installer fails to find the key regardless of which path I check. When access is installed, it's still behaving as if the key is not found regardless of which path I check, even though the key is present on both paths.

Does any of that give any more clues as to what's going on?

[FunkyDexter]

A possible wrinkle that might be affecting the above behaviour: I do have Office 365 64 bit installed, including access.  So I guess some of the registry entries I'm seeing may be coming from that.  I guess this is worth mentioning however it doesn't get round the fact that my app needs the 32 bit engine installed and doesn't explain why the registry keys aren't being found even though they're clearly present.

[MarkusLatz]

I think I have to explain some basics:

In a 32-bit msi installation package you have only access to the 32-bit part of the registry, normally there is no WOW6432Node part.

During the development process of a 32-bit msi on a 64-bit operating system, best is to use the 32-bit version of the regedit.exe (%systemroot%\syswow64\regedit.exe). Then you have the same "view" as your msi package.

Additionally check my picture, hope that brings some light into the darkness 😉

regards

Markus

[FunkyDexter]

Thank you.  I thought I might be miss-understanding the registry and that was really useful information.  Observing it through the 32 but regedit I can see exactly what you're talking about.  That lets me confirm that the key I should be looking for was as you described.

However, my condition is still not working.  I'm now looking for key SOFTWARE\ODBC\ODBCINST.INI\Microsoft Access Driver (*.mdb, *.accdb) under HKEY_LOCAL_MACHINE.  I've set the condition to Not Found (because I want the installer to run if Access is not installed).  However, the installer runs regardless of whether the access is already present or not.  On the off chance I also tried it with the full path (Computer\HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Microsoft Access Driver (*.mdb, *.accdb)) but that made no difference.

A couple of screenies. My registry:-

My condition:-

Can you see what I'm doing wrong?

[MarkusLatz]

Let me try ...

regards
Markus

[MarkusLatz]

Okay I tried and I think the problem is, that in your "System search for Registry" the field "Registry Value: (Optional)" is empty. What is valid.

But this does work only if the "Default value" is not empty. But in your case it is empty.

From the windows installer help:

Note that it is not possible to use the RegLocator table to check only for the presence of the key. However, you can search for the default value of a key and retrieve its value if it is not empty.

Can you try to check for another key/value ?

regards

Markus

[FunkyDexter]

Interesting idea.  I thought I'd give it a quick test and set the default value to "test" in the registry.  I then updated the condition so that it both left the value empty and explicitly looked for a value of "test".  Neither of these has solved it which implies there's still something missing.  As before, though, I'm likely to be miss-understanding something.

Meantime I'm seeing if I can find a different key/value to look for.

[FunkyDexter]

actually, scratch that.  I think I bungled the test.  I'm retesting.

[MarkusLatz]

You can also check the uninstall section for the presence of the access runtim msi package:

regards

Markus

[MarkusLatz]

I created a sample project which did exact this test. With empty "default value" it does not work, if I set a value to the default key, it works:

regards

Markus

[FunkyDexter]

Yeah, I bungled the test.  I'd accidentally copied the key path from excel into my condition🙄

So here's what I did which seems to be working:-

I put "test" as the data of default value in the registry and fixed my condition to actually look for the right key and it worked.  Obviously that won't work in the real world, though, as the default value won't normally have a value.

So, I simply picked an arbitrary value from that key that had data and put that value into the value of the condition.  My condition now looks like this:-

...and this works 🙂

Markus, I cannot thank you enough.  I was out of my depth on this one and you've handheld me through it.  If ever we meet I owe you a beer.

[MarkusLatz]

you're welcome and that's exactly what communities are for 😀

have a nice day.

Markus