Re: [WiX-users] Issues with Burn (WiX v3.6.2921.0)
On 29-May-12 11:58, Pally Sandher wrote: Rob M. advised that to do the above with Burn I would have to schedule the v2.0 MSI for install Slipstream the 2.2 MSP since Burn assumes a false InstallConditon means uninstall rather than don't install. Right. You could do this in a custom BA, changing Burn's plan from uninstall to nothing. (I like that the engine has a feature to let a bundle clean up in this case but I agree there's another feature here: Long ago, I was in a thread with Fredrik that Burn needed an EnableCondition for the do-nothing scenario.) Running that command on a clean install produces the same issue as Burn, it hangs at the WelcomeDlg clicking Next does nothing. Log files - http://upload.iesve.com/downloads/burn_issues/sc_clean_before_cancel.log; http://upload.iesve.com/downloads/burn_issues/sc_clean.log Running that command when 1.4 is installed does the same as when nothing is installed. Log files - http://upload.iesve.com/downloads/burn_issues/sc_upgrade_before_cancel.log; http://upload.iesve.com/downloads/burn_issues/sc_upgrade.log Very weird: Both show MSI basically hanging at a 2727 error but with no directory. 2727 could be problematic though obviously it shouldn't cause a hang. (See my comment on the bug -- I can't download the patch to check it out.) One more thing to try: What happens if you use /qb or /qn to suppress the UI? -- sig://boB http://joyofsetup.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Issues with Burn (WiX v3.6.2921.0)
When I say 2.2 should be installed, ideally I'd be able to run the 2.2 MSI for major upgrades clean installs or the 2.2 MSP should be run for 2.0 or later. I could do this using simple conditions with dotnetinstaller as the MSI's MSP's support these scenarios when manually run, I just want to not rely on the user to download run the correct file for their specific scenario. Rob M. advised that to do the above with Burn I would have to schedule the v2.0 MSI for install Slipstream the 2.2 MSP since Burn assumes a false InstallConditon means uninstall rather than don't install. Running that command on a clean install produces the same issue as Burn, it hangs at the WelcomeDlg clicking Next does nothing. Log files - http://upload.iesve.com/downloads/burn_issues/sc_clean_before_cancel.log http://upload.iesve.com/downloads/burn_issues/sc_clean.log Running that command when 1.4 is installed does the same as when nothing is installed. Log files - http://upload.iesve.com/downloads/burn_issues/sc_upgrade_before_cancel.log http://upload.iesve.com/downloads/burn_issues/sc_upgrade.log Thanks for looking into this Bob. Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: 29 May 2012 03:32 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Issues with Burn (WiX v3.6.2921.0) On 22-May-12 08:22, Pally Sandher wrote: On a machine which has an existing v2.0 or later MSI installation, the MSP should be applied to update to v2.2 On a machine which has nothing installed, v2.2 should be installed On a machine which has an existing installation older than v2.0 a Major Upgrade should be applied to update to v2.2 The above scenarios all work when manually executing the relevant MSI or MSP show the expected errors when attempted outside of those conditions. When you say v2.2 should be installed, you mean, v2.0 should be installed and then patched to v2.2, right? The second case (fresh v2.0 plus slipstreamed patch) appears to be hung inside MSI (or at least there's nothing in the MSI log to indicate progress). On the third case (major upgrade plus patch), I suspect it's failing because MSI doesn't support it. The logs look like MSI is trying to apply the patch to the v1.4 installed product instead of slipstreamed to the v2.0 product. It's not clear that MSI supports applying a major upgrade with a slipstreamed patch view applied. Please try the following on a machine with and without v1.4 installed and upload the logs. msiexec /l*vx! /i VESharedContent.msi ALLUSERS=1 MSIFASTINSTALL=7 PATCH=VESharedContent.msp That's equivalent to what Burn is doing in both cases. -- sig://boB http://joyofsetup.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Issues with Burn (WiX v3.6.2921.0)
On 22-May-12 08:22, Pally Sandher wrote: On a machine which has an existing v2.0 or later MSI installation, the MSP should be applied to update to v2.2 On a machine which has nothing installed, v2.2 should be installed On a machine which has an existing installation older than v2.0 a Major Upgrade should be applied to update to v2.2 The above scenarios all work when manually executing the relevant MSI or MSP show the expected errors when attempted outside of those conditions. When you say v2.2 should be installed, you mean, v2.0 should be installed and then patched to v2.2, right? The second case (fresh v2.0 plus slipstreamed patch) appears to be hung inside MSI (or at least there's nothing in the MSI log to indicate progress). On the third case (major upgrade plus patch), I suspect it's failing because MSI doesn't support it. The logs look like MSI is trying to apply the patch to the v1.4 installed product instead of slipstreamed to the v2.0 product. It's not clear that MSI supports applying a major upgrade with a slipstreamed patch view applied. Please try the following on a machine with and without v1.4 installed and upload the logs. msiexec /l*vx! /i VESharedContent.msi ALLUSERS=1 MSIFASTINSTALL=7 PATCH=VESharedContent.msp That's equivalent to what Burn is doing in both cases. -- sig://boB http://joyofsetup.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Issues with Burn (WiX v3.6.2921.0)
Slipstreaming MSP's logs: http://upload.iesve.com/downloads/burn_issues/shared_content_clean_install_burn.log http://upload.iesve.com/downloads/burn_issues/shared_content_clean_install_msi.log - this is where it sticks with the Install button that does nothing when clicked no matter how long you leave it (only Cancel actually does anything at this point). http://upload.iesve.com/downloads/burn_issues/shared_content_major_upgrade_burn.log http://upload.iesve.com/downloads/burn_issues/shared_content_major_upgrade_msi.log Clicking the Install button when Burn is attempting to Uninstall does actually run an uninstall successfully. http://upload.iesve.com/downloads/burn_issues/uninstall_burn.log http://upload.iesve.com/downloads/burn_issues/uninstall_msi.log However Bob you're incorrect, WiXUI perfectly supports indirect uninstall with full UI. You can run the MSI you used to install the product you'll get that button saying Uninstall and the rest of the prompts labelled accordingly. It's only when run by Burn it appears to get confused so I can only assume Burn is doing something differently in this case. I agree though it should run as per ARP with the /x /qb options by default to be consistent. I'll log the .NET 4.0 issue as a bug on SourceForge. Do you want either of the other 2 issues logged? Thanks for looking into these issues Bob. Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: 23 May 2012 20:33 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Issues with Burn (WiX v3.6.2921.0) On 22-May-12 08:22, Pally Sandher wrote: 1 - Slipstreaming MSP's doesn't work Likely a bug. Need logs to know for sure. Obviously Install isn't what should be happening here. Using the MSI directly (circumventing Burn) will bring up the Uninstall process as expected. What happens if you click Install? WixUI doesn't have anything to support this case of indirect uninstall with full UI -- ARP and /x use basic UI. I'll work on making Burn do that too. [0AF4:0AB4][2012-05-22T13:04:26]: Error 0x80070667: Process returned error: 0x667 This actually works on XP but fails on Win7. Definitely a bug, probably in the .NET chainer, that we'll have to work around somehow. -- sig://boB http://joyofsetup.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Issues with Burn (WiX v3.6.2921.0)
On 24-May-12 10:02, Pally Sandher wrote: However Bob you're incorrect, WiXUI perfectly supports indirect uninstall with full UI. You can run the MSI you used to install the product you'll get that button saying Uninstall and the rest of the prompts labelled accordingly. That's maintenance mode -- the user has to then choose Uninstall (or Repair or Modify). What I was talking about is specifying that you want an uninstall from the command line but still go through the full UI sequence, essentially: msiexec /i foo.msi REMOVE=ALL. Try that, you'll get the same ResumeDlg you were getting from Burn. I agree though it should run as per ARP with the /x /qb options by default to be consistent. I'm running it with no UI. I started with basic UI but it looked pretty silly with two progress bars. I'll log the .NET 4.0 issue as a bug on SourceForge. Do you want either of the other 2 issues logged? Please log the slipstreaming bug. I already have the UI bug fixed, so file that if you want. AFAIK, neither of us gets paid per bug, so...g -- sig://boB http://joyofsetup.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Issues with Burn (WiX v3.6.2921.0)
On 22-May-12 08:22, Pally Sandher wrote: 1 - Slipstreaming MSP's doesn't work Likely a bug. Need logs to know for sure. Obviously Install isn't what should be happening here. Using the MSI directly (circumventing Burn) will bring up the Uninstall process as expected. What happens if you click Install? WixUI doesn't have anything to support this case of indirect uninstall with full UI -- ARP and /x use basic UI. I'll work on making Burn do that too. [0AF4:0AB4][2012-05-22T13:04:26]: Error 0x80070667: Process returned error: 0x667 This actually works on XP but fails on Win7. Definitely a bug, probably in the .NET chainer, that we'll have to work around somehow. -- sig://boB http://joyofsetup.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Issues with Burn (WiX v3.6.2921.0)
1 - Slipstreaming MSP's doesn't work
Code:
Chain
[snip]
MsiPackage Id=SharedContentFull
SourceFile=..\..\..\..\..\TEMP\VESharedContent.msi
After=NET4.0
Compressed=no
DisplayInternalUI=yes
DownloadUrl=[removed]VESharedContent.msi
ForcePerMachine=yes
Permanent=yes
Visible=yes
Vital=yes
SlipstreamMsp Id=SharedContentPatch /
/MsiPackage
MspPackage Id=SharedContentPatch
SourceFile=..\..\..\install\VESharedContent.msp
After=NET4.0
Compressed=no
DisplayInternalUI=yes
DownloadUrl=[removed]VESharedContent.msp
InstallSize=1
PerMachine=yes
Permanent=yes
Vital=yes
Slipstream=yes /
[snip]
/Chain
What's meant to happen:
On a machine which has an existing v2.0 or later MSI installation, the MSP
should be applied to update to v2.2
On a machine which has nothing installed, v2.2 should be installed
On a machine which has an existing installation older than v2.0 a Major Upgrade
should be applied to update to v2.2
The above scenarios all work when manually executing the relevant MSI or MSP
show the expected errors when attempted outside of those conditions.
What actually happens:
On a machine which has an existing MSI installation, the MSP applies
successfully as expected.
On a machine with nothing installed it hangs at the following -
http://upload.iesve.com/downloads/burn_issues/shared_content_hang.png (clicking
the Next button does nothing, it will sit here for hours).
On a machine which has an existing installation older than v2.0 it fails. Burn
log extract:
[0BF4:0188][2012-05-22T12:05:19]: Applying execute package: SharedContentFull,
action: Install, path: C:\ProgramData\Package
Cache\{92E2C426-6CDB-44D4-8D48-6414A442231D}v2.0.0\VESharedContent.msi,
arguments: ' ALLUSERS=1 MSIFASTINSTALL=7 PATCH=C:\ProgramData\Package
Cache\{C87ACD42-5458-4168-949C-F495E1140AAE}\VESharedContent.msp'
[0BF4:0188][2012-05-22T12:05:44]: Error 0x8007066a: Failed to install MSI
package.
[0BF4:0188][2012-05-22T12:05:44]: Error 0x8007066a: Failed to execute MSI
package.
[0AAC:08EC][2012-05-22T12:05:44]: Error 0x8007066a: Failed to configure
per-machine MSI package.
[0AAC:08EC][2012-05-22T12:05:44]: Applied execute package: SharedContentFull,
result: 0x8007066a, restart: None
[0AAC:08EC][2012-05-22T12:05:44]: Error 0x8007066a: Failed to execute MSI
package.
[0BF4:0188][2012-05-22T12:05:44]: Removing cached package: SharedContentFull,
from path: C:\ProgramData\Package
Cache\{92E2C426-6CDB-44D4-8D48-6414A442231D}v2.0.0\
Windows Installer log for the above package -
http://upload.iesve.com/downloads/burn_issues/shared_content_major_upgrade.txt
The MSI in the above code is the v2.0 MSI not the v2.2 as advised by Rob M -
https://sourceforge.net/mailarchive/message.php?msg_id=29195304 and as stated
above using the MSI and/or MSP where applicable outside of Burn works as
expected in all scenarios.
2 - Burn package uninstall doesn't work.
Scenario 1 AKA The Rock
Code:
Bundle Name=IES Virtual Environment 2012
Version=12.1.0.0
Manufacturer=Integrated Environmental Solutions Limited
UpgradeCode=[removed]
Compressed=yes
AboutUrl=http://www.iesve.com/;
Copyright=IES Virtual Environment is Copyright (c) 2012 Integrated
Environmental Solutions Limited.
HelpTelephone=+44 (0)141 945 8500
HelpUrl=http://www.iesve.com/support;
IconSourceFile=..\VEInstall\res\VE.ico
UpdateUrl=http://www.iesve.com/;
BootstrapperApplicationRef
Id=WixStandardBootstrapperApplication.HyperlinkLicense
bal:WixStandardBootstrapperApplication LicenseUrl=
SuppressOptionsUI=yes LogoFile=res\IES_Logo.png /
/BootstrapperApplicationRef
Chain
[snip]
MsiPackage Id=ve
SourceFile=..\..\..\install\ve2012.msi
After=SharedContentPatch
Compressed=yes
DisplayInternalUI=yes
ForcePerMachine=yes
Visible=no
Vital=yes /
MsiPackage Id=SketchUpPlugin
SourceFile=..\..\..\install\SketchUpPlugin2012.msi
After=ve
Compressed=yes
DisplayInternalUI=yes
ForcePerMachine=yes
Visible=no
Vital=yes /
MsiPackage Id=RevitPlugin
SourceFile=..\..\..\install\RevitPlugin2012.msi
After=SketchUpPlugin
Compressed=yes
DisplayInternalUI=yes
ForcePerMachine=yes
Visible=no
Vital=yes /
/Chain
/Bundle
What's
