Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper
Could you please share the complete code. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/dual-purpose-installer-ALLUSERS-2-and-Bootstrapper-tp7591740p7596724.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Custom action issue when msi is generated on Windows 8.1 and installed on Windows 8 or Windows 7
Hi, I'm calling a custom action on upgrade and delete of an application. The custom action essentially deletes certain folders (not part of the installation folder) using the command prompt. When the msi is generated on windows 7/ windows 8, and then launched either on windows 7/windows 8/windows 8.1 - the custom action works perfectly fine. But, when the msi is generated on windows 8.1 and launched on either windows 7 or windows 8 -- the folders are not being deleted. The same generated msi is working fine on other windows 8.1 systems. Please let me know how to address this issue. Regards, Sharpi. Sent from Windows Mail -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom action issue when msi is generated on Windows 8.1 and installed on Windows 8 or Windows 7
Why reinvent the wheel? http://wixtoolset.org/documentation/manual/v3/xsd/util/removefolderex.html -Original Message- From: sharada boda [mailto:sharada.b...@outlook.com] Sent: Tuesday, September 09, 2014 6:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Custom action issue when msi is generated on Windows 8.1 and installed on Windows 8 or Windows 7 Hi, I'm calling a custom action on upgrade and delete of an application. The custom action essentially deletes certain folders (not part of the installation folder) using the command prompt. When the msi is generated on windows 7/ windows 8, and then launched either on windows 7/windows 8/windows 8.1 - the custom action works perfectly fine. But, when the msi is generated on windows 8.1 and launched on either windows 7 or windows 8 -- the folders are not being deleted. The same generated msi is working fine on other windows 8.1 systems. Please let me know how to address this issue. Regards, Sharpi. Sent from Windows Mail -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container
Ok, did some install testing of the upgrade from the earlier version to 1709 this morning. Windows Server 2008 R2 No repro Windows Server 2012 No repro Windows 8 Reproduces I'm digging through the logs . . . -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: Sascha Sertel [mailto:sascha.ser...@gmail.com] Sent: Monday, September 8, 2014 5:31 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container Right, fresh install works fine for me, it's only the upgrade case that is borked. // Sascha On Mon, Sep 8, 2014 at 3:07 PM, John Cooper jocoo...@jackhenry.com wrote: It doesn't replicate for me in the NOT installed case for the 1709 version of the product. I'll get the earlier product tonight and test the upgrade case tomorrow. -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 | jocoo...@jackhenry.com -Original Message- From: John Cooper Sent: Monday, September 8, 2014 2:54 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container If a file is unversioned, the normal file versioning rules and process don’t apply to it. In the case of these three assemblies, they end up being entries in the MsiFileHash table. However, file timestamps control whether the MsiFileHash table is even entered. Repairs are also going to be strange. Likewise patching. That being said, it is a concern, but unlikely to be the source of your problem. -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: Monday, September 8, 2014 2:28 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container For what it is worth, I tried one of my investigation packages with a fake exe (for the sake of ease of recognizing as a fake) which, needless to say, has no version at all. It seems to upgrade fine with no trouble. Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du | Canada -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: September-08-14 3:18 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I notice that Agent.Interop.dll, CefSharp.dll, and CefSharpt.Wpf.dll all are completely unversioned (no version numbers at all). When an upgrade works, what to does the log look like for these three files? -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: Sascha Sertel [mailto:sascha.ser...@gmail.com] Sent: Monday, September 8, 2014 2:02 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container Yes, my installer uses a bundle because I have .NET Framework 4.5.1 and Visual C++ 12 runtime components as a prerequisite before running my actual product MSI. I haven't actually tried if the upgrade failure also repros using the product MSI only instead of the bundle, I'll try that out today. Maybe it's actually something about upgrading a bundle that causes the failure to happen. In terms of what do we know, I don't think we know anything, we have yet to find anything common between the failing installers. It seems to fail for both per-user and per-machine installs, domain as well as workgroup user accounts, elevated and non-elevated privileges, none of that seems to matter. // Sascha On Mon, Sep 8, 2014 at 11:48 AM, keith.doug...@statcan.gc.ca wrote: Let me echo John here, I am trying to help us and also help the community. We are worse off, too, than some, because the machines I deal with are mostly-disconnected remotes which receive the vast majority of their tech support via RDP if at all. It seems that most
Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container
Factor that may or may not mean anything:
Upgrade Scheduling appears to be InstallValidate
REINSTALLMODE: vomus
OS: Windows 8 with latest updates including KB2918614
Profile: Roaming (only able to reproduce on a laptop)
MajorUpgrade authoring is not being used (custom Upgrade Table entries)
Failure looks like this in the MSI log:
MSI (s) (A8:E8) [09:20:04:609]: Determining source type
MSI (s) (A8:E8) [09:20:04:609]: Source type from package 'Lyve Product.msi': 10
MSI (s) (A8:E8) [09:20:04:609]: SECREPAIR: Hash Database:
C:\WINDOWS\Installer\SourceHash{C5E60292-2E11-4FAE-883F-E548ECF032F7}
MSI (s) (A8:E8) [09:20:04:625]: SECREPAIR: CryptAcquireContext succeeded
MSI (s) (A8:E8) [09:20:04:844]: SECREPAIR: filename: Lyve Product.msi Stored
Hash Value:RUgGMOmbpYsraTZ8VjLP1M9KGepCCMUiBVmXkOMCD6w= Current
Hash:TfXkukwiWlgqxX0jqHwgUEwjjKlSG2KJpuZX/cEM3Uw=
MSI (s) (A8:E8) [09:20:04:844]: Machine policy value 'AlwaysInstallElevated' is 0
MSI (s) (A8:E8) [09:20:04:844]: User policy value 'AlwaysInstallElevated' is 0
MSI (s) (A8:E8) [09:20:04:844]: MSI_LUA: Elevation prompt disabled for silent
installs
MSI (s) (A8:E8) [09:20:04:844]: Note: 1: 3
MSI (s) (A8:E8) [09:20:04:844]: SECUREREPAIR: SecureRepair Failed. Error code:
364DF2640
MSI (s) (A8:E8) [09:20:04:859]: Note: 1: 2265 2: 3: -2147287035
MSI (s) (A8:E8) [09:20:04:859]: Machine policy value 'DisableRollback' is 0
MSI (s) (A8:E8) [09:20:04:859]: Note: 1: 1402 2:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts
3: 2
Action ended 9:20:04: RegisterProduct. Return value 2.
It looks like this in the bootstrapper log:
[1D64:1100][2014-09-09T09:20:01]i300: Apply begin
[1D64:1100][2014-09-09T09:20:02]i000: Caching bundle from:
'C:\Users\jocooper\AppData\Local\Temp\{a8554c44-e09c-479f-a8e5-685f5bf90487}\.be\Lyve
Setup.exe' to: 'C:\Users\jocooper\AppData\Local\Package
Cache\{a8554c44-e09c-479f-a8e5-685f5bf90487}\Lyve Setup.exe'
[1D64:1100][2014-09-09T09:20:02]i320: Registering bundle dependency provider:
{a8554c44-e09c-479f-a8e5-685f5bf90487}, version: 1.0.1.1079
[1D64:1FFC][2014-09-09T09:20:02]i305: Verified acquired payload: Lyve at path:
C:\Users\jocooper\AppData\Local\Package Cache\.unverified\Lyve, moving to:
C:\Users\jocooper\AppData\Local\Package
Cache\{C5E60292-2E11-4FAE-883F-E548ECF032F7}v1.0.1.1079\Lyve Product.msi.
[1D64:1100][2014-09-09T09:20:02]i323: Registering package dependency provider:
{C5E60292-2E11-4FAE-883F-E548ECF032F7}, version: 1.0.1.1079, package: Lyve
[1D64:1100][2014-09-09T09:20:02]i301: Applying execute package: Lyve, action:
MinorUpgrade, path: C:\Users\jocooper\AppData\Local\Package
Cache\{C5E60292-2E11-4FAE-883F-E548ECF032F7}v1.0.1.1079\Lyve Product.msi,
arguments: ' ARPSYSTEMCOMPONENT=1 MSIFASTINSTALL=7'
[1D64:1100][2014-09-09T09:20:04]e000: Error 0x80070642: Failed to perform minor
upgrade of MSI package.
[1D64:1100][2014-09-09T09:20:04]e000: Error 0x80070642: Failed to configure
per-user MSI package.
[1D64:1100][2014-09-09T09:20:04]i319: Applied execute package: Lyve, result:
0x80070642, restart: None
[1D64:1100][2014-09-09T09:20:04]e000: Error 0x80070642: Failed to execute MSI
package.
An earlier upgrade with the same installers succeed when KB2918614 was missing.
I then remove the product, applied the update, and rebooted. Initial install
of the older product succeeded. Upgrade failed.
It appears that the digital signature requirements for repair/upgrade using
msiexec 5.0 have been more strict. The stored hash and the computed hash are
not matching after the update (they did before) and that is failing the upgrade.
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development
Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: John Cooper
Sent: Tuesday, September 9, 2014 9:42 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the
default key container
Ok, did some install testing of the upgrade from the earlier version to 1709
this morning.
Windows Server 2008 R2 No repro
Windows Server 2012 No repro
Windows 8 Reproduces
I'm digging through the logs . . .
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: Sascha Sertel [mailto:sascha.ser...@gmail.com]
Sent: Monday, September 8, 2014 5:31 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the
default key container
Right, fresh install works fine for me, it's only the upgrade case that is
borked.
// Sascha
On Mon, Sep 8, 2014 at 3:07 PM, John Cooper jocoo...@jackhenry.com wrote:
It doesn't replicate for me in
Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container
By the way this also only seems to affect MinorUpgrade.
I tried out changing the product code to execute a MajorUpgrade, and indeed
the upgrade worked fine. So this further narrows it down and explains why
many others aren't seeing this, I guess MinorUpgrades aren't as common as I
thought?
// Sascha
On Tue, Sep 9, 2014 at 8:52 AM, John Cooper jocoo...@jackhenry.com wrote:
Factor that may or may not mean anything:
Upgrade Scheduling appears to be InstallValidate
REINSTALLMODE: vomus
OS: Windows 8 with latest updates including KB2918614
Profile: Roaming (only able to reproduce on a laptop)
MajorUpgrade authoring is not being used (custom Upgrade Table entries)
Failure looks like this in the MSI log:
MSI (s) (A8:E8) [09:20:04:609]: Determining source type
MSI (s) (A8:E8) [09:20:04:609]: Source type from package 'Lyve
Product.msi': 10
MSI (s) (A8:E8) [09:20:04:609]: SECREPAIR: Hash Database:
C:\WINDOWS\Installer\SourceHash{C5E60292-2E11-4FAE-883F-E548ECF032F7}
MSI (s) (A8:E8) [09:20:04:625]: SECREPAIR: CryptAcquireContext succeeded
MSI (s) (A8:E8) [09:20:04:844]: SECREPAIR: filename: Lyve Product.msi
Stored Hash Value:RUgGMOmbpYsraTZ8VjLP1M9KGepCCMUiBVmXkOMCD6w= Current
Hash:TfXkukwiWlgqxX0jqHwgUEwjjKlSG2KJpuZX/cEM3Uw=
MSI (s) (A8:E8) [09:20:04:844]: Machine policy value
'AlwaysInstallElevated' is 0
MSI (s) (A8:E8) [09:20:04:844]: User policy value 'AlwaysInstallElevated'
is 0
MSI (s) (A8:E8) [09:20:04:844]: MSI_LUA: Elevation prompt disabled for
silent installs
MSI (s) (A8:E8) [09:20:04:844]: Note: 1: 3
MSI (s) (A8:E8) [09:20:04:844]: SECUREREPAIR: SecureRepair Failed. Error
code: 364DF2640
MSI (s) (A8:E8) [09:20:04:859]: Note: 1: 2265 2: 3: -2147287035
MSI (s) (A8:E8) [09:20:04:859]: Machine policy value 'DisableRollback' is 0
MSI (s) (A8:E8) [09:20:04:859]: Note: 1: 1402 2:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts
3: 2
Action ended 9:20:04: RegisterProduct. Return value 2.
It looks like this in the bootstrapper log:
[1D64:1100][2014-09-09T09:20:01]i300: Apply begin
[1D64:1100][2014-09-09T09:20:02]i000: Caching bundle from:
'C:\Users\jocooper\AppData\Local\Temp\{a8554c44-e09c-479f-a8e5-685f5bf90487}\.be\Lyve
Setup.exe' to: 'C:\Users\jocooper\AppData\Local\Package
Cache\{a8554c44-e09c-479f-a8e5-685f5bf90487}\Lyve Setup.exe'
[1D64:1100][2014-09-09T09:20:02]i320: Registering bundle dependency
provider: {a8554c44-e09c-479f-a8e5-685f5bf90487}, version: 1.0.1.1079
[1D64:1FFC][2014-09-09T09:20:02]i305: Verified acquired payload: Lyve at
path: C:\Users\jocooper\AppData\Local\Package Cache\.unverified\Lyve,
moving to: C:\Users\jocooper\AppData\Local\Package
Cache\{C5E60292-2E11-4FAE-883F-E548ECF032F7}v1.0.1.1079\Lyve Product.msi.
[1D64:1100][2014-09-09T09:20:02]i323: Registering package dependency
provider: {C5E60292-2E11-4FAE-883F-E548ECF032F7}, version: 1.0.1.1079,
package: Lyve
[1D64:1100][2014-09-09T09:20:02]i301: Applying execute package: Lyve,
action: MinorUpgrade, path: C:\Users\jocooper\AppData\Local\Package
Cache\{C5E60292-2E11-4FAE-883F-E548ECF032F7}v1.0.1.1079\Lyve Product.msi,
arguments: ' ARPSYSTEMCOMPONENT=1 MSIFASTINSTALL=7'
[1D64:1100][2014-09-09T09:20:04]e000: Error 0x80070642: Failed to perform
minor upgrade of MSI package.
[1D64:1100][2014-09-09T09:20:04]e000: Error 0x80070642: Failed to
configure per-user MSI package.
[1D64:1100][2014-09-09T09:20:04]i319: Applied execute package: Lyve,
result: 0x80070642, restart: None
[1D64:1100][2014-09-09T09:20:04]e000: Error 0x80070642: Failed to execute
MSI package.
An earlier upgrade with the same installers succeed when KB2918614 was
missing. I then remove the product, applied the update, and rebooted.
Initial install of the older product succeeded. Upgrade failed.
It appears that the digital signature requirements for repair/upgrade
using msiexec 5.0 have been more strict. The stored hash and the computed
hash are not matching after the update (they did before) and that is
failing the upgrade.
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development
Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |
jocoo...@jackhenry.com
-Original Message-
From: John Cooper
Sent: Tuesday, September 9, 2014 9:42 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create
the default key container
Ok, did some install testing of the upgrade from the earlier version to
1709 this morning.
Windows Server 2008 R2 No repro
Windows Server 2012 No repro
Windows 8 Reproduces
I'm digging through the logs . . .
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext:
431050 |jocoo...@jackhenry.com
-Original Message-
From:
Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container
I figure it was a minor upgrade with the ProductCodes.
There was some expression of interest in a registry dump on my reproducing
machine for HKCR\Msi.Package. So, here it is:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Msi.Package]
@=Windows Installer Package
InfoTip=prop:System.ItemType;System.Author;System.Title;System.Subject;System.Comment;System.DateModified;System.Size
EditFlags=hex:00,00,10,00
FullDetails=prop:System.PropGroup.Description;System.Title;System.Subject;System.Category;System.Keywords;System.Comment;System.PropGroup.Origin;System.Author;System.Document.RevisionNumber;System.Document.DateCreated;System.ApplicationName;System.PropGroup.FileSystem;System.ItemNameDisplay;System.ItemType;System.ItemFolderPathDisplay;System.DateCreated;System.DateModified;System.Size;System.FileAttributes;System.OfflineAvailability;System.OfflineStatus;System.SharedWith;System.FileOwner;System.ComputerName
FriendlyTypeName=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,\
00,6f,00,6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,\
32,00,5c,00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,\
00,2d,00,33,00,34,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\DefaultIcon]
@=C:\\Windows\\System32\\msiexec.exe,0
[HKEY_CLASSES_ROOT\Msi.Package\shell]
@=Open,Repair,Uninstall
[HKEY_CLASSES_ROOT\Msi.Package\shell\edit]
@=Edit with Orca
[HKEY_CLASSES_ROOT\Msi.Package\shell\edit\command]
@=\C:\\Program Files (x86)\\Orca\\Orca.exe\ \%1\
command=hex(7):36,00,59,00,55,00,27,00,53,00,72,00,2d,00,54,00,35,00,40,00,\
45,00,40,00,35,00,4c,00,28,00,28,00,2e,00,6d,00,4a,00,55,00,4f,00,72,00,63,\
00,61,00,3e,00,6e,00,52,00,37,00,39,00,66,00,5e,00,26,00,71,00,66,00,28,00,\
76,00,3f,00,65,00,71,00,46,00,28,00,29,00,77,00,26,00,47,00,20,00,22,00,25,\
00,31,00,22,00,00,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Open]
@=Install
MUIVerb=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,\
6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,\
00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,\
33,00,36,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Open\command]
@=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\
73,00,69,00,65,00,78,00,65,00,63,00,2e,00,65,00,78,00,65,00,22,00,20,00,2f,\
00,69,00,20,00,22,00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Repair]
@=Repair
MUIVerb=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,\
6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,\
00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,\
33,00,37,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Repair\command]
@=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\
73,00,69,00,65,00,78,00,65,00,63,00,2e,00,65,00,78,00,65,00,22,00,20,00,2f,\
00,66,00,20,00,22,00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\runasuser]
@=@shell32.dll,-50944
SuppressionPolicyEx={F211AA05-D4DF-4370-A2A0-9F19C09756A7}
Extended=
[HKEY_CLASSES_ROOT\Msi.Package\shell\runasuser\command]
DelegateExecute={ea72d00e-4960-42fa-ba92-7792a7944c1d}
[HKEY_CLASSES_ROOT\Msi.Package\shell\Uninstall]
@=Uninstall
MUIVerb=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,\
6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,\
00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,\
33,00,38,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Uninstall\command]
@=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\
73,00,69,00,65,00,78,00,65,00,63,00,2e,00,65,00,78,00,65,00,22,00,20,00,2f,\
00,78,00,20,00,22,00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shellex]
[HKEY_CLASSES_ROOT\Msi.Package\shellex\ContextMenuHandlers]
@=Compatibility
[HKEY_CLASSES_ROOT\Msi.Package\shellex\ContextMenuHandlers\Compatibility]
@={1d27f844-3a1f-4410-85ac-14651078412d}
[HKEY_CLASSES_ROOT\Msi.Package\shellex\PropertySheetHandlers]
[HKEY_CLASSES_ROOT\Msi.Package\shellex\PropertySheetHandlers\ShimLayer Property
Page]
@={513D916F-2A8E-4F51-AEAB-0CBC76FB1AF8}
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development
Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: John Cooper
Sent: Tuesday, September 9, 2014 10:53 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the
default key container
Factor that may or
Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container
Just got this from Microsoft as a proposed fix:
http://www.vindamedia.com/windows/help/windows-installer-msi-hash-mismatch
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development
Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: John Cooper
Sent: Tuesday, September 9, 2014 12:40 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the
default key container
I figure it was a minor upgrade with the ProductCodes.
There was some expression of interest in a registry dump on my reproducing
machine for HKCR\Msi.Package. So, here it is:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Msi.Package]
@=Windows Installer Package
InfoTip=prop:System.ItemType;System.Author;System.Title;System.Subject;System.Comment;System.DateModified;System.Size
EditFlags=hex:00,00,10,00
FullDetails=prop:System.PropGroup.Description;System.Title;System.Subject;System.Category;System.Keywords;System.Comment;System.PropGroup.Origin;System.Author;System.Document.RevisionNumber;System.Document.DateCreated;System.ApplicationName;System.PropGroup.FileSystem;System.ItemNameDisplay;System.ItemType;System.ItemFolderPathDisplay;System.DateCreated;System.DateModified;System.Size;System.FileAttributes;System.OfflineAvailability;System.OfflineStatus;System.SharedWith;System.FileOwner;System.ComputerName
FriendlyTypeName=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,\
00,6f,00,6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,\
32,00,5c,00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,\
00,2d,00,33,00,34,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\DefaultIcon]
@=C:\\Windows\\System32\\msiexec.exe,0
[HKEY_CLASSES_ROOT\Msi.Package\shell]
@=Open,Repair,Uninstall
[HKEY_CLASSES_ROOT\Msi.Package\shell\edit]
@=Edit with Orca
[HKEY_CLASSES_ROOT\Msi.Package\shell\edit\command]
@=\C:\\Program Files (x86)\\Orca\\Orca.exe\ \%1\
command=hex(7):36,00,59,00,55,00,27,00,53,00,72,00,2d,00,54,00,35,00,40,00,\
45,00,40,00,35,00,4c,00,28,00,28,00,2e,00,6d,00,4a,00,55,00,4f,00,72,00,63,\
00,61,00,3e,00,6e,00,52,00,37,00,39,00,66,00,5e,00,26,00,71,00,66,00,28,00,\
76,00,3f,00,65,00,71,00,46,00,28,00,29,00,77,00,26,00,47,00,20,00,22,00,25,\
00,31,00,22,00,00,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Open]
@=Install
MUIVerb=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,\
6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,\
00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,\
33,00,36,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Open\command]
@=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\
73,00,69,00,65,00,78,00,65,00,63,00,2e,00,65,00,78,00,65,00,22,00,20,00,2f,\
00,69,00,20,00,22,00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Repair]
@=Repair
MUIVerb=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,\
6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,\
00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,\
33,00,37,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Repair\command]
@=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\
73,00,69,00,65,00,78,00,65,00,63,00,2e,00,65,00,78,00,65,00,22,00,20,00,2f,\
00,66,00,20,00,22,00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\runasuser]
@=@shell32.dll,-50944
SuppressionPolicyEx={F211AA05-D4DF-4370-A2A0-9F19C09756A7}
Extended=
[HKEY_CLASSES_ROOT\Msi.Package\shell\runasuser\command]
DelegateExecute={ea72d00e-4960-42fa-ba92-7792a7944c1d}
[HKEY_CLASSES_ROOT\Msi.Package\shell\Uninstall]
@=Uninstall
MUIVerb=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,\
6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,\
00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,\
33,00,38,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Uninstall\command]
@=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\
73,00,69,00,65,00,78,00,65,00,63,00,2e,00,65,00,78,00,65,00,22,00,20,00,2f,\
00,78,00,20,00,22,00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shellex]
[HKEY_CLASSES_ROOT\Msi.Package\shellex\ContextMenuHandlers]
@=Compatibility
[HKEY_CLASSES_ROOT\Msi.Package\shellex\ContextMenuHandlers\Compatibility]
@={1d27f844-3a1f-4410-85ac-14651078412d}
[HKEY_CLASSES_ROOT\Msi.Package\shellex\PropertySheetHandlers]
Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container
Microsoft forum, I should say.
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development
Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: John Cooper
Sent: Tuesday, September 9, 2014 3:14 PM
To: 'General discussion about the WiX toolset.'
Subject: RE: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the
default key container
Just got this from Microsoft as a proposed fix:
http://www.vindamedia.com/windows/help/windows-installer-msi-hash-mismatch
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: John Cooper
Sent: Tuesday, September 9, 2014 12:40 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the
default key container
I figure it was a minor upgrade with the ProductCodes.
There was some expression of interest in a registry dump on my reproducing
machine for HKCR\Msi.Package. So, here it is:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Msi.Package]
@=Windows Installer Package
InfoTip=prop:System.ItemType;System.Author;System.Title;System.Subject;System.Comment;System.DateModified;System.Size
EditFlags=hex:00,00,10,00
FullDetails=prop:System.PropGroup.Description;System.Title;System.Subject;System.Category;System.Keywords;System.Comment;System.PropGroup.Origin;System.Author;System.Document.RevisionNumber;System.Document.DateCreated;System.ApplicationName;System.PropGroup.FileSystem;System.ItemNameDisplay;System.ItemType;System.ItemFolderPathDisplay;System.DateCreated;System.DateModified;System.Size;System.FileAttributes;System.OfflineAvailability;System.OfflineStatus;System.SharedWith;System.FileOwner;System.ComputerName
FriendlyTypeName=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,\
00,6f,00,6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,\
32,00,5c,00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,\
00,2d,00,33,00,34,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\DefaultIcon]
@=C:\\Windows\\System32\\msiexec.exe,0
[HKEY_CLASSES_ROOT\Msi.Package\shell]
@=Open,Repair,Uninstall
[HKEY_CLASSES_ROOT\Msi.Package\shell\edit]
@=Edit with Orca
[HKEY_CLASSES_ROOT\Msi.Package\shell\edit\command]
@=\C:\\Program Files (x86)\\Orca\\Orca.exe\ \%1\
command=hex(7):36,00,59,00,55,00,27,00,53,00,72,00,2d,00,54,00,35,00,40,00,\
45,00,40,00,35,00,4c,00,28,00,28,00,2e,00,6d,00,4a,00,55,00,4f,00,72,00,63,\
00,61,00,3e,00,6e,00,52,00,37,00,39,00,66,00,5e,00,26,00,71,00,66,00,28,00,\
76,00,3f,00,65,00,71,00,46,00,28,00,29,00,77,00,26,00,47,00,20,00,22,00,25,\
00,31,00,22,00,00,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Open]
@=Install
MUIVerb=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,\
6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,\
00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,\
33,00,36,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Open\command]
@=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\
73,00,69,00,65,00,78,00,65,00,63,00,2e,00,65,00,78,00,65,00,22,00,20,00,2f,\
00,69,00,20,00,22,00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Repair]
@=Repair
MUIVerb=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,\
6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,\
00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,\
33,00,37,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Repair\command]
@=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\
73,00,69,00,65,00,78,00,65,00,63,00,2e,00,65,00,78,00,65,00,22,00,20,00,2f,\
00,66,00,20,00,22,00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\runasuser]
@=@shell32.dll,-50944
SuppressionPolicyEx={F211AA05-D4DF-4370-A2A0-9F19C09756A7}
Extended=
[HKEY_CLASSES_ROOT\Msi.Package\shell\runasuser\command]
DelegateExecute={ea72d00e-4960-42fa-ba92-7792a7944c1d}
[HKEY_CLASSES_ROOT\Msi.Package\shell\Uninstall]
@=Uninstall
MUIVerb=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,\
6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,\
00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,\
33,00,38,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Uninstall\command]
@=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container
Looking at the link, it would address the case where something was wrong with
HKCR/Msi or HKCR/Msi.Package, but the repro I had on Window 8 appears to have
the correct entries here.
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development
Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: John Cooper
Sent: Tuesday, September 9, 2014 3:16 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the
default key container
Microsoft forum, I should say.
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: John Cooper
Sent: Tuesday, September 9, 2014 3:14 PM
To: 'General discussion about the WiX toolset.'
Subject: RE: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the
default key container
Just got this from Microsoft as a proposed fix:
http://www.vindamedia.com/windows/help/windows-installer-msi-hash-mismatch
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: John Cooper
Sent: Tuesday, September 9, 2014 12:40 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the
default key container
I figure it was a minor upgrade with the ProductCodes.
There was some expression of interest in a registry dump on my reproducing
machine for HKCR\Msi.Package. So, here it is:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Msi.Package]
@=Windows Installer Package
InfoTip=prop:System.ItemType;System.Author;System.Title;System.Subject;System.Comment;System.DateModified;System.Size
EditFlags=hex:00,00,10,00
FullDetails=prop:System.PropGroup.Description;System.Title;System.Subject;System.Category;System.Keywords;System.Comment;System.PropGroup.Origin;System.Author;System.Document.RevisionNumber;System.Document.DateCreated;System.ApplicationName;System.PropGroup.FileSystem;System.ItemNameDisplay;System.ItemType;System.ItemFolderPathDisplay;System.DateCreated;System.DateModified;System.Size;System.FileAttributes;System.OfflineAvailability;System.OfflineStatus;System.SharedWith;System.FileOwner;System.ComputerName
FriendlyTypeName=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,\
00,6f,00,6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,\
32,00,5c,00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,\
00,2d,00,33,00,34,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\DefaultIcon]
@=C:\\Windows\\System32\\msiexec.exe,0
[HKEY_CLASSES_ROOT\Msi.Package\shell]
@=Open,Repair,Uninstall
[HKEY_CLASSES_ROOT\Msi.Package\shell\edit]
@=Edit with Orca
[HKEY_CLASSES_ROOT\Msi.Package\shell\edit\command]
@=\C:\\Program Files (x86)\\Orca\\Orca.exe\ \%1\
command=hex(7):36,00,59,00,55,00,27,00,53,00,72,00,2d,00,54,00,35,00,40,00,\
45,00,40,00,35,00,4c,00,28,00,28,00,2e,00,6d,00,4a,00,55,00,4f,00,72,00,63,\
00,61,00,3e,00,6e,00,52,00,37,00,39,00,66,00,5e,00,26,00,71,00,66,00,28,00,\
76,00,3f,00,65,00,71,00,46,00,28,00,29,00,77,00,26,00,47,00,20,00,22,00,25,\
00,31,00,22,00,00,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Open]
@=Install
MUIVerb=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,\
6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,\
00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,\
33,00,36,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Open\command]
@=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\
73,00,69,00,65,00,78,00,65,00,63,00,2e,00,65,00,78,00,65,00,22,00,20,00,2f,\
00,69,00,20,00,22,00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Repair]
@=Repair
MUIVerb=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,\
6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,\
00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,\
33,00,37,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\Repair\command]
@=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\
73,00,69,00,65,00,78,00,65,00,63,00,2e,00,65,00,78,00,65,00,22,00,20,00,2f,\
00,66,00,20,00,22,00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00
[HKEY_CLASSES_ROOT\Msi.Package\shell\runasuser]
@=@shell32.dll,-50944
SuppressionPolicyEx={F211AA05-D4DF-4370-A2A0-9F19C09756A7}
Extended=
Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container
I noticed that your reproduction was only slightly similar to one of the ones from earlier in the thread. The one earlier was an overlapped I/O, yours is a hash being different. Also, didn't some report problems with Windows 7, and your testing is on 8? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: September-09-14 4:23 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container Looking at the link, it would address the case where something was wrong with HKCR/Msi or HKCR/Msi.Package, but the repro I had on Window 8 appears to have the correct entries here. -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: John Cooper Sent: Tuesday, September 9, 2014 3:16 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container Microsoft forum, I should say. -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: John Cooper Sent: Tuesday, September 9, 2014 3:14 PM To: 'General discussion about the WiX toolset.' Subject: RE: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container Just got this from Microsoft as a proposed fix: http://www.vindamedia.com/windows/help/windows-installer-msi-hash-mismatch -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: John Cooper Sent: Tuesday, September 9, 2014 12:40 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I figure it was a minor upgrade with the ProductCodes. There was some expression of interest in a registry dump on my reproducing machine for HKCR\Msi.Package. So, here it is: Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Msi.Package] @=Windows Installer Package InfoTip=prop:System.ItemType;System.Author;System.Title;System.Subject;System.Comment;System.DateModified;System.Size EditFlags=hex:00,00,10,00 FullDetails=prop:System.PropGroup.Description;System.Title;System.Subject;System.Category;System.Keywords;System.Comment;System.PropGroup.Origin;System.Author;System.Document.RevisionNumber;System.Document.DateCreated;System.ApplicationName;System.PropGroup.FileSystem;System.ItemNameDisplay;System.ItemType;System.ItemFolderPathDisplay;System.DateCreated;System.DateModified;System.Size;System.FileAttributes;System.OfflineAvailability;System.OfflineStatus;System.SharedWith;System.FileOwner;System.ComputerName FriendlyTypeName=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,\ 00,6f,00,6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,\ 32,00,5c,00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,\ 00,2d,00,33,00,34,00,00,00 [HKEY_CLASSES_ROOT\Msi.Package\DefaultIcon] @=C:\\Windows\\System32\\msiexec.exe,0 [HKEY_CLASSES_ROOT\Msi.Package\shell] @=Open,Repair,Uninstall [HKEY_CLASSES_ROOT\Msi.Package\shell\edit] @=Edit with Orca [HKEY_CLASSES_ROOT\Msi.Package\shell\edit\command] @=\C:\\Program Files (x86)\\Orca\\Orca.exe\ \%1\ command=hex(7):36,00,59,00,55,00,27,00,53,00,72,00,2d,00,54,00,35,00,40,00,\ 45,00,40,00,35,00,4c,00,28,00,28,00,2e,00,6d,00,4a,00,55,00,4f,00,72,00,63,\ 00,61,00,3e,00,6e,00,52,00,37,00,39,00,66,00,5e,00,26,00,71,00,66,00,28,00,\ 76,00,3f,00,65,00,71,00,46,00,28,00,29,00,77,00,26,00,47,00,20,00,22,00,25,\ 00,31,00,22,00,00,00,00,00 [HKEY_CLASSES_ROOT\Msi.Package\shell\Open] @=Install MUIVerb=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,\ 6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,\ 00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,00,2d,00,\ 33,00,36,00,00,00 [HKEY_CLASSES_ROOT\Msi.Package\shell\Open\command] @=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\ 00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\ 73,00,69,00,65,00,78,00,65,00,63,00,2e,00,65,00,78,00,65,00,22,00,20,00,2f,\ 00,69,00,20,00,22,00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00
Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container
That is true. Haven't gotten it to reproduce on any of our 7 Enterprise machines. Did get the Windows 8 to reproduce. No luck on Server 2008 R2 or Server 2012. The Lyve installer was doing a minor upgrade with a non-standard REINSTALLMODE, but that shouldn't have created the problem I repo'ed. Mine was specific to the hash as you've said. -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: Tuesday, September 9, 2014 3:42 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I noticed that your reproduction was only slightly similar to one of the ones from earlier in the thread. The one earlier was an overlapped I/O, yours is a hash being different. Also, didn't some report problems with Windows 7, and your testing is on 8? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: September-09-14 4:23 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container Looking at the link, it would address the case where something was wrong with HKCR/Msi or HKCR/Msi.Package, but the repro I had on Window 8 appears to have the correct entries here. -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: John Cooper Sent: Tuesday, September 9, 2014 3:16 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container Microsoft forum, I should say. -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: John Cooper Sent: Tuesday, September 9, 2014 3:14 PM To: 'General discussion about the WiX toolset.' Subject: RE: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container Just got this from Microsoft as a proposed fix: http://www.vindamedia.com/windows/help/windows-installer-msi-hash-mismatch -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: John Cooper Sent: Tuesday, September 9, 2014 12:40 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I figure it was a minor upgrade with the ProductCodes. There was some expression of interest in a registry dump on my reproducing machine for HKCR\Msi.Package. So, here it is: Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Msi.Package] @=Windows Installer Package InfoTip=prop:System.ItemType;System.Author;System.Title;System.Subject;System.Comment;System.DateModified;System.Size EditFlags=hex:00,00,10,00 FullDetails=prop:System.PropGroup.Description;System.Title;System.Subject;System.Category;System.Keywords;System.Comment;System.PropGroup.Origin;System.Author;System.Document.RevisionNumber;System.Document.DateCreated;System.ApplicationName;System.PropGroup.FileSystem;System.ItemNameDisplay;System.ItemType;System.ItemFolderPathDisplay;System.DateCreated;System.DateModified;System.Size;System.FileAttributes;System.OfflineAvailability;System.OfflineStatus;System.SharedWith;System.FileOwner;System.ComputerName FriendlyTypeName=hex(2):40,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,\ 00,6f,00,6f,00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,\ 32,00,5c,00,6d,00,73,00,69,00,6d,00,73,00,67,00,2e,00,64,00,6c,00,6c,00,2c,\ 00,2d,00,33,00,34,00,00,00 [HKEY_CLASSES_ROOT\Msi.Package\DefaultIcon] @=C:\\Windows\\System32\\msiexec.exe,0 [HKEY_CLASSES_ROOT\Msi.Package\shell] @=Open,Repair,Uninstall [HKEY_CLASSES_ROOT\Msi.Package\shell\edit] @=Edit with Orca [HKEY_CLASSES_ROOT\Msi.Package\shell\edit\command] @=\C:\\Program Files (x86)\\Orca\\Orca.exe\ \%1\ command=hex(7):36,00,59,00,55,00,27,00,53,00,72,00,2d,00,54,00,35,00,40,00,\ 45,00,40,00,35,00,4c,00,28,00,28,00,2e,00,6d,00,4a,00,55,00,4f,00,72,00,63,\
Re: [WiX-users] PIDTemplate w/ MaskedEdit
Okay I have another question about the masked edit field. If we have a PID that contains only letters and numbers then is there a maskededit setting that will ONLY allow this mix of characters or is this something that it can not handle and therefore other actions would have to be used to validate the entries? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PIDTemplate-w-MaskedEdit-tp4815087p7596737.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn FileSearch in 64 bit system folder
I am trying to write the detection logic for some VC redist packages (32 and 64 bit). The problem I am running into is being able to detect the assemblies under windows\system32 on a 64 bit OS. On a 64 bit OS, it appears that burn translates these as such: [SystemFolder] = C:\Windows\system32\ [System64Folder] = C:\Windows\SysWOW64\ However, since it's a 32 bit executable, both paths end up searching in the 32 bit location. I feel like I must be missing something really obvious, but I can't figure out how this should to be done. Thanks, -Dave -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Should the ActionResult from a rollback CA be ignored?
The result returned by a rollback CA can be Success or Failure. But should that response be ignored by the installer? If I check it, and it is a Failure, will that prevent the installer from rolling back? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Should-the-ActionResult-from-a-rollback-CA-be-ignored-tp7596740.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to pass data from deferred CA to rollback CA?
In a deferred custom action, I am changing some text in a file. I want to be able to undo those changes in a rollback custom action. So, I'm attempting to store the original contents of the file and then set the file back to that data in the rollback CA. The place where I've tried to store the original content is in CustomActionData for the rollback CA. I am attemting to set the CustomActionData from the deferred CA (in C# code, using DTF). However, when I try to set CustomActionData for the rollback CA from within the deferred CA, the values are not there when the rollback CA runs. I can also not set any WiX properties from within the deferred CA, or I get an error. Is there a way to pass data from a deferred CA to a rollback CA? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-pass-data-from-deferred-CA-to-rollback-CA-tp7596739.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn installer upgrade does not work
Hi, Do you mind posting the fix in the xml file? I have a problem doing a burn upgrade. Thanks! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-installer-upgrade-does-not-work-tp7589150p7596741.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstalling bundle with broken BA
2014-09-08 16:44 GMT-03:00 Hoover, Jacob jacob.hoo...@greenheck.com:
As for the borked bundle, I'm not certain if you can easily assign the bundle
Id, but that’s what I would try doing
(http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapper-UpgradeCode-td7578845.html).
I'm guessing you'd have to hack on WiX to get it to happen, but if you
could assign the same id as the original, you should be able to overwrite the
one in the cache and uninstall it.
I tried to change the bundle ID with a hex editor, but it turns out
the ID is also present in a compressed embedded XML, in
/BootstrapperApplicationData/WixBundleProperties/@Id, and I don't know
how to replace that. Hacking the WiX compiler to set the bundle ID
sounds like a tempting option, but I haven't yet managed to even
compile WiX.
It may just be easier to uninstall the packages your bundle installed
manually, then manually remove the bundle from the package cache and ARP.
...so I took this approach. Uninstalled the packages with msiexec,
then deleted the bundle and packages from the package cache, and
deleted the ARP entry and the registry keys related to dependency
providers (whatever that is) with my bundle ID.
--
Nicolás
-Original Message-
From: Sascha Sertel [mailto:sascha.ser...@gmail.com]
Sent: Monday, September 08, 2014 2:11 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Uninstalling bundle with broken BA
MsiZap will wipe out anything that is related to the product code. Run it
once and you will see the giant output of all the registry and file locations
it goes through.
As far as other bundle left-over go, you should be able to clear those out
yourself from paths like C:\Users\username\AppData\Local\Package Cache
C:\Users\username\AppData\Local\Temp
C:\Config,msi
Paths will be different on XP obviously, but you know what I mean. There are
also package cache locations under C:\Windows, you can see in the log file
where it's caching the package.
// Sascha
On Mon, Sep 8, 2014 at 11:55 AM, Nicolás Alvarez nicolas.alva...@gmail.com
wrote:
I can properly uninstall the MSIs via msiexec /x {GUID}. The problem
is removing the stuff left behind by Burn, such as the cached bundle
and packages. I doubt msizap knows anything about bootstrappers...
El lunes, 8 de septiembre de 2014, Sascha Sertel
sascha.ser...@gmail.com
escribió:
Let me introduce you to your new best friend: MsiZap
http://msdn.microsoft.com/en-us/library/aa370523(v=vs.85).aspx (
http://msdn.microsoft.com/en-us/library/aa370523(v=vs.85).aspx)
While I was doing custom BA development MsiZap helped me out of a
few botched installations where I was stuck in the same situation
and
couldn't
uninstall. As long as you have your product GUID MsiZap can clean up
everything left behind so you can start off fresh.
I usually call MsiZap like this:
MsiZap.exe T! {GUID}
Hope it helps!
// Sascha
On Sun, Sep 7, 2014 at 8:08 PM, Nicolás Alvarez
nicolas.alva...@gmail.com
javascript:;
wrote:
Hi,
I was experimenting with a custom BA, and I installed my bundle
with it. Now I can't uninstall it because my simplistic BA has no
way to plan uninstallation.
I can't just build a new bundle with the wixstdba because it would
have a new bundle ID, so it offers me to install again, not to
uninstall. If I go ahead and install it again with wixstdba, I get
two entries in ARP, and the old entry is still launching my custom
and broken BA.
What do I do now? :(
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Should the ActionResult from a rollback CA be ignored?
If you select to ignore by return=ignore but if you have return=check and your CA fails, the installation rolls back. The rollback though might not rollback your custom action's that have occurred before the CA that failed. --Pavan -Original Message- From: Nick Ramirez [mailto:nickra...@hotmail.com] Sent: Tuesday, September 09, 2014 4:44 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Should the ActionResult from a rollback CA be ignored? The result returned by a rollback CA can be Success or Failure. But should that response be ignored by the installer? If I check it, and it is a Failure, will that prevent the installer from rolling back? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Should-the-ActionResult-from-a-rollback-CA-be-ignored-tp7596740.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to pass data from deferred CA to rollback CA?
I wasn't able to find a way to pass data from a deferred CA to a rollback CA. Nor could I access the session's database, which prevented me from storing the data in a custom table. The only way I found that worked was to store the original file in the TEMP directory and, in the rollback, restore the original file back using the copy in TEMP. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-pass-data-from-deferred-CA-to-rollback-CA-tp7596739p7596744.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to pass data from deferred CA to rollback CA?
The correct way is to read the file from the immediate custom action and schedule the rollback and deferred actions with the appropriate data. The WiX custom actions do this all the time. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom action issue when msi is generated on Windows 8.1 and installed on Windows 8 or Windows 7
Hi Hoover, The reason why I’m using custom action and calling command prompt and not RemoveFolderEx is because I need to: Always delete the folder on uninstall (which will work with removeFolderEx) Delete conditionally on upgrade (i.e. I have modified the UI and provided a checkbox in InstallDirDlg providing the user an option to delete the data on upgrade). As far as I know RemoveFolderEx will work on install and uninstall but not for upgrade. Please correct me if I’m wrong. Thank you, Sharada Sent from Windows Mail From: Hoover, Jacob Sent: Tuesday, September 9, 2014 8:03 PM To: wix-users@lists.sourceforge.net Why reinvent the wheel? http://wixtoolset.org/documentation/manual/v3/xsd/util/removefolderex.html -Original Message- From: sharada boda [mailto:sharada.b...@outlook.com] Sent: Tuesday, September 09, 2014 6:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Custom action issue when msi is generated on Windows 8.1 and installed on Windows 8 or Windows 7 Hi, I'm calling a custom action on upgrade and delete of an application. The custom action essentially deletes certain folders (not part of the installation folder) using the command prompt. When the msi is generated on windows 7/ windows 8, and then launched either on windows 7/windows 8/windows 8.1 - the custom action works perfectly fine. But, when the msi is generated on windows 8.1 and launched on either windows 7 or windows 8 -- the folders are not being deleted. The same generated msi is working fine on other windows 8.1 systems. Please let me know how to address this issue. Regards, Sharpi. Sent from Windows Mail -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
