InstallShield - 64bit Registry Component Being Written When a 32bit Entry is Required
Hi, any assistance or guidance as to a better way to do this, would be greatly received.
I want to create an MSI that creates a folder in c:\users\public and then installs files there. C:\users\public is not a predefined folder so I thought I would try to achieve this with the following.
1. Create a registry entry here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\ that adds the path c:\users\public
2. Use the System Search utility within Install Shield to look up this folder and store the value in a public property (PUBLICFOL). I have ticked the option that says "search 64bit registry".
3. Create components which have the files I need installed and set the destination as this public property.
My Template Summary is set to Intel;1033 at present.
Component Config for file install :- 64-bit Component = No Disable Registry Reflection = No Destination = PUBLICFOL
Component Config for Registry :- 64-bit Component = No Disable Registry Reflection = No Destination = INSTALLDIR
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432NODE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders -
This resultant MSI installs the registry entry HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432NODE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders -not where I want it. Because of this, the files are not installed to c:\users\public as required. They are installed to a folder called PUBLICFOL at the root of c:\
If I manually create the registry entry I want then run the install, it all works as it should. This registry redirection issue is my problem.
If you have any suggestions to fix this or perhaps another way to install to the public directory (apart from creating a directory structure of folders through the directory table, I know I can do that, I wanted to try to leverage a different method), that would be great.
I have tried various different combinations of configurations over the last 2 days, but please fire me any further questions, if I haven't provided enough info. Thank you.
Answers (2)
You are specifying the 64 bit path to the shell folder registry location but the component is not 64 bit. Either use a 64 bit component, or specify the 32 bit path (ie without the syswow64 bit)
Edt
Comments:
-
Thanks for replying EdT.
I don' think I am, unless you can clarify further what my mistake is. It could be I'm being dense and not understanding you.
In point one of my original explanation, I have detailed the path. I am actually importing the registry entry into my project in installshield, using a reg export I originally took and reconfigured, from the correct 32bit registry path.
The resulting MSI is putting my 32bit reg entry into the 64 aspect of the registry, which is the very crux of the matter :(
This is what I'm importing:-
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
"LBI Common Public"="C:\\Users\\Public"
To my knowledge I'm using a 32bit template, so why is the resulting MSI writing to Wow6432Node when that is not what I'm specifying?
Am I missing some other Install shield configuration to ensure this registry entry ends up in the 32bit aspect of the registry? - Bexy 3 years ago-
You are making an assumption that Installshield is able to correctly capture what you are doing but the bottom line is that it is probably using a 64 bit capture engine and thus everything tends to reflect how things would appear in a 64 bit environment. You have two options - one is to make sure your components are 64 bit by using the 64 bit template (even for 32 bit apps), as then the registry path with syswow64 would be correct, or alternatively edit the registry path in your MSI registry table to remove the reference to syswow64, so that the registry path in the 32 bit components is a 32 bit registry path and not a 64 bit registry path. Have you tried running validation with ORCA or Installshield to see what the ICE errors report? That can often point you in the right direction. The other thing that does not get mentioned often enough is VERBOSE LOGGING. The log will show all the native MSI properties and what they contain, which as VBScab has indicated, may allow you the much simpler solution of just referencing a property value rather than the convoluted registry solution. Mixing 32 and 64 bit content in a single MSI is always going to lead to tears. - EdT 3 years ago
-
You are probably right that I'm making assumptions about install shield that are not correct. But what? is the conundrum for me.
It's rare I find myself with time to play with installshield and it's always good to have different things in your arsenal when packaging.
My registry entry doesn't have SYSWOW, it is the correct registry path (well as far as I can determine).
I tried using a 64bit template prior to posting, but the install still does not look up the path. It will only find the install path if I manually have the correct registry entry in the 32bit aspect of the registry.
It is indeed a mystery I don't think I'm going to solve quickly and unfortunately no one else seems to have seen this behaviour :( No worries, thank you for your suggestions. - Bexy 3 years ago
Why not simply use the environment variable %PUBLIC%, as in [%PUBLIC] ?
Comments:
-
Hi VBScab our paths have crossed before in a previous question I posted, it was all good. We didn't solve the problem, but I think we talked about "old IT" and realised how old we are ;)
Yes I can do this and it will probably be my approach now. It is rare I get time to "play" with installshield and its bugging me that I can't work out why I'm seeing this behaviour. Call me Sherlock Bexy :D
Lockdown is making me realise I could really handle retirement :). Unfortunately its still a little bit too distant for my liking. - Bexy 3 years ago
