Property Based Folder Installing Into Weird Locations

[rock]

I have an installer that is using a registry search based property folder. The weird thing about it is if the registry search doesn't find a value it will install the files into a folder on one of the hard drives on the machine. For instance, one of my searches is named SQL_2005_DIR. It looks for a specific folder where SQL Server 2005 is installed based on a microsoft key value. If that key isn't found, the folder and the contents from the installer will be installed onto the root drive (or any other drive AI chooses) of the machine with the name of the search. So the above would create C:\SQL_2005_DIR if the registry key value isn't found.

On my machine, I have two drives C & E. When the installer runs on my machine, I get the folders and files installed onto my E drive (e.g. E:\SQL_2005_DIR). I chose the correct installer path of C:\program files...\ and E has nothing installed onto it. It's just an extra drive.

I cannot for the life of me figure how to stop this from occurring. I tried moving the search based folders into the application directory but the UI will not allow me to create search based properties there.

I'm sending the package to support with the hopes that you can help me figure this out.

Thanks!

[Dan]

Hello Chris,

You get other hard disk drive when the installation path for the property based folder is not a valid one. (in your case the registry key value isn't found). This is done automatically by Advanced Installer in order to avoid an installation error. e.g. "Could not access network location...".

Now, all you have to do is to make sure that you will set the installation path for the property based folders to the desired value(e.g. C:\SQL_2005_DIR ) when the registry key value isn't found. In order to achieve that you can go in the Custom Actions page and add our predefined Set installer property predefined custom action with sequence.

You can have the custom action's properties like that:

• Property field SQL_2005_DIR
  Value field C:\SQL_2005_DIR

Also you should condition the execution of this custom action only if the SQL_2005_DIR property is empty (the registry key value isn't found). Just add the NOT SQL_2005_DIR argument in the Condition field of the custom action. You can condition the execution of this custom action only on the Install process.

So, you will have to add a Set installer property for each property based which depends on a search result.

If you have other questions, please let us know.

Best regards,
Dan

[epu]

I have a similar issue with registry search for folder returning <bootvolume>PROPERTYNAME with advinst 10.6. This didn't happen when using an x64 MSI, but we transitioned to x86/x64 mixed mode, and instead of null/empty, the registry search always returns this bad value instead.

The described work-around doesn't function, because the PROPERTYNAME is already full of the bad string instead of null/empty.

Strangely, the customize feature dialog correctly shows that features that enable/disable based on the registry search are displayed in the correct enabled/disabled state. But the components for those features get installed anyways.

[epu]

For us, using advinst10.6 mixed x86/x64 mode, a file search using a registry location as the folder base might be reliable at returning the folder I needed (based on a file's existence in that folder). I'm not convinced yet that it will return a null/empty string.