This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Can I Handle This Feature/Component Situation Better?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 22, 2013
07:02 PM
Can I Handle This Feature/Component Situation Better?
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!
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!
(9) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 22, 2013
10:39 PM
I wonder if the cab compression takes care of that for you...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 23, 2013
07:41 PM
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 24, 2013
07:24 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 25, 2013
08:42 AM
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.
Mr. Painter, as always, has a terrific idea. I think i need to play around with the DuplicateFile, MoveFile tables.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 27, 2013
01:19 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 27, 2013
01:26 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 27, 2013
01:31 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 27, 2013
02:08 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 27, 2013
02:16 PM
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.
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)