[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=157508191&iu=/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=157508191&iu=/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=157508191&iu=/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 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, 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 m
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 wrote:
> It doesn't replicate for me in the NOT install
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 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 662
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]
@="Re&pair"
"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:
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]
@="Re&pair"
"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.
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]
@="Re&pair"
"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
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]
@="Re&pair"
"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-D4
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,
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,0
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=157508191&iu=/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=157508191&iu=/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=157508191&iu=/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=157508191&iu=/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=157508191&iu=/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 :
> 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\\AppData\Local\Package Cache
> C:\Users\\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
> 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
>>
>> escribió:
>>
>> > Let me introduce you to your new best friend: MsiZap
>> > (
>> > 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! {}
>> >
>> > Hope it helps!
>> >
>> > // Sascha
>> >
>> >
>> >
>> > On Sun, Sep 7, 2014 at 8:08 PM, Nicolás Alvarez <
>> nicolas.alva...@gmail.com
>> > >
>> > 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=157508191&iu=/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=157508191&iu=/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=157508191&iu=/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=157508191&iu=/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=157508191&iu=/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=157508191&iu=/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=157508191&iu=/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=157508191&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn FileSearch in 64 bit system folder
Hi Dave, I have done this with a different Approach. I have used an Msi Product Check to Check for existing redist Packages. To make sure the 64Bit Versions are not installed set the 64Bit flag within burn. I search for product ids with Microsofts Old Manifest bootstrap Editor. Don't know if there is a better Way. In conclusion there is no Need to Access These directorys Directly. Chris Am 10.09.2014 um 01:20 schrieb "Dave Andersen" : 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=157508191&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users Wichtiger Hinweis: Diese E-Mail und etwa angehängte Dateien können vertrauliche Informationen enthalten und sind ausschließlich für den/die Adressaten bestimmt. Sollten Sie irrtümlich diese E-Mail erhalten haben, bitten wir Sie, uns darüber zu informieren und die E-Mail aus Ihrem System zu löschen. Das unerlaubte Kopieren und die unbefugte Weitergabe dieser Mail und ihrer Inhalte sind nicht gestattet. Important notice: This email and some of the attached files can contain confidential information and are intended solely for the addressee. Should you have received this email in error, we ask that you inform us about this and delete the email from your system. The illegal copying and unauthorised re-distribution of this email and its contents are not permitted. -- 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=157508191&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
