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 (http://community.flexerasoftware.com/showthread.php?t=201895) 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.
 
 
 
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).

??
Answer Summary:
Cancel
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Answers

0

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.

Answered 06/26/2012 by: Superfreak3
Black Belt

Please log in to comment
0

NO can do chaining a 64 bit installer to a 32 bit installer...

http://blogs.msdn.com/b/heaths/archive/2009/07/03/installation-sequence-restrictions-for-multi-package-transactions.aspx

I'll work around with an Asynch-No Wait custom action that will monitor the msiexe processes of the calling installer (32 bit).  Once freed up, the action executable will fire the 64 bit installer that was installed as part of the 32 bit package.

Might be clunky, but it appears to get the job done.

Answered 07/01/2012 by: Superfreak3
Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity