The wixlib looks like exactly what I need--thank you for pointing me in that direction. I *almost* have it working, except I can't figure out what to use for the Directory elements in the "common" wxs file. The components in the wxs file will be installed in different locations in the stand-alone application vs. the larger application. My stand-alone wxs Directory elements look like this:
<Directory Id='TARGETDIR' Name='SourceDir'> <Directory Id='ProgramFilesFolder' Name='PFiles'> <Directory Id='Ntfmo' Name='Ntfmo'> <Directory Id='INSTALLDIR' Name='Literacy'> Right now, my common wxs Directory elements are: <Directory Id='TARGETDIR' Name='SourceDir'> <Directory Id='INSTALLDIR' Name='.'> But, of course, light.exe gives me "error LGHT0130 : The primary key 'INSTALLDIR' is duplicated in table 'Directory'. Please remove one of the entries or rename a part of the primary key to avoid the collision." What do I use here? In the standalone app, the installation path is %ProgramFiles%\Ntfmo\Literacy, but in the larger application it should be the installation path of that application. Thanks for your help! ---------------------------------------------------------------------- Message: 1 Date: Fri, 9 Oct 2009 01:28:28 -0700 From: "Blair" <os...@live.com> Subject: Re: [WiX-users] Create shortcut for file in merge module To: "'General discussion for Windows Installer XML toolset.'" <wix-users@lists.sourceforge.net> Message-ID: <bay122-ds48fd29104433ba618c98acd...@phx.gbl> Content-Type: text/plain; charset="us-ascii" If you wish to retain the advertised nature of the shortcut, you will have a harder time because the shortcut has to live in the same component as the eventual target (which means you have to have the same component with different resources based on whether the component lives in the stand-alone application or the integrated application, which is a violation of the component rules. Violating it could possibly cause the shortcut to be orphaned depending on the installation/upgrade/removal sequences between the stand-alone and integrated products. If you wish to target a file from a merge module in a shortcut, you have to assemble the target like this: "[#fileid.mergemoduleguid]". If you are autogenerating the MSM's package guid, that value might be hard to anticipate, depending on your build environment. Instead, think of the situation this way: Component GUIDS are used to identify components universally in the Windows Installer universe. Component Ids, File Ids, etc. are used to identify those elements WITHIN any arbitrary package. Thus, you don't have to use the same merge module in both installation packages, you just have to use the same merge module content you care about between both packages. And the easiest way to do that would be to use wixlibs, which are wix-toolset-specific "libraries" of compiled wix code, analogous to merge modules in the larger Windows Installer world but without several of the problems associated with merge modules. Here's how this can work in practice: You generate a wixlib (compile with candle, link with lit) the code containing the shared components and their resources. That code consists of .wxs files containing only Fragments as direct children of the root Wix elements. You reference that wixlib in your standalone application, which will include the appropriate ~Ref elements required to eventually include all your fragments in your wixlib. Your standalone app is now built and can easily create a non-advertised shortcut that targets any file (using simple "[#fileid]" syntax) in your wixlib. You generate an MSM that has a similarly small wxs file as your standalone app, except it uses the Module element instead of the Product element and doesn't include the shortcut. You reference the resulting MSM file in your integrated package. The result is that the shared components are the same (have the same GUIDS and the same contained resources) even though the IDs differ (the integrated product has those IDs with the appended ".GUID" on them). They act as you expect them to act in scenarios where the standalone app and the integrated app are both installed and removed in all combinations of ordering/version differing/etc. as if the merge module had been used in building both packages. And, when you finally move away from non-wix toolsets, you can simply drop the wrapping MSM and directly link the wixlibs (remembering to replace the Merge elements with appropriate ~Ref elements to pull in the fragments from the wixlibs), so you have your migration story. Let us know how that works for you. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users