I've heard that argument before ( configuration data is a pain ) and I
disagree. When you take that approach it is still a real pain to deploy an
application with large systems like SMS. You end up with an MSI that can
`install` an application, but to actually get it configured and usable is
different from one application to another since the functionality is
externalized and unique for each app.
Take MSDE for example.... you can pass a bunch of public properties to it and
deploy it silently and actually get it working. Now try doing the same thing
with MySQL. You can install it silently, but to actually create and configure
and instance requires running a GUI wizard that doesn't have a silent mode.
When dealing with dynamic configuration data, I always implement a pattern
that preserves attribute data and sets an order of priority like:
( Greatest Priority to least priority )
1) Information entered during UI sequence ( if run in Full UI mode )
2) Information passed as a public property ( so that an app can be configured
or reconfigured.
3) The current state of configuration ( for use during repair or upgrades
where the configuration is not respecified )
4) A default value ( for UI defaulting and silent initial installation where
a value was not specified.
When properly implemented, the user experience ( interactive and silent ) is
very robust and not difficult or unreliable.
Rob Mensching <[EMAIL PROTECTED]> wrote:
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}
Yes, what you have is a very non-optimal application design for
declarative installation. There was a thread a few days ago about static
configuration vs. dynamic configuration. Static configuration (including
application defaults) should be in the installation package. Dynamic
configuration (such as user settings that are modified away from the defaults)
should not be in the install (to prevent repair, upgrade, patch from
overwriting the user data).
Your last question boils down to How do I change the static information such
that (some part of) the dynamic information is forced to a new value? The
only place that can truly solve that problem is application code. For example,
if youre writing settings to the per-user locations and you have multiple
users, the application is going to have to migrate the user settings
appropriately for each user. If you put the migration code in the install,
then the migration would only happen for the user that did the install.
Ultimately, the world gets much easier to deal with if you separate static
and dynamic state.
From: Rennie Petersen [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 10, 2007 1:33 PM
To: Christopher Painter; Rob Mensching; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Avoiding registry entries being modified with
REINSTALL=ALL REINSTALLMODE=vos
Rob and Christopher, thanks.
Rob, you say "played games like this". You seem to be implying I'm doing
something in a non-standard or non-optimal way? If so, please let me know what
a more standard way would be to do this.
The reason I do not want to change the registry entries is that these
registry entries are used by the application to store changes in the
configuration. For example, one registry entry is used to indicate the language
to be used by the running application. It is initialized to Danish or English
at install time, depending on Windows locale info or a value entered via the
UI. But later, the user may change his/her mind and specify a different
language. An install of a minor upgrade should preserve the new value rather
than re-initialize it, otherwise the users will get upset since they have to
re-change the language once again.
Maybe this is poor application design? The application should accept
installation values in one set of registry entries and save running values
elsewhere?
But if I do it that way, how should one tell the application that you really
do want it to change the values to new installation values when that is
advantageous, for example a re-install to force a change to Swedish when that
language support is added and most of the users at this site are Swedish?
Rennie
---------------------------------
From: Christopher Painter [mailto:[EMAIL PROTECTED]
Sent: 10. juni 2007 20:07
To: Rob Mensching; Rennie Petersen; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Avoiding registry entries being modified with
REINSTALL=ALL REINSTALLMODE=vos
The description of this is a Small Update. Typically when I hear of
someone not wanting to write to the registry during an upgrade it is because
they are having negative side effects from the fact that properties don't
persist in the cached MSI and they are trying to work around the symptom
instead of addresing the cause.
Rennie, am I guessing your situation correctly? Are you using [FOO] in
the Registry table and seeing some default or null value get written to the
registry during an upgrade instead of the value that was written during the
initial installation?
If so, generally you want to use an AppSearch to retrieve the value of FOO
from the registry so that if the component reinstalls, it'll be written back
out correctly to the registry.
Rob Mensching <[EMAIL PROTECTED]> wrote:
I havent played games like this with the Windows Installer but my
understanding is that if the Component believes it needs to be repaired (the
KeyPath is being updated) then the whole Component gets written.
You might (although I wouldnt really recommend it) be able to condition
the registry related actions.
Why do you need to not have registry stuff written?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rennie
Petersen
Sent: Friday, June 08, 2007 3:37 AM
To: Rennie Petersen; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Avoiding registry entries being modified with
REINSTALL=ALL REINSTALLMODE=vos
No answers. :-(
Of course, this is not WiX specific, but I'm wondering if someone could
help me anyway.
To elaborate, the situation is that in my MSI I have not written any
<Upgrade element, nor any <RemoveExistingProducts element.
The <Product element contains the same Version= tag (Version="4.1.1.0") and
the same UpgradeCode=guid tag as used when the prior install was done.
On the msiexec.exe command line I specify REINSTALL=ALL and
REINSTALLMODE=vos. I'm not specifying REINSTALLMODE=vomus because I do not want
the registry entries to be modified.
But the registry entries are being modified anyway.
Any idea of how I can prevent this?
Thanks.
Rennie
---------------------------------
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rennie
Petersen
Sent: 6. juni 2007 19:18
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Avoiding registry entries being modified withREINSTALL=ALL
REINSTALLMODE=vos
I'm doing a reinstall, but I don't want the existing registry entries to be
modified.
So instead of specifying REINSTALLMODE=vomus I specify REINSTALLMODE=vos.
But the registry entries still get reset to the values in my MSI.
Is it possible to avoid this?
Thanks.
Rennie
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
---------------------------------
You snooze, you lose. Get messages ASAP with AutoCheck
in the all-new Yahoo! Mail Beta.
---------------------------------
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
