Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Some Chained Installer Questions...


4 replies to this topic

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 20 June 2012 - 13:53

Hi All,

I have a bit of a problem. Since our client application is only 32 bit, I've run up against a challenge of adding some third party Merge Modules that have 64 bit components marked as such. I can't add them to my 32 Bit package without changing it to x64 so I thought I would Chain a 64 bit installer to place these.

For the most part, it works as the Merge Modules are configurable so when I pass my 32 bit INSTALLDIR to the chain, the components go where they need to go, almost.

There are some Common program files that should end up in the 64 bit Program Files\Common Files\MyFolder, but they end up in Program Files (x86)\Common Files\MyFolder.

If I run the chained installer standalone it appears OK so the thought was that running the 64 bit chained install from 32 bit process makes directories a hairy issue. Registry entries seem to be OK as, when chained, they go to the 64 bit hive as hoped.

So, I was hoping there was a way to set the desired Common Files directory in the 64 bit installer to avoid placement in the (x86) area. I tried setting the directory to [%CommonProgramFiles], but it still goes to the 32 bit area.

Any ideas on how I can get this stuff where it needs to be.

UPDATE: More details to the Common Files issue. Chaining my installer works as desired on XP 64, but does not work on Win 7 64. The common files end up in Program Files (x86) on that OS.

Am I running up against a security issue of some kind. My initial install is fired off by an Admin. Does that chained install not inherit the rights of the 'parent' or main install? I'm reaching.

Edited by Superfreak3, 20 June 2012 - 19:45.


Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 21 June 2012 - 02:24

Another Update ...

I added a vbScript Custom Action to display the directories in my Win 7 scenario. During the UI phase, they are correct...

session.property("ProgramFiles64Folder") = C:\Program Files\
session.property("ProgramFilesFolder") = C:\Program Files (x86)\
session.property("CommonFiles64Folder") = C:\Program Files\Common Files\
session.property("CommonFilesFolder") = C:\Program Files (x86)\Common Files\
session.property("MyFolderShared") = C:\Program Files\Common Files\MyFolder Shared (CommonFiles64 is parent).

During the Execute sequence...

session.property("ProgramFiles64Folder") = C:\Program Files\
session.property("ProgramFilesFolder") = C:\Program Files (x86)\
session.property("CommonFiles64Folder") = C:\Program Files (x86)\Common Files\
session.property("CommonFilesFolder") = C:\Program Files (x86)\Common Files\
session.property("MyFolderShared") = C:\Program Files (x86)\Common Files\MyFolder Shared (CommonFiles64 is parent but resolving to (x86).

??


Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 26 June 2012 - 15:18

If I change the processor on my calling installer to x64, all works properly so something is lost in translation when an x64 bit chained install is called from a 32 bit install.

I just can't figure out how to set the CommonFiles64Folder so that the contents of the MyFolder sub-direcotry gets there instead of in the Program Files (x86)\Common Files folder.

Any help is MORE THAN GREATLY APPRECIATED!

I've tried Set Directory actions, passing in property values from the calling installer to set the location, etc. Nothing is working.

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 02 July 2012 - 00:00

Found out I have a problem with 64 Bit chained install...

http://blogs.msdn.co...ansactions.aspx

Went a different approach to workaround the issue...

Installing a 64 bit installer that is fired by an Asynch No Wait custom action that monitors msiexec processes and fires the 64 bit installer when calling msi processes have ended. Seems to be working so far.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 02 July 2012 - 09:31

Thanks for updating this thread. I followed it but didn't know of any solution, sorry.