Re: [WiX-users] Create shortcut for file in merge module

[Blair <os...@li...>]

In your wixlib, use only DirectoryRef elements as needed. Under your Product
and Module elements for each of the two packages supply the appropriate
directory tree.

-----Original Message-----
From: Dave Mateer [mailto:dav...@nt...] 
Sent: Tuesday, October 13, 2009 7:30 AM
To: wix...@li...
Subject: Re: [WiX-users] Create shortcut for file in merge module

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...@li...>
Subject: Re: [WiX-users] Create shortcut for file in merge module
To: "'General discussion for Windows Installer XML toolset.'"
	<wix...@li...>
Message-ID: <BAY...@ph...l>
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...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users