This speaks to the best practice of always setting up your bundles so that they
use the package hashes instead of signatures to validate that the correct
package was retrieved.
> From: dan.mad...@quanser.com
> To: wix-users@lists.sourceforge.net
> Date: Tue, 7 Jan 2014 12:22:13 -0500
> Subject: Re: [WiX-users] Burn not uninstalling MSI downloaded from URL
>
> Hi Rob,
>
> I recognize that System Restore isn't a magic bullet, but it has been working
> fairly well for me in this case. It turns out that the package cache was not
> in a dirty state. Instead, I found out the wrong MSI was put online. The file
> sizes were the same as was the Summary Information in Orca and UpgradeCode so
> it wasn't immediately evident. The bootstrapper would download the online
> version and then fail to register it because it was trying to register the
> ProductCode GUID used when it was built while the downloaded MSI had a
> different ProductCode. Hence, the registration failed because it could not
> find the ProductCode in the list of installed products. However, it continued
> with the install anyways without any warning given to the user.
>
> The net effect of this failed registration did not turn up until I attempted
> to uninstall, in which case it decided (I think) that the product was not
> installed (since it was using the wrong GUID) so no action was required other
> than removing the cached MSI and bootstrapper. So the uninstall also
> "succeeded" even though the product was actually left installed. Again, no
> feedback to the user indicating failure and the ARP entry was removed, while
> the files were left on the system.
>
> Moral of the story: always make sure the online MSI and local MSI used as the
> SourceFile for the MsiPackage are absolutely identical. Obvious, but mistakes
> are quite costly, potentially leaving users with no way to uninstall the
> product from their machine without technical support.
>
> Thanks for your help.
>
> Dan
>
> -----Original Message-----
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Monday, January 06, 2014 4:39 PM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Burn not uninstalling MSI downloaded from URL
>
> System Restore isn't a system reset. I've never seen it work terribly well.
> If you want system reset, use a VM and snapshots.
>
> The messages you are seeing are pretty suspect. They suggest the package
> cache is constantly in a dirty state which shouldn't be happening with normal
> install/uninstall. Anyway, the bundle log file should show why a package is
> not being uninstalled.
>
> -----Original Message-----
> From: Daniel Madill [mailto:dan.mad...@quanser.com]
> Sent: Monday, January 6, 2014 1:27 PM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Burn not uninstalling MSI downloaded from URL
>
> Hi,
>
> I don't think so. I don't have the packages as part of any other bundle.
> Also, I can always install and uninstall fine if I put the MSIs on the local
> filesystem, but never when it has to download the MSI from the URL. I've also
> been using System Restore to put my system back in its original state. I
> searched for the package code of the MSI in the registry after uninstall but
> could not find it. However, just in case I did not look properly, where
> should I expect to find the reference counts for the packages in the registry
> and should I be looking for the package code from the summary information of
> the MSI, the upgrade code or the component GUIDS (of which there are probably
> 13000 so I hope not).
>
> If I have the MSIs on the local filesystem then I do not get the "Unable to
> register source directory" warning in the install log, nor do I get the
> "Detected partially cached package" in the uninstall log. It is only when it
> has to download the MSI from the URL that I get these warnings in the logs.
>
> I added Cache='yes' and 'CacheId' values but that didn't help. Is the fact I
> use a relative path as part of the Name attribute a problem for downloaded
> packages? It does appear to download and cache the MSI in the
> C:\ProgramData\Package Cache folder after downloading it so I'm surprised by
> the "Detected partially cached package" warning in the uninstall log.
>
> Is there anything else I can do to better debug the problem?
>
> Thanks.
>
> Dan
>
> -----Original Message-----
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Monday, January 06, 2014 3:36 PM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Burn not uninstalling MSI downloaded from URL
>
> First guess: maybe the packages are being reference counted by another bundle
> still on the machine.
>
> -----Original Message-----
> From: Daniel Madill [mailto:dan.mad...@quanser.com]
> Sent: Monday, January 6, 2014 12:24 PM
> To: WiX-users@lists.sourceforge.net
> Subject: [WiX-users] Burn not uninstalling MSI downloaded from URL
>
> Hi,
>
> I have a simple burn bundle that contains three packages: .NET, a 64-bit MSI
> and an equivalent 32-bit MSI. The MSIs are not compressed as part of the
> bundle EXE but are external. The MsiPackage elements have both a SourceFile
> attribute and a DownloadURL attribute. If I run the bundle EXE with the MSI's
> contained on the local file system then the bundle uses the appropriate local
> MSI and installs the package. The package can also be uninstalled without any
> problem.
>
> If I remove the MSI from the local file system to force the bundle to use the
> download URL then it does indeed download the MSI from the URL and install it
> successfully.
>
> HOWEVER, in this case, uninstalling the bundle causes the bundle to be
> removed from ARP with no complaints, but the MSI files are NOT UNINSTALLED.
> In other words, it clearly has not uninstalled the MSI. It only uninstalls
> the bundle. This leaves my system in a state where I have to manually remove
> all the files that were installed by the MSI and then do a System Restore to
> get rid of the component registrations.
>
> I'm using the ManagedBootstrapperApplicationHost with a version of the
> src/Setup/WixBA that has only been modified slightly (really just small
> changes to the GUI and "check for update" code so far).
>
> My Chain looks like:
>
> <Chain>
> <PackageGroupRef Id='NetFx40Web' />
> <MsiPackage Id='myapp_win64'
> Name='win64\myapp.msi'
> SourceFile='$(var.MyApp.ProjectDir)win64\myapp.msi'
> DownloadUrl='http://mycompany.com/win64/myapp.msi'
> InstallCondition='VersionNT64 >= v6.1'
> Compressed='no'
> Permanent='no'/>
> <MsiPackage Id='myapp_win32'
> Name='win32\myapp.msi'
> SourceFile='$(var.MyApp.ProjectDir)win32\myapp.msi'
> DownloadUrl='http://mycompany.com/win32/myapp.msi'
> InstallCondition='(NOT VersionNT64) AND (VersionNT >=
> v6.1)'
> Compressed='no'
> Permanent='no'/>
> </Chain>
>
> The only thing I noticed in the log that looked like a warning during install
> was the line:
>
> [1010:0D9C][2014-01-06T14:23:04]w355: Unable to register source directory:
> C:\ProgramData\Package
> Cache\{E351F542-514D-4019-8362-61F01897D08B}v2.3.703\win64\, product:
> {E351F542-514D-4019-8362-61F01897D08B}, reason: 0x80070645. Continuing...
>
> During uninstall, the log showed the following line that looked suspicious:
>
> [1320:1644][2014-01-06T14:31:31]w120: Detected partially cached package:
> myapp_win64, invalid payload: myapp_win64, reason: 0x80070570
>
> Does anyone know what is going wrong? Do I need to define the Cache
> attributes for the MsiPackage elements? I can provide more of the logs if
> needed. It never creates an uninstall log specific to the MSI so it looks to
> me like it never even attempts to uninstall the MSI.
>
> Ultimately what I want to do is have a single bundle EXE that I put on a
> distribution CD as well as on the web. On the distribution CD, I will also
> have the two MSIs on the CD so that everything the user needs is available on
> the CD. On the web, I will put the MSIs at the download URLs so that the
> customer only has to download the bundle EXE, which is quite small, and then
> the bundle EXE itself will download the MSI it needs depending on whether the
> client is running a 32-bit or 64-bit version of Windows.
>
> It all seemed to work beautifully and seamlessly until I tried to uninstall
> the bundle after installing from the web.
>
> Sincerely,
>
> Daniel Madill
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
