How can this save testing? You're going to invent something like a custom 
action to check various combinations of properties (and I don't know what that 
would be) and you're not going to test it?  You'd need to test that right-click 
an MSI file and Repair does what you expect, that any repair entry points 
(shortcuts and others) don't repair, that removing files or registry entries 
and having Windows try to repair does what you expect, and that's not a 
complete list either. And how will you test that the repair did or did not 
happen if your custom action code is incorrect? It seems to me that a test plan 
which makes sure you have really disabled repair involves more work that just 
letting Windows do what it does, and that doesn't even cover the customer 
experience issues with your proposed solution and the instability you're 
introducing by pretending some Windows feature can be turned off. It's like 
saying you don't support FilesInUse dialogs, requests for the original install 
source, reboots at the end of the install and other things that Windows will do 
whether you want to support them or not. 

Phil Wilson 

-----Original Message-----
From: Tony [mailto:yellowjacketl...@gmail.com] 
Sent: Thursday, January 07, 2010 4:42 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Disable repair and admin setup...

Ooops!  I replied directly rather than to the list...

We've just never seen a need to support repair. That entails extensive
testing by an already over-worked QA staff. All of our configuration
information is in databases and we never remove databases during
upgrade and/or uninstalls. So, if something really needs to be "fixed"
just uninstall/install.

I know that I personally never, ever do a repair. It just scares me
and I don't trust it.  Way too many "what ifs".

On Thu, Jan 7, 2010 at 6:51 PM, Sascha Beaumont
<sascha.beaum...@gmail.com> wrote:
> Tony, I'm echoing Phil and Blair here..
>
> Phil wrote:
>>> What is the problem that you believe disabling repair will solve?
>
> Blair wrote:
>>> If you have custom actions or other issues that break when repair is run,
>>> you should seek to fix those instead of disabling repair
>
> You shouldn't have to "support" repair, if repairing your installation
> breaks something then you're probably doing something wrong and you
> should be fixing the underlying issue rather than preventing repair.
>
> Custom Actions aside, try to think of your MSI as a description of how
> the system should look. When the system doesn't match the MSI, a
> repair is initiated. If you want an xcopy type setup, there are
> alternatives.
>
>
> Sascha
>
> On Fri, Jan 8, 2010 at 10:28 AM, Tony <yellowjacketl...@gmail.com> wrote:
>> We never patch, so that won't be an issue.  Thanks for the suggestion
>> regarding admin installs.
>>
>> In the past we have never really supported repair either.  So, we
>> strive to prevent it from being triggered.  We always use the
>> ARPNOREPAIR, but the question of "automated" repair came up and we
>> noticed it is still possible to trigger a repair action via that
>> mechanism.  We are trying to prevent repair not abort it as I might
>> have suggested above.
>>
>> On Thu, Jan 7, 2010 at 6:01 PM, Blair <os...@live.com> wrote:
>>> You could simply drop the AdminExecuteSequence (and AdminUISequence) tables.
>>> That would prevent administrative installations. I also echo the question of
>>> why.
>>>
>>> Disabling repair is a bigger "why?".
>>>
>>> If you are referring to the Repair button in the "Programs and Features"
>>> window just add the ARPNOREPAIR property <Property Id="ARPNOREPAIR"
>>> Value="1"/> to your <Product> element. That will still allow triggered
>>> repairs based on broken installs as well as patching and non-major upgrades,
>>> but I personally prefer to see products that allow Repair from the Programs
>>> and Features window.
>>>
>>> If you have custom actions or other issues that break when repair is run,
>>> you should seek to fix those instead of disabling repair. Those issues
>>> aren't just "repair" issues, they are also upgrade issues (and possibly even
>>> remove issues) that should never be shipped until you fix them.
>>>
>>> -----Original Message-----
>>> From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com]
>>> Sent: Thursday, January 07, 2010 1:49 PM
>>> To: General discussion for Windows Installer XML toolset.
>>> Subject: Re: [WiX-users] Disable repair and admin setup...
>>>
>>> I'm not too familiar with Administrative installs, but I would assume
>>> you could condition something in the AdminExecuteSequence and
>>> AdminUISequence to abort the install.
>>>
>>> Aborting if a repair is triggered sounds like a very strange request,
>>> what if your KeyPaths are damaged and you have advertised shortcuts?
>>> Windows Installer can no longer repair them and your app would likely
>>> fail to launch. The 'repair' functionality of Windows Installer is
>>> part of why you would choose to use MSI in the first place. If you're
>>> trying to bypass the resiliency features then maybe a non-MSI setup
>>> would be a better choice.
>>>
>>> Sascha
>>>
>>>
>>> On Fri, Jan 8, 2010 at 7:38 AM, Tony <yellowjacketl...@gmail.com> wrote:
>>>> Is there some way we can "disable" (abort install action) if someone
>>>> were to launch our msi with the /a (administrative install) or /f
>>>> (repair) options?  We can hide the actions in the UI, but when
>>>> launched via command-line they can still occur, we'd like to disable
>>>> them for now.
>>>>
>>>> --
>>>> Tony
>>>>
>>>>
>>> ----------------------------------------------------------------------------
>>> --
>>>> This SF.Net email is sponsored by the Verizon Developer Community
>>>> Take advantage of Verizon's best-in-class app development support
>>>> A streamlined, 14 day to market process makes app distribution fast and
>>> easy
>>>> Join now and get one step closer to millions of Verizon customers
>>>> http://p.sf.net/sfu/verizon-dev2dev
>>>> _______________________________________________
>>>> WiX-users mailing list
>>>> WiX-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>>
>>>
>>> ----------------------------------------------------------------------------
>>> --
>>> This SF.Net email is sponsored by the Verizon Developer Community
>>> Take advantage of Verizon's best-in-class app development support
>>> A streamlined, 14 day to market process makes app distribution fast and easy
>>> Join now and get one step closer to millions of Verizon customers
>>> http://p.sf.net/sfu/verizon-dev2dev
>>> _______________________________________________
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Verizon Developer Community
>>> Take advantage of Verizon's best-in-class app development support
>>> A streamlined, 14 day to market process makes app distribution fast and easy
>>> Join now and get one step closer to millions of Verizon customers
>>> http://p.sf.net/sfu/verizon-dev2dev
>>> _______________________________________________
>>> WiX-users mailing list
>>> WiX-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>
>>
>>
>> --
>> Tony
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
Tony

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privileged. 
If you have received it in error, you are on notice of its status. Please 
notify the sender immediately by reply e-mail and then delete this message from 
your system. Please do not copy it or use it for any purposes, or disclose its 
contents to any other person. This email comes from a division of the Invensys 
Group, owned by Invensys plc, which is a company registered in England and 
Wales with its registered office at Portland House, Bressenden Place, London, 
SW1E 5BF (Registered number 166023). For a list of European legal entities 
within the Invensys Group, please go to 
http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77. 
You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail 
inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be 
subject to the terms of any agreements between Invensys (and/or its 
subsidiaries and affiliates) and the recipient (and/or its subsidiaries and 
affiliates).



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to