Bugs item #1340430, was opened at 2005-10-28 01:42
Message generated for change (Comment added) made by derekc
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1340430&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: v2.0
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Riko Eksteen (rikoe)
>Assigned to: Derek (derekc)
Summary: KeyPath not resolved correctly for nested registry entries
Initial Comment:
When I use the following registry definition:
<Registry Root="HKCU" Key="Software\MyComp\MyApp">
<Registry Name="Test1" Type="string" Value="1"
KeyPath="yes" />
<Registry Name="Test2" Type="string" Value="2" />
</Registry>
the compiler generates three Registry table rows - one
for the key itself, and two for the two values. What's
more, it sets the entry for the registry key entry to
the the KeyPath of the component, instead of the one
for Test1.
When I use the following settings
<Registry Root="HKCU" Key="Software\MyComp\MyApp"
Name="Test1" Type="string" Value="1"
KeyPath="yes" />
<Registry Root="HKCU" Key="Software\MyComp\MyApp"
Name="Test2" Type="string" Value="2" />
the compiler generates only two Registry table rows,
one each for the two name-value pairs (and not another
one for the key itself). Also it correctly sets the row
for Test1 as the component's key path.
To me the above two defintions are logically the same,
and should generate the same MSI table rows, but they
don't. Plus the first definition incorrectly sets the
parent key as the key path, and not the value.
----------------------------------------------------------------------
>Comment By: Derek (derekc)
Date: 2005-10-29 16:04
Message:
Logged In: YES
user_id=518766
The automatic KeyPath assignment logic is merely a means of
ensuring that a file/registry/ODBC child is set as the
keypath if present. It doesn't discriminate between
registry keys or values. To properly set the keypath of a
component you should always specify KeyPath="yes" on the
correct child element. If you turn on the legendary
pedantic level it will enforce requiring explicit keypaths
under all components. This is the suggested method of
authoring because it doesn't rely upon the ordering of child
elements under the Component element to determine the
keypath (which is dangerous because making edits to the
component later on by adding a new item before the old child
elements may unexpectedly change the keypath of the component).
Furthermore - the current registry nesting behavior is known
to be problematic and will be fixed for WiX 3.0 (because it
will require schema changes). For WiX 2.0 (which is what
you're using) - I highly suggest not using the nested
registry elements because it produces unexpected registry
rows (every single registry element creates a registry row -
this is not what people intuitively expect). We cannot
change the beahvior in WiX 2.0 because individuals are
relying upon the current behavior. This is another reason
why this will only be cleaned up in WiX 3.0.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1340430&group_id=105970
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
WiX-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
