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

Reply via email to