Can I Handle This Feature/Component Situation Better?

[Superfreak3]

Hi all,

I'm back with another situation!

I have some components that I need to install into another app's file system. That's easily enough achieved with a registry search and Set Directory Custom Action. Here is the issue, however. These files will support two different applications, Third Party App 1 and Third Party App 2.

What I'm currently doing is using two features that are conditioned by the population of the registry search property. If a Third Party App 1 install directory is found that feature gets installed. Same for Thirdy Party App 2. The files are the same for both.

I was wondering if there was a better way to handle this to cut the overhead in the install in half with regard to these files instead of having two sets of the same files packaged.

My first thought was to simply install the single set of files in our file system. Then, install a dummy file into the Third Party App directories if found. Then, I could use the DuplicateFile table tied to the dummy component. Using this method has the potential for a footprint of 3 sets of files as opposed to the possibility of having two sets from the current setup. However, the actual overhead in the install is cut in half.

I guess it comes down to the question of how can I install a single set of files to two areas from the same installation?

Let me know if anything is murkey or if you have any suggestions or agree with my current approach!

Thanks much in advance!

[Kelter]

I wonder if the cab compression takes care of that for you...

[Superfreak3]

Kelter wrote:
I wonder if the cab compression takes care of that for you...

??. What does compression have to do with how Features/Components are configured and delivered?

[Christopher_Pai]

The duplicate file method is the way I usually go. An example is installing Project Template addins for multiple versions of visual studio. I'll install the templates to [INSTALLDIR]Templates ( Say [ProgramFilesFolder]MyCompany\MyProduct\Templates and then use system searches to find the directories for VS2005, VS2008, VS2010 and VS2012. If the properties get a value, the files get copied. Otherwise nothing happens.

Sure, I install a set of files to [INSTALLDIR]Templates that I don't really need but that doesn't bother me much.

Windows Installer XML (WiX) has a feature called Smart Cabbing where the compiler/linker compares the hashes of files and automatically eliminates redundancy when building the CAB. I don't think InstallShield ever did this though.

[Kelter]

I guess i was only addressing the "installation overhead" which i took to mean the size of the package. as i don't typically need to modify components once they are created, i don't see much of a maintenance hazard in having the duplicate components, and assumed that a compression algorithm would not store two identical files twice.

Mr. Painter, as always, has a terrific idea. I think i need to play around with the DuplicateFile, MoveFile tables.

[Superfreak3]

Christopher Painter wrote:
The duplicate file method is the way I usually go. An example is installing Project Template addins for multiple versions of visual studio. I'll install the templates to [INSTALLDIR]Templates ( Say [ProgramFilesFolder]MyCompany\MyProduct\Templates and then use system searches to find the directories for VS2005, VS2008, VS2010 and VS2012. If the properties get a value, the files get copied. Otherwise nothing happens.

Sure, I install a set of files to [INSTALLDIR]Templates that I don't really need but that doesn't bother me much.

Windows Installer XML (WiX) has a feature called Smart Cabbing where the compiler/linker compares the hashes of files and automatically eliminates redundancy when building the CAB. I don't think InstallShield ever did this though.

My only issue is trying to push x86 files system files to x64 from an x86 or 32 bit installer. I believe I ran into this problem before with an integration I had to add so I created another 64 bit installer to be called from the initial install on 64 bit systems.

For instance, I'll be installing my files to c:\Program Files\My App\Integrations\IntegrationApp. I'll have to add registry searches to look in the 64 bit hive of the registry from a 32 bit installer and I don't know how that would work if at all. So, the third party install will be in c:\program files\third pary\application (not program files (x86)) so I don't know if this will work.

I could still reduce the overhead and maintain the separate 64 Bit installer until I can figure that part of it out.

[Christopher_Pai]

Windows Installer looks at the bitness of your MSI and if it's x86 redirects any reference to C:\PRogram Files\ to C:\Program Files (x86)\ under the assumption that you made a mistake.

There is a way of subverting it. Use a custom action to get the shortname for the C:\Program Files\ and set a directory to it. Now when you try to install to C:\PRogra~1\ Windows Installer doesn't redirect your attempt.

[Superfreak3]

Christopher Painter wrote:
Windows Installer looks at the bitness of your MSI and if it's x86 redirects any reference to C:\PRogram Files\ to C:\Program Files (x86)\ under the assumption that you made a mistake.

There is a way of subverting it. Use a custom action to get the shortname for the C:\Program Files\ and set a directory to it. Now when you try to install to C:\PRogra~1\ Windows Installer doesn't redirect your attempt.

That's a nifty trick. My 32 bit installer files will go to Program Files (x86) on a 64 bit system. I would then just need DuplicateFile entries to copy to a 64 bit file system directory under Program Files which would be derived from a registry search and set directory custom action. During the set directory custom action will it be set to the static text pulled from the registry or will it be converted to (x86)?

All this is assuming the registry search of the 64 bit hive works from the 32 bit installer.

[Christopher_Pai]

WiX used to have 1 MSI for x86 and 1 MSI for x64. It turns out the only reason for the x64 installer was to install 1 file to the 64bit MSBuild directory. I told Bob Arnson my trick and magically the second MSI went away. I never did get credit for it of course....

x86 MSI RegLocator can read x64 hive. You just have to set the bit. There's no way to write to the x64 registry though unless you use a custom action.

All of these hacks are to create "hybrid" MSI's and aren't really supported by Microsoft. I don't know Flexera's position. They are good for some scenarios otherwise you have to spin 2 MSI's and link them together using something like a Suite installer to hide it from the user.

[Superfreak3]

Christopher Painter wrote:
WiX used to have 1 MSI for x86 and 1 MSI for x64. It turns out the only reason for the x64 installer was to install 1 file to the 64bit MSBuild directory. I told Bob Arnson my trick and magically the second MSI went away. I never did get credit for it of course....

x86 MSI RegLocator can read x64 hive. You just have to set the bit. There's no way to write to the x64 registry though unless you use a custom action.

All of these hacks are to create "hybrid" MSI's and aren't really supported by Microsoft. I don't know Flexera's position. They are good for some scenarios otherwise you have to spin 2 MSI's and link them together using something like a Suite installer to hide it from the user.

Cool. If the 64 bit reg reads work and the Set Directory CAs don't do anything funky with the values, I might be good.

That's what I do is a series of hacks to create hybrid's if components are actually marked as 64 bit. For this scenario, I won't have to write anything to the 64 bit hive, just read.

What I do for my combo installs is to launch a custom action that monitors msiexec. When the 32 bit process ends, I fire up the 64 bit installer that was actually installed on that OS.