/build/static/layout/Breadcrumb_cap_w.png

Software Deployment Question


InstallShield - 64bit Registry Component Being Written When a 32bit Entry is Required

05/01/2020 474 views

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.







0 Comments   [ + ] Show comments

Comments



Community Chosen Answer

1

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

Answered 05/02/2020 by: EdT
Red Belt

  • 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?
    • 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.
      • 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.

All Answers

0

Why not simply use the environment variable %PUBLIC%, as in [%PUBLIC] ?

Answered 05/04/2020 by: VBScab
Red Belt

  • 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.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ