RE: [WiX-users] rfc: registry schema

[Derek C. <de...@us...>]

inline

 

  _____  

From: Michael Osmond [mailto:MO...@ba...] 
Sent: Sunday, March 05, 2006 9:25 PM
To: de...@us...; wix...@li...
Subject: RE: [WiX-users] rfc: registry schema

 

Derek,

 

What you are proposing makes sense, and doesn't seem to difficult.  

 

Is it intended support nesting of registry keys ie

 

<RegistryKey Root"HKCU" Key="Software\SomeApplication">

    <RegistryKey Root"HKCU" Key="SomeSubkey">

        <RegistryValue .....

    </RegistryKey>

</RegistryKey>

 

Which would create "HKCU\Software\SomeApplication\SomeSubkey"

[DerekC] Yes, this is to make nested authoring more intuitive, but also
makes it more clear how to create keys versus values.

 

In regards the statement - you can simply have a RegistryValue which will
act like the current Registry.  Can you simply leave the Registry element in
the Schema and simply remove some of its current attributes (or does this
create to much confussion)?

[DerekC] We would leave the Registry element for up to a year (with a
suppressible warning that it's deprecated), while people migrate to the new
RegistryValue element.  The idea is to keep things as clean and concise as
possible - keeping around the Registry element would offer overlapping
functionality which is a bit confusing.  Also, you can use WixCop to
automatically migrate to the new schema (this is how we keep our authoring
up-to-date as the schema changes).

 

Michael

  _____  

From: wix...@li...
[mailto:wix...@li...] On Behalf Of Derek Cicerone
Sent: Sunday, 5 March 2006 7:56 PM
To: wix...@li...
Subject: [WiX-users] rfc: registry schema

Since nested <Registry> elements were introduced, we've gotten lots of bug
reports about problems with authoring default registry values.  There has
also been a bit of confusion over the authoring for registry keys versus
values and less frequently how to remove registry values via WiX.

 

1. Default values in nested Registry elements

<Registry Root="HKLM" Key="Software\SomeApplication">

            <Registry Value="SomeDefaultValue" Type="string" />

            <Registry Name="SomeName" Value="SomeValue" Type="string" />

</Registry>

The bolded <Registry> element above will cause a linker error because the
generated registry identifier will collide with the parent <Registry>
element.  This happens because every <Registry> element creates a row in the
Registry table.  This means that the parent <Registry> element which the
user likely created just for organizational reasons, will also attempt to
set the default registry value as does the bolded <Registry> element (thus
the collision).

 

2. Confusion over how to author registry keys versus values

Since the <Registry> element covers both values and keys, people sometimes
become confused with hot to interpret the various values of the
Registry/@Action attribute.  It's not always clear that the values with the
word "Key" in the name always operate on the registry keys whereas the
others operate on values.

 

3. Confusion over how to remove registry keys and values

This problem happens to a much lesser extent than the first two issues, but
there is also a problem with the current schema in which people expect there
to be a <RemoveRegistry> element to complement the <Registry> element.
Given the presence of a <RemoveFile> and <RemoveFolder> elements, this is a
reasonable assumption.  The case for having separate Remove functionality is
further bolstered since doing so would allow wix to specify which attributes
were required for adding versus removing registry elements more clearly.
For example, right now a <Registry> element which removes a registry value
could still (according to the schema) have a Type, KeyPath, and Value
attribute (all of which are not allowed for removal operations).

 

Proposed solution

Deprecate the <Registry> element in favor of some more strongly typed
elements.  These new elements should more tightly couple with their intended
functionality by only exposing the minimal settings required for each
individual operation but without requiring the user to author registry
information more verbosely.

 

Here's what the above authoring would look like for this new schema:

<RegistryKey Root"HKCU" Key="Software\SomeApplication">

            <Registry Value="SomeDefaultValue" Type="string" />

            <Registry Name="SomeName" Value="SomeValue" Type="string" />

</RegistryKey>

 

Here's the functionality provided by each new element:

*	RegistryKey 

*	@Id - optional identifier 
*	@Root - the predefined registry root ("HKLM", "HKCU", .) 
*	@Key - the path to the registry key 
*	@Action - "create" (the "+" option), "removeOnUninstall" (the "-"
option), "createAndRemoveOnUninstall" (the "*" option), "none" (the default
value of Action this means that the element is for organization reasons
only) 
*	Note the lack of @KeyPath since its not allowed, @Name since its not
applicable, @Value since its not applicable, and @Type since its not
applicable. 

*	RegistryValue 

*	@Id - optional identifier 
*	@Root - the optional predefined registry root ("HKLM", "HKCU", .) -
this may inherit from it's parent 
*	@Action - append (appends to a multi-string value), prepend
(prepends to a multi-string value), write (writes a registry value) 
*	@Key - the optional path to the registry key - this may inherit from
it's parent or append to the parent's value 
*	@KeyPath - specifies whether the value is the keypath for its parent
component 
*	@Name - optionally specifies the Name for the value, unspecified is
a default value 
*	@Value - specifies the Value for the value, unspecified is an empty
string 
*	@Type - specifies the type of value being created 
*	Note that Type can now become required because it's always
appropriate. 

*	MultiStringValue - text node which specifies a single multi-string
value, this is similar to the currently supported <RegsitryValue> element
which nests under <Registry> for this purpose 

 

Additionally, it may also be desirous to create the following new elements
in lieu of putting this functionality into the <RegistryKey> and
<RegistryValue> elements.:

*	RemoveRegistryKey 

*	@Id - optional identifier 
*	@Root - the predefined registry root ("HKLM", "HKCU", .) 
*	@Key - the path to the registry key 

*	RemoveRegistryValue 

*	@Id - optional identifier 
*	@Root - the predefined registry root ("HKLM", "HKCU", .) 
*	@Key - the path to the registry key 
*	@Name - the registry value name to remove 

Note the lack of Type, KeyPath, etc. because they are now clearly not
applicable.  Using separate elements for removal makes it much easier to see
and understand what is required.  However, there is a bit confusion left
with the separate removal elements since the Registry table offers some
removal options as evidenced by the "removeOnUninstall" and
"createAndRemoveOnUninstall" values for <RegistryKey>.  That is why this is
a bit contentious - I'm hoping for feedback on this in particular.  Perhaps
we could just have RemoveRegistryValue but the functionality of
RemoveRegistryKey is represented by RegistryKey/@Action="removeOnInstall"
(kinda like how it works now).  This would be a good compromise for clarity
although some people may then have problems discovering the
RemoveRegistryValue element in this scenario.

 

Will this new authoring require always nesting <RegistryValue> elements
under <RegistryKey> elements?

No.  You can just author <RegistryValue> elements in the same way that
<Registry> was previously authored flatly.  So beyond having a different
element name, the functionality is identical to what is currently authored.
This should allow us to completely remove the <Registry> element at some
time in the future since all its functionality and flexibility will be
offered by the new schema.

 

Is it possible to get these improvements without modifying the schema?

Partially.  We could add an Action="none" capability to Registry/@Action
attribute to help alleviate the first scenario.  However, this will not be
as clean of a solution and will not help the second and third issues.  Also,
as people migrate to WiX 3.0, this will likely be the only chance we get to
do additional refactoring on the registry schema since we'd like to leave
the wix schema alone post WiX 3.0.

 

These schema modifications are a big pain, how many more are there?

This is the final planned schema change for WiX authoring.  As always,
WixCop will automatically update authoring to the latest schema, so if you
use it, staying up-to-date should be a snap (it's how we keep all our
authoring for wixui and tests up-to-date, so we always test it pretty
thoroughly and check in new versions of WixCop along with the schema
changes).

 

I look forward to hearing feedback from the community! :-)

 

Thanks,

Derek