If you were using the MSM simply because it is a container of files themselves, you can get the same effect by "binding" the files to the WixLib by supplying the -bf flag to lit.exe. In MSBuild/VisualStudio, you can do this by setting either of the following properties to true in the WixProj file: LibBindFiles or BindFiles.
Blair -----Original Message----- From: Joost van Zoest [mailto:jzo...@siqura.com] Sent: Thursday, February 02, 2012 12:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Visual C++ 2010 Merge Module Hi Blair, Thank you very much for this new insight. The use of WixLib sounds good; the actual wxs files of product A are already in a WixLib, so that they can be shared between the installer and MSM. The only thing is that the repository of product B then has to have access to the repository of product A, which we don't want. I really like the idea of using the Common Files directory though. We will give this a try in our next sprint. So again, thanks for your time! Regards, Jari -----Original Message----- From: Blair [mailto:os...@live.com] Sent: Wednesday, February 01, 2012 6:11 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Visual C++ 2010 Merge Module 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 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
