Re: [WiX-users] Conditional registry entries and handling them properly on uninstall
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
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
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
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