Re: [WiX-users] Burn not uninstalling MSI downloaded from URL
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
Re: [WiX-users] Burn not uninstalling MSI downloaded from URL
So you mean set SuppressSignatureVerification=yes in the MSIPackage, ExePackage,... ? Looks like I'm going to have to make a change although I don't do this and had no problem so far. . Wes -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: January-08-14 7:10 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Burn not uninstalling MSI downloaded from URL 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
Re: [WiX-users] Burn not uninstalling MSI downloaded from URL
There is some high level discussion about the value of signing right now. It came up in relation to WIXBUG:4243 - http://wixtoolset.org/issues/4243/. -Original Message- From: Wesley Manning [mailto:wmann...@dynagen.ca] Sent: Wednesday, January 8, 2014 1:09 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Burn not uninstalling MSI downloaded from URL So you mean set SuppressSignatureVerification=yes in the MSIPackage, ExePackage,... ? Looks like I'm going to have to make a change although I don't do this and had no problem so far. . Wes -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: January-08-14 7:10 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Burn not uninstalling MSI downloaded from URL 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
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
[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=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
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=84349831iu=/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
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
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
