That is what the "Common" Program Files directory was created for <smile/>. You use it similarly to the non-Common directory, except that components shared between simultaneously installed products live there. Then there is never any need to keep track of or even care about a COM object's installation directory.
Do you build both Product A and Product B with the same (or at least similar) builds of WiX? If so, your problem as you have designed it would probably be easier to solve using WIXLIBs instead of MSMs. Create a WixLib project (instead of a module) of Product A. Even better than the registry search would be a component search to get the component's installation directory, but a registry search can be used as well (as long as you write the registry key). Place that search in the WixLib. Create two WiX-MSI projects, one for A and the other for B. Both consume (and depend on) the WixLib for A. The linker (which is not heavily involved in the the incorporation of MSM content) will be able to arbitrate the various actions needed between the different parts the installation much more easily than the binder can, and you will also avoid the issues you are seeing with trying to force the AppSearch from an MSM. Blair -----Original Message----- From: Joost van Zoest [mailto:jzo...@siqura.com] Sent: Wednesday, February 01, 2012 5:11 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Visual C++ 2010 Merge Module Hi Blair, Thanks for your reply. Let me explain the reason why we're using the registry search inside the MSM. We have a product containing a COM object, let's call this product A. We also have a product which is using the COM object of product A, let's call this one product B. We've made both an installer and a MSM of product A. And the installer of product B embeds the MSM of product A. Then we released product B, and later decided to change the installation directory for product A. When someone installs product B, the COM object is registered in the old path. When he installs product A afterwards, the old registration is overwritten with the new location of the product A binaries. If he uninstalls product A, the registry gets corrupted because the COM registration still points to the new location, while the binaries installed by product B are located in the old location. To overcome this problem, we wanted to let both the installer and MSM of product A write a registry key containing the install directory. When either the installer, or MSM, gets installed, it will first try to retrieve the install directory from the registry to make sure it will install the binaries to the same directory when the product is already installed. As it seems, this registry search is not working very well inside the MSM. Given our problem, does someone have an idea on how to deal with this? We also thought about stopping using MSM's, but the disadvantage of embedding the product A installer inside the product B installer is that product A is not refcounted. So when product B gets uninstalled, it cannot tell whether or not it should remove product A as well. All ideas are appreciated! Thanks! -----Original Message----- From: Blair [mailto:os...@live.com] Sent: Tuesday, January 31, 2012 4:38 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Visual C++ 2010 Merge Module Several action don't seem to be intended to be found in MSMs. Maybe AppSearch is one of them. Do you distribute your MSM publically? If not, I've got a couple of ideas. 1) Run a couple of SQL queries against the MSM to remove them from the two Module*Sequence tables. 2) Change from using MSMs and instead generate/consume WixLibs instead. If you do distribute MSMs publically then each idea I have has limitations. -----Original Message----- From: Joost van Zoest [mailto:jzo...@siqura.com] Sent: Tuesday, January 31, 2012 6:41 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Visual C++ 2010 Merge Module I've validated my MSM in Orca. At first, I got a lot of ICE33 warnings because of some COM registration logic. To rule out that this was causing my problems, I removed this registration logic and validated the MSM again. Now the validation completes, but ends with: Execution ERROR There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. I'm using Orca with the darice.cub of WIX 3.6 BETA Looking further in Orca, I saw 2 tables (ModuleInstallExecuteSequence and ModuleInstallUISequence) which both contained an action called AppSearch with a Sequence of 50. I guess the actions of these tables are moved to the InstallExecuteSequence and InstallUISequence tables when you embed this merge module into an installer. So could this be the cause of the warnings I see when I build my installer? Somewhere in my merge module I perform a registry search to get a directory from the registry: <Property Id="MYDIRECTORY"> <RegistrySearch Id="REG_DirectorySearch" Type="raw" Root="HKLM" Key="Software\MyApplication" Name="InstallDir"/> </Property> *MYDIRECTORY is the ID of a Directory element. When I remove this registry search, the AppSearch actions are also removed from the 2 tables. And I don't get the warnings anymore when I build the installer containing this merge module. The original problem, that a registry key was not written when you run the installer, is also gone now. Am I using the RegistrySearch in a correct way? Or is there another way to fill the Directory element with a value from the registry? This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. ---------------------------------------------------------------------------- -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
