Thanks for the detailed report.
However, I don't intend to 'fix' this because that change was done
intentionally:
https://sourceforge.net/p/tortoisesvn/code/25940/
This change makes it possible to get the 'repair' dialog of the
installer when doing an 'uninstall' from the control panel.
If you check other programs you'll see that many do the same, including
MS Office.
Stefan
On 07.10.2015 21:23, Ace Olszowka wrote:
> {{Summary}}
> TortoiseSVN's UninstallString does not contain the uninstall command,
> rather the
> package install (msiexec /I{PRODUCTCODE}) is used.
>
> This makes it a little more difficult to automate uninstall of the product.
>
> ***THIS MAY BE BY DESIGN/UPSTREAM WIX BUG/LIMITATION***
>
> {{Reproducible?}}
> Yes
>
> {{Steps To Reproduce}}
> After installing a TortoiseSVN Package navigate to
> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{PRODUCTCODE}
> and look at the UninstallString entry.
>
> The expectation is that this string contains the uninstall command:
>
> msiexec /X{PRODUCTCODE}
>
> As per the msiexec documentation
> https://technet.microsoft.com/en-us/library/cc759262%28v=ws.10%29.aspx#BKMK_Uninstall
> and The Uninstall Registry Key documentation
> https://msdn.microsoft.com/en-us/library/aa372105%28v=vs.85%29.aspx
> this is determined by the Windows Installer it appears this project uses
> WiX see
> below for more discussion.
>
> {{Work Around}}
> Those attempting to automate the uninstall process should parse for the
> PRODUCTCODE and send the appropriate msiexec command; this can be done in
> several ways:
>
> 1. (Recommended) As per the Uninstall Registry Key Documentation end
> users are
> promised that, when the package is an MSI (as is the case here), the
> Subkey
> is the PRODUCTCODE, it is recommended that whatever process is used
> to scan
> for the package returns this key.
> 1a. A popular script is Get-RemoteProgram
> https://gallery.technet.microsoft.com/scriptcenter/Get-RemoteProgram-Get-list-de9fd2b4
> which unfortunately does not return this information. The vendor
> has been
> contacted to backport a fix which allows end users of that script
> to easily
> retrieve the PRODUCTCODE.
> 2. Parse the Existing UninstallString looking for the PRODUCTCODE
> 2a. This is prone to failure if the developer is not careful in their
> parsing
> especially if the upstream project changes their uninstall string
> to perform
> any additional actions.
>
> {{Bug Previously Reported?}}
> Several posts on the mailing list are concerned with attempting to
> automate the
> servicing of TortoiseSVN, one such post from 2010 is here:
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2631063
> however the requested feature is not what is desired, the correct way to
> do this
> is to either ask MSIExec for the installed packages, or scan the
> registry for
> the desired product, and then invoke the UninstallString or invoke the
> msiexec /X{PRODUCTCODE}. Note that this second option will perform a
> straight up
> msiexec uninstall and is NOT necessarily the same as Add/Remove Programs,
> especially if the UninstallString has been customized.
>
> {{Version(s)}}
> Issue appears to be present in the latest stable build of TortoiseSVN
> 1.9.2.26806-x64-svn-1.9.2.msi at some point there may have been a
> regression as
> very old versions of TortoiseSVN (1.6.19260 is the "newest" one I've
> seen) have
> the expected msiexec uninstall string.
>
> I didn't see anything that stuck out as apparent in the WiX Installer
> source in
> Subversion that would be causing this.
>
> {{WiX Discussion}}
> Reading online it looks like there are a lot of results with regards to WiX
> and this Uninstall string, it may be that by design you are unable to rely
> on this as apparently this is also used to handle the Change/Modify dialog
> (which is when the "regression" might have occurred when this feature was
> added).
>
> The "bug" might even ben upstream/unsupported by WiX.
>
> I am by no means a WiX expert but would leave this:
>
> http://stackoverflow.com/questions/10280952/uninstallstring-being-set-with-i-not-x-param
>
> However none of those solutions looked appealing, worst case I'd say
> keep it as
> is and just make people aware of the work around (you'll have to do it
> anyway
> because you cannot guarantee what version you might be coming from).
>
> {{Contact}}
> Reported on the vendors mailing list. If additional information is
> required, it can be provided upon request via the mailing list.
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3141490
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-10-08 20:17:10 CEST