The property you set in System Search will contain the value in your registry key. If the key doesn't exist, the property won't exist. So, in your Launch Condition, all you have to check for is the existence of the property; it's never going to "=TRUE". So in the condition builder, just put the name of the property. ... View more

Is your custom action set to execute after InstallFiles in deferred context? ... View more

I've done this two ways: I've set up the UI in the wrapper script project, run the msi's from OnFirstUIBefore, then aborted the wrapper setup. I've also set up the wrapper setup with a dummy feature, created a script-created media set to list all the installs available, displayed all my UI, then called a function in OnFirstUIAfter that runs the other setups selected using MsiInstallProduct for msi's and LaunchAppAndWait for setup.exe's. I can then track any errors using MsiInstallProduct's return code and LAAW_PARAMETERS.nLaunchResult. In the latter project, I set the wrapper setup project's "Maintenance Experience" to "no uninstall or maintenance" and "Update Supported" to "No" so that my wrapper always runs as a new install, and in OnBegin I look for my products and set global variables so that I can present them as already installed in my UI. Basically, this project acts as an "install controller" for our suite of products so that customers can use it to install, add or remove plug-ins, upgrade, or uninstall. ... View more

Have you looked at marking some components as "permanent"? ... View more

First, I would suggest creating a log file to see if it can tell you what the problem is. What kind of project? If it's a Basic MSI, I would also suggest running validation against the project to see if that can uncover any errors. Also, if it's a Basic MSI, and you have one component with multiple executable files (exe and/or dll) in it, you have broken Windows Installer's component rules and you could be setting yourself up for some real issues for later upgrades and for repairs. Each component should contain only one executable file, and that file should be the key for the component. ... View more

If any of the files have a .msi extension, they are viewable in Orca. If they are .exe files, then they might extract some embedded stuff, part of which may be an .msi file. Usually, you can find extracted files in the Documents and Settings\ \Local Settings\Temp directory somewhere, often in a subfolder by a GUID. If you start the install and get to some kind of Welcome screen, you should then be able to look for the temp directory and save whatever files are in there for further examination. Hope this helps! ... View more

When you say you don't have the previous installs, I'm assuming you mean that you don't have the actual projects? Were they MSIs? If you have the MSI file you should be able to get the product code for each using a tool like Orca, then you can uninstall it in a custom action using the product code. You can also use the API to detect if a product has been installed with that product code (in a custom action). Or, you can use AppSearch (through System Search view) to look for specific files in the directories you know might be there to determine which are already installed. To uninstall them, though, you would still have to know either the product code, the update code, or both. If you know the upgrade code, you can simply set an Upgrade Table item in your new install to uninstall the old one. If the previous installs were built using Wise's version of InstallScript instead of MSI, then I don't know what to suggest... ... View more

The only way I've ever managed to do this successfully is by writing an InstallScript setup that runs the other setups behind the scenes. The front-end setup displays options for the "background" setups, gathers all user input, then initiates them silently with user input set as properties on the command line. ... View more

I think you're on the right track. What do you mean when you say "that would contain about 15 other merge modules"? Do you mean that your MM has dependecies set for these other MMs? I think that's the way to go. Your "master" module will contain only the "loose dll's" but any time you include it, the dependent MMs will also be pulled in. ... View more

What kind of project are you using? With a Basic MSI, you could create a custom dialog with the radio buttons, then use the corresponding property to conditionally set the contents of ADDLOCAL and REMOVE. With an InstallScript project, you can use either a custom dialog or one of the standard option dialogs, and then in your script set the feature state of the features based on the option selected. Hope this helps. ... View more

That depends. What kind of project is your installer? What kind of installer do you want to embed? It's easy to run an MSI from within a pure InstallScript installer. It's not so easy to run an MSI from within an MSI or InstallScript MSI project. ... View more

Can you post a few more details on how you created your System Search, and how you're getting the message box to pop up? The issue is probably in those details. ... View more

Just a thought here. If your install must run in a Terminal Services environment, keep in mind that your users may not have a C:\ drive. ... View more

First, what kind of project are you using, Basic MSI, InstallScript or InstallScript MSI? Second, how are you retrieving the previous installation directory, and how/when are you setting INSTALLDIR to that value? Have you logged an upgrade installation that put files in the wrong path? ... View more

If you're using an MSI project, have you tried using AppSearch to get the value from the .ini file, and then using a SetDirectory custom action to apply that value to specific entry in the Directory table? ... View more