Searching the Registry doesn't work after AI update

[AlexThunder]

Hi,

I have a lot of installer projects for our products. This is a plugin based product- a base installation and certain plugins that will install into the installation folder of the base installation. The base part is also a setup created with Advanced Installer and comes as a prerequisite with the plugin installer. The plugin installer starts, doesn't find the base part and launches the installer of the base. This is installed into a user defined folder and when the installation is finished, the plugin installer does a registry search for the installation folder via "Searches". A custom action of type set installer property is performed after "Searches" in Wizard Dialog Stage and also in Install Execution Stage which sets the APPDIR to the Value of the Search Property.
This was working just fine for years. Now after updating to version 21.0 -and i guess it didn't work for 20.9.XX- it is not working anymore. The registry key is present after the base installation, but the search isn't either performed at all or doesn't find the reg-key -if the installation of the plugin called the base installation.
If the base is already there before the plugin is installed and therefore the base installer is NOT invoked by the plugin installer, everything works great again.
Any idea???

[curt.blunt]

Hi Alex,

Have you tried enabling 'Search the 64-bit portion of the registry"


Also, can you manually add the reg key you are expecting (add it manually to your registry) then hit 'Test Search' do you get a response?

[AlexThunder]

Hi Curt,

thx for your reply. That 64bit thing was in my mind already, so I did add another search for the same reg-key but for the 64bit portion. I also added Messageboxes to my custom actions to show the content of the propertys before and after the search was performed. In all cases there were just empty if the plugin installer invoked the base installer before. It kind of felt like, the registry was not updated during the installation process. I could see that key in the registry editor but the search could not find it.
Again to make that clear: If the base part of the software was installed before and the plugin installer was started with the base already there, the same search works just fine.
I will create create a sreenshot series later and post it here.

[AlexThunder]

So here is the screenshot. This ist right after the plugin on the right called the base installer. I modified the installation path of the base installer to C:\Testinstall.

Installer start.png (30.57 KiB) Viewed 5408 times

This is the registry befor the installation of the base part:

reg.png (4.45 KiB) Viewed 5408 times

The base part installs and this is right after it's installation. You see, there is an entry in the registry:

Installer base end.png (47.6 KiB) Viewed 5408 times

Than the plugin installer gets back to work and this is the result of the Search -the path for the installation is the default value that I set, so the search was not successfull:
... see next post...

[AlexThunder]

plugin installer.png (6.87 KiB) Viewed 5408 times

Here is the search:

Search.png (11.01 KiB) Viewed 5408 times

And the custom Actions:

Custom Actions.png (42.86 KiB) Viewed 5408 times

[Catalin]

Hello Alex, Curt,

@Curt, thank you very much for your feedback here, we highly appreciate it.

However, that does not seem to be the case here as the registry search should, in fact, be 32-bit - we can see that in the WOW6432Node entry.

@Alex,

I have run some tests just now and it looks like this is working just fine on my end.

Before I explain how I tested this, I would like to clarify a few things.

First of all, let's make sure that the two setups do not have missmatched bitness. What I mean by that is that the main installation ("plugin") should also be 32-bit (considering the "base" is also 32-bit).

If the plugin is 64-bit, it will never be able to look into a 32-bit location for its search (considering the "base" is 32-bit and it redirects its registry entry under WOW6432Node).

Another thing to notice here would be that the "base" package should be installed "before the main package".

Screenshot_56.png (23.29 KiB) Viewed 5373 times

The reason for this is that otherwise, the search is executed before the installation of the prerequisite and this might lead to the search not working.

Now, here's how I tested this:

- created a new MSI called zzz.msi

- I added this as a prerequisite in a new project, scheduled to run "before the main package"

- in the "Search" page, I created the following search

Screenshot_57.png (15.19 KiB) Viewed 5373 times

- in the Custom Actions page, I have added a messagebox to make sure this works as expected

Note: you can see that my search is set to "Retrieve the raw value".

Screenshot_58.png (30.3 KiB) Viewed 5373 times

Upon installation, the prerequisite is installed and then when the main package installs, the searches are executed and then the MessageBox prints the expected path:

Screenshot_59.png (59.39 KiB) Viewed 5373 times

Hope this helps!

Best regards,
Catalin

[AlexThunder]

Hello Catalin,

thank you very much for your answer. I checked your point:
both packages are 32bit
the base is sheduled before main package
and the search is just like your -just that i had "The value contains a path to a directory" instead of "Retrieve the raw value"
But i also tried this with the same behaviour.

I did send the .aip file to the support team this morning...

[Catalin]

Hello Alex,

This is currently under our investigation.

Once we'll have more information, we'll followup over the email.

Thank you for your patience on this!

Best regards,
Catalin