Chained MSI Questions...

[Superfreak3]

Hi all,

I have a situation where I think I may need to chain some installers.

We now have the need for some third party controls and they are 32/64 bit specific. They have Merge Modules, but the components contained within the x64 modules are marked as 64 bit.

Our application installer is 32 bit so when I try to build including the x64 modules tied to a feature conditioned with VersionNT64, I get the adjust Intel messages as there are now 64 bit components added.

I thought of editing the Modules by removing the 64 bit component attribute, but who knows what that will do.

What I was thinking of doing was creating two chained installers outfitted with their Merge Modules being architecture specific.

The questions, can I install chained installers conditionally based on architecture? If so, can I run a x64 chained install (Intel64) from a 32 bit installer?

Also, I'm wondering how I can detect installation of these chains and only run when an update is needed (in a hurry at the moment so I haven't given any thought to this part of it yet).

Any tips appreciated.

[MichaelU]

You can condition packages by various OS properties in a Suite project, or you can use any MSI condition in the chained package support. However in the latter case, I believe there were problems when chaining to a 64-bit package from a 32-bit package, particularly with getting the correct 64-bit folders. Hence I would suggest a Suite project over the chained .msi packages approach.

[Superfreak3]

Unfortunately a Suite won't work for us in this instance. We can't have the .msi encapsulated in any way as it gets modified with user configuration.

It looks like the 64 bit chained package is run under the 32 bit calling Windows Installer process. The 64 bit target folder Program Files\Common Files is only hit properly if I run it outside of the chain or standalone.

If I chain the same installer, Program Files (x86)\Common Files is used.

So, it looks as if you are correct... 64 from a 32 Bit install looks funky. I'm going to try to create a 64 bit widget called from the chained installer to copy some stuff where I need it to be. It's getting clunky, but I may be stuck with it.

Not a big fan of increasing the footprint like this, but moving the files probably isn't an option as a repair would be caused (3rd party Merge Module component keys).

[Superfreak3]

Is there any way to send text to the progress dialog when the chained installer is running? I do have a Reduced UI set for the chained installer, but it appears behind the dialog of the calling or parent .msi. The progress bar appears frozen with no text indication of what is going on.

What I would really like to do is display text on the progress bar and have no UI for the chained installer.

Also, I have some files from a Merge Module that are to reside in the Program Files\Common Files\MyDir folder. However, they are ending up in Program Files (x86)\Common Files\MyDir. I'm trying to redirect this currently via a Set Directory custom action. I tried setting CommonFiles64Folder to [%CommonProgramFiles] environment variable. CommonFiles64Folder is listed as the parent of MyDir in this scenario. This didn't work.

So, I figured that maybe this property isn't used/set since it was launched from a 32 Bit Windows Installer process. I changed to using CommonFilesFolder in the Set Directory action and changed the parent directory accordingly. This didn't work either.

I was hoping the parent directory would be set to the value of C:\Program Files\Common Files on 64 bit, but it just is not occurring. Is there any way to accomplish this? Would it work if I hard code something in a property and use that in the Set Directory action instead of the environment variable?

I'm kind of up against the gun so any help appreciated!

[Superfreak3]

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.

[Superfreak3]

Another Update :eek: ...

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]

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]

Can't chain 64 form a 32 bit installer effectively...

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