Bugs item #1273447, was opened at 2005-08-25 14:42
Message generated for change (Comment added) made by micarls
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1273447&group_id=105970
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: candle
Group: v3.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jeff Lawson (bovineone)
Assigned to: pmarcu (pmarcu)
Summary: Can't put RegLocator inside DrLocator
Initial Comment:
I need to be able to represent this MSI relationship,
which seems disallowed:
Table "AppSearch"
Property="INSTALLDIR", Signature="_olddir"
Table "DrLocator"
Signature="_olddir", Parent="_oldexe1", Path="", Depth=0
Signature="_olddir", Parent="_oldexe2", Path="", Depth=0
Table "RegLocator"
Signature="_oldexe1", ....., Type="File"
Signature="_oldexe2", ....., Type="File"
Table "Signature"
Signature="_oldexe1", .....
Signature="_oldexe2", .....
The representation I would need is:
<Property Id="INSTALLDIR">
<DirectorySearch Id="_olddir" Depth="0">
<RegistrySearch Id="_oldexe1" Root="HKLM"
Key="Software\MyCompany\MyProgram" Name="Executable"
Type="file">
<FileSearch Id="_oldexe1" Name="PROGRAM1.EXE"
MinSize="200000" MaxSize="4000000" />
</RegistrySearch>
</DirectorySearch>
<DirectorySearch Id="_olddir" Depth="0">
<RegistrySearch Id="_oldexe2" Root="HKLM"
Key="Software\MyCompany\MyProgram" Name="Executable"
Type="file">
<FileSearch Id="_oldexe2" Name="PROGRAM2.EXE"
MinSize="200000" MaxSize="4000000" />
</RegistrySearch>
</DirectorySearch>
</Property>
However, this produces the error:
error CNDL0005 : The DirectorySearch element contains
an unexpected child element 'RegistrySearch'.
But I think if that were fixed, it would still probably
fail with something like:
error LGHT0112 : Duplicate symbol 'DrLocator:_olddir//'
found.
I have not had any problems with the 4 table
relationship (at the top of this report) when I was
previously using msi2xml/xml2msi and the Orca
validators have never indicated that this was an
invalid relationship.
Is what I have been doing actually illegal, or is
wix/candle erroroneously stringent?
----------------------------------------------------------------------
>Comment By: Mike Carlson (micarls)
Date: 2008-05-02 15:37
Message:
Logged In: YES
user_id=2057970
Originator: NO
Note: when this bug is fixed, we should likely ensure it fixes the rest of
the scenario in Bug #1864685.
----------------------------------------------------------------------
Comment By: Heath Stewart (heaths)
Date: 2007-05-17 20:45
Message:
Logged In: YES
user_id=1335104
Originator: NO
According to the documentation for the FileSearch table, not specifying
the optional @Id will result in the outer Property being set to the parent
DirectorySearch result. This is reflected in the authoring example below:
<Property Id="INSTALLDIR">
<RegistrySearch Id="InstallDirReg"
Key="SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine"
Name="ApplicationBase" Root="HKLM" Type="directory">
<DirectorySearch Id="InstallDirDir">
<FileSearch Name="powershell.exe"/>
</DirectorySearch>
</RegistrySearch>
</Property>
This does not result in two entries in the DrLocator, which should look
like this (and manually authoring this in the resultant MSI works as
expected):
[DrLocator]
InstallDirDir, InstallDirReg, ...
InstallDirFile, InstallDirDir, ...
[Signature]
InstallDirFile, powershell.exe, ...
So the bug here is that when @Id is not specified on the inner FileSearch,
Signature is not generated nor is the extra DrLocator to tie the file to
the directory.
----------------------------------------------------------------------
Comment By: Rob Mensching (robmen)
Date: 2006-12-15 11:47
Message:
Logged In: YES
user_id=991639
Originator: NO
Moving to WiX v3 to not destabilize v2.
----------------------------------------------------------------------
Comment By: Jeff Lawson (bovineone)
Date: 2005-08-31 10:39
Message:
Logged In: YES
user_id=511066
I've temporarily been able to work around this limitation by
hand-generating a .wxsobj object file containing a
"fragment" with the necessary raw table rows. I can then
link that into the rest of my Wix project without problems,
but I agree it would be nice for this syntax to be natively
supported.
----------------------------------------------------------------------
Comment By: Rob Mensching (robmen)
Date: 2005-08-31 00:33
Message:
Logged In: YES
user_id=991639
This is a limitation in the WiX representation of the Search
elements. The Locator tables don't map to a heirarchy well
and the WiX schema doesn't handle all cases. This is a bug
that needs to be fixed. It just isn't simple.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1273447&group_id=105970
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
WiX-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
