Re: [WiX-users] Conditional registry entries and handling them properly on uninstall

2009-11-26 Thread Blair
The advantages of a "data-driven" design instead of a procedural design boil
down to two:

1- Resiliency: you can effect installations and removals without requiring a
"working state" of some obscure part of the ecosystem which usually includes
the program you are installing/removing. This means you can safely remove a
program even if its files have been damaged/virus infected. This also gives
you the ability to support repair. Self-registration breaks resiliency. One
of the large Microsoft properties banned self-registration a few years ago
and had a drop in failure rates by a large factor (much more success in
installations).

2- Transparency: the database is "open" and anyone can understand what
changes it will effect in your system before applying it. This is a big win
with administrators who can screen different programs for conflicts before
approving them in their organizations. Of course custom actions can reduce
this transparency, but procedural installers tend to be even blacker boxes
and could literally do anything to a box without anyone being none the
wiser.

Your application does not appear to be the prototypical "self-contained"
application since it inserts itself between the Windows shell (explorer) and
third party applications. That doesn't mean that you can't properly use MSIs
to distribute and service your application, it just means that the majority
of the examples out there won't directly address your needs.

I noticed that you intend to service extension .xyz. I assume .xyz is only
one of several extensions your application supports/extends and is used
simply as your example for obtaining the pattern you need to implement your
installation. My question earlier is: does the installing user select which
extensions are extended? Are the extensions you extend picked from a fixed
set, or an open-ended one? How do you intend to deal with the following
scenario:

Program A installs support for .xyz files.
Your program is installed, extending support for .xyz files.
Program B is installed, replacing Program A.
Your program is removed. How do you intend to clean up?

With answers to those above questions, we can help you identify the patterns
that will work for you.

If you wish to not have a discussion in the public with this level of detail
of your application's design, reply privately and we can arrange whatever
level of NDA you need.

Blair

-Original Message-
From: Jan Wester [mailto:happyhon...@gmail.com] 
Sent: Thursday, November 26, 2009 1:28 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Conditional registry entries and handling them
properly on uninstall

Hello Blair,

Leaving registry keys behind isn't the biggest issue, and I could deal
with leaving some things behind if they didn't replace existing
values. But as I wrote in an earlier post, my application deals in the
improvement of the experience dealing with files outside the
applications installed by the user, either because they do not provide
such support or haven't done a thorough enough job. Suppose I allow my
overwritten Infotip entry to remain, that breaks any Infotips the
native application has used.

I guess my problems are only reinforced by the fact that I haven't
fully grasped understanding of and the advantages of WiX mechanism
over a more procedural approach where I could do it in a simple
if-statement. I have already got rough sketches working in a simple
DLL register/unregister function, but that is a strong no-no for
deployment according to all places I have read up on the matter.
(Although the reason escapes me - run the unregister before deleting
the file, and you get the same net effect..)

-Jan

On Wed, Nov 25, 2009 at 6:19 AM, Blair  wrote:
> If you want to restore a previously existing registry key, you would have
> had to have saved it someplace, or at least saved the fact that it
> previously existed with enough information to recreate it. That means that
> in your RegistrySearches you would need to be able to distinguish the
> difference between a non-existent key (that you are defaulting, perhaps?)
> and a previously existing key.
>
> Or, can you change the situation a bit? Is it bad to leave the registry
key
> behind when you uninstall? Sometimes old droppings really aren't as bad as
> the destruction that can be caused by trying to do a comprehensive job
> cleaning up after yourself.
>
> -Original Message-
> From: Jan Wester [mailto:happyhon...@gmail.com]
> Sent: Saturday, November 21, 2009 11:37 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Conditional registry entries and handling them
properly
> on uninstall
>
> Hello WiX community,
>
> After the advice given to me yesterday, I've been focusing on the
> subject I've had least replies on. Basically, I am tryi

Re: [WiX-users] Conditional registry entries and handling them properly on uninstall

2009-11-26 Thread Jan Wester
Hello Blair,

Leaving registry keys behind isn't the biggest issue, and I could deal
with leaving some things behind if they didn't replace existing
values. But as I wrote in an earlier post, my application deals in the
improvement of the experience dealing with files outside the
applications installed by the user, either because they do not provide
such support or haven't done a thorough enough job. Suppose I allow my
overwritten Infotip entry to remain, that breaks any Infotips the
native application has used.

I guess my problems are only reinforced by the fact that I haven't
fully grasped understanding of and the advantages of WiX mechanism
over a more procedural approach where I could do it in a simple
if-statement. I have already got rough sketches working in a simple
DLL register/unregister function, but that is a strong no-no for
deployment according to all places I have read up on the matter.
(Although the reason escapes me - run the unregister before deleting
the file, and you get the same net effect..)

-Jan

On Wed, Nov 25, 2009 at 6:19 AM, Blair  wrote:
> If you want to restore a previously existing registry key, you would have
> had to have saved it someplace, or at least saved the fact that it
> previously existed with enough information to recreate it. That means that
> in your RegistrySearches you would need to be able to distinguish the
> difference between a non-existent key (that you are defaulting, perhaps?)
> and a previously existing key.
>
> Or, can you change the situation a bit? Is it bad to leave the registry key
> behind when you uninstall? Sometimes old droppings really aren't as bad as
> the destruction that can be caused by trying to do a comprehensive job
> cleaning up after yourself.
>
> -Original Message-
> From: Jan Wester [mailto:happyhon...@gmail.com]
> Sent: Saturday, November 21, 2009 11:37 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Conditional registry entries and handling them properly
> on uninstall
>
> Hello WiX community,
>
> After the advice given to me yesterday, I've been focusing on the
> subject I've had least replies on. Basically, I am trying to only
> write a registry entry if it does not exist and create some keys to go
> with it, or if it does exist, I want to modify things, and at
> uninstall time, restore things to how they were. Since my attempts so
> far combined with examples will probably be more informative, here
> they come:
>
> 
>              Root='HKLM' Key='Software\CLASSES\.xyz' />
> 
>
> That ought to fill PROGID_XYZ with an already existing ProgID, or if
> the filetype is unknown, substitute my own default handler.
>
> 
>  
>                  Action="createAndRemoveOnUninstall">
>    
>  
> 
>
> This created the value in the proper place, but upon uninstallation,
> it removed the entire key, which makes sense since I asked it to. But
> in this case, the RegistrySearch was successful, and thus the
> appropriate ProgID already existed, and I essentially wiped out the
> file associations. Oops. How can I avoid this? If I were to make it
> action="create", I would never remove the handler afterwards if I
> understand correctly.
>
> To have it all in a little neat list, these are the requirements I am
> trying to achieve:
> * .XYZ exists - make changes in existing ProgID.
> * .XYZ does not exist - make the .XYZ key, and make my default ProgID.
> * Uninstallation: .XYZ already existed at installation - place back
> any settings I overwrote in the 'foreign' ProgID, and remove any new
> entries I made.
> * Uninstallation: .XYZ never existed at installation - remove .XYZ and
> my default ProgID.
>
> I have studied conditions, features, components and the various
> options available to me with a RegistrySearch, but I am pretty much
> lost. As such I appreciate any advice or examples you folks can give
> me to work off. :)
>
> Regards,
>
> Jan Wester
>
> 
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simpli

Re: [WiX-users] Conditional registry entries and handling them properly on uninstall

2009-11-24 Thread Blair
If you want to restore a previously existing registry key, you would have
had to have saved it someplace, or at least saved the fact that it
previously existed with enough information to recreate it. That means that
in your RegistrySearches you would need to be able to distinguish the
difference between a non-existent key (that you are defaulting, perhaps?)
and a previously existing key.

Or, can you change the situation a bit? Is it bad to leave the registry key
behind when you uninstall? Sometimes old droppings really aren't as bad as
the destruction that can be caused by trying to do a comprehensive job
cleaning up after yourself.

-Original Message-
From: Jan Wester [mailto:happyhon...@gmail.com] 
Sent: Saturday, November 21, 2009 11:37 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Conditional registry entries and handling them properly
on uninstall

Hello WiX community,

After the advice given to me yesterday, I've been focusing on the
subject I've had least replies on. Basically, I am trying to only
write a registry entry if it does not exist and create some keys to go
with it, or if it does exist, I want to modify things, and at
uninstall time, restore things to how they were. Since my attempts so
far combined with examples will probably be more informative, here
they come:


  


That ought to fill PROGID_XYZ with an already existing ProgID, or if
the filetype is unknown, substitute my own default handler.


  
  

  


This created the value in the proper place, but upon uninstallation,
it removed the entire key, which makes sense since I asked it to. But
in this case, the RegistrySearch was successful, and thus the
appropriate ProgID already existed, and I essentially wiped out the
file associations. Oops. How can I avoid this? If I were to make it
action="create", I would never remove the handler afterwards if I
understand correctly.

To have it all in a little neat list, these are the requirements I am
trying to achieve:
* .XYZ exists - make changes in existing ProgID.
* .XYZ does not exist - make the .XYZ key, and make my default ProgID.
* Uninstallation: .XYZ already existed at installation - place back
any settings I overwrote in the 'foreign' ProgID, and remove any new
entries I made.
* Uninstallation: .XYZ never existed at installation - remove .XYZ and
my default ProgID.

I have studied conditions, features, components and the various
options available to me with a RegistrySearch, but I am pretty much
lost. As such I appreciate any advice or examples you folks can give
me to work off. :)

Regards,

Jan Wester


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus
on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Conditional registry entries and handling them properly on uninstall

2009-11-21 Thread Jan Wester
Hello WiX community,

After the advice given to me yesterday, I've been focusing on the
subject I've had least replies on. Basically, I am trying to only
write a registry entry if it does not exist and create some keys to go
with it, or if it does exist, I want to modify things, and at
uninstall time, restore things to how they were. Since my attempts so
far combined with examples will probably be more informative, here
they come:


  


That ought to fill PROGID_XYZ with an already existing ProgID, or if
the filetype is unknown, substitute my own default handler.


  
  

  


This created the value in the proper place, but upon uninstallation,
it removed the entire key, which makes sense since I asked it to. But
in this case, the RegistrySearch was successful, and thus the
appropriate ProgID already existed, and I essentially wiped out the
file associations. Oops. How can I avoid this? If I were to make it
action="create", I would never remove the handler afterwards if I
understand correctly.

To have it all in a little neat list, these are the requirements I am
trying to achieve:
* .XYZ exists - make changes in existing ProgID.
* .XYZ does not exist - make the .XYZ key, and make my default ProgID.
* Uninstallation: .XYZ already existed at installation - place back
any settings I overwrote in the 'foreign' ProgID, and remove any new
entries I made.
* Uninstallation: .XYZ never existed at installation - remove .XYZ and
my default ProgID.

I have studied conditions, features, components and the various
options available to me with a RegistrySearch, but I am pretty much
lost. As such I appreciate any advice or examples you folks can give
me to work off. :)

Regards,

Jan Wester

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users