Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container
Ah! There seems to be some confusion on this point. I will see. 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: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] Sent: September-06-14 1:27 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container 2014-09-05 17:15 GMT-03:00 keith.doug...@statcan.gc.ca: I've gotten hold of a Windows 7 x64 VM and tried installing, uninstalling, repairing a few dinky products we have built installers for over the last while. Even added a new one with a large (100 megabytes uncompressed) payload. Tried with and without UAC for all. No troubles at all with the trouble KB installed. User was a domain account, for what that is worth. Well, previous messages indicate the problem is with minor updates. Did you try updates, or only install/uninstall/repair? -- Nicolás -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ 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
[WiX-users] Where to get the ClassicTheme.xml/wxl Bootstrapper files?
I am updating the WiX 3.8 to see the differences in the updated Bootstrapper and therefore I am looking at the following page: https://classicwixburntheme.codeplex.com/wikipage?title=Guide%201referringTitle=Documentation Just to follow the example it states to download 1033.zip and extract the ClassicTheme files. It just does not state where to get this 1033.zip file from. So where can I get this 1033.zip file, as well as any of the other language files that contain these ClassicTheme files? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Where-to-get-the-ClassicTheme-xml-wxl-Bootstrapper-files-tp7596697.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] SECREPAIR: CryptAcquireContext: Could not create the default key container
I've now tried a small update. I've never fully understood why you’d use these, but my co-workers wanted to use MSPs for some of our updating, so I built a front end for making those and hence small updates. That all to say that I may be doing something unusual or wrong with them. However, that disclaimer aside, I cannot reproduce any trouble with that either. 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: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: September-08-14 8:41 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container Ah! There seems to be some confusion on this point. I will see. 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: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] Sent: September-06-14 1:27 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container 2014-09-05 17:15 GMT-03:00 keith.doug...@statcan.gc.ca: I've gotten hold of a Windows 7 x64 VM and tried installing, uninstalling, repairing a few dinky products we have built installers for over the last while. Even added a new one with a large (100 megabytes uncompressed) payload. Tried with and without UAC for all. No troubles at all with the trouble KB installed. User was a domain account, for what that is worth. Well, previous messages indicate the problem is with minor updates. Did you try updates, or only install/uninstall/repair? -- Nicolás -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ 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
Re: [WiX-users] Burn built-in variables question
Sorry, Rob but I am still at a loss here as how what I would need to update to be able to get the values of these environment variables into the WiX burn bootstrapper that then get passed to my .msi installer. Again I am not up to date with programming skills and therefore having to update code is not as easy a task for me then it is for others to do.. So again any help that would make it easier for me to accomplish this would be great. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-built-in-variables-question-tp7596676p7596699.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] Where to get the ClassicTheme.xml/wxl Bootstrapper files?
That's an independent project. You might ask them on their discussion board: https://classicwixburntheme.codeplex.com/discussions ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: TimM [mailto:timmay...@smarttech.com] Sent: Monday, September 8, 2014 7:27 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Where to get the ClassicTheme.xml/wxl Bootstrapper files? I am updating the WiX 3.8 to see the differences in the updated Bootstrapper and therefore I am looking at the following page: https://classicwixburntheme.codeplex.com/wikipage?title=Guide%201referringTitle=Documentation Just to follow the example it states to download 1033.zip and extract the ClassicTheme files. It just does not state where to get this 1033.zip file from. So where can I get this 1033.zip file, as well as any of the other language files that contain these ClassicTheme files? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Where-to-get-the-ClassicTheme-xml-wxl-Bootstrapper-files-tp7596697.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] Burn Bootstrapper run executable on exit
Okay so it is not as easy as adding a new control to the Success Page in the theme because as stated I did that and it shows no problem, but have basically no control over this and it's execution. So the actions that were on the Launch button has to be switched actions that get triggered only if this checkbox is checked as well as the Finish button would have to be enabled to call this custom action and then exit the install. So does this mean that if I want this checkbox and Finish button to actually do anything then I have to create a custom BootstrapperApplication so that I can interact with this checkbox and button? I was hoping that it was simply adding a check box and then updating the custom action trigger to only be triggered if the checkbox was checked... So if I am missing some steps to where I do NOT need to create a special custom made BootstrapperApplication then I would really like to know what I have to do. If I have to create a custom BootstrapperApplication then where is the code that I can would have to try and understand and figure out what would have to change so that if the checkbox is checked that it would launch the app and exist the install at the end? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Bootstrapper-run-executable-on-exit-tp7580830p7596700.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 built-in variables question
Neither Burn nor wixstdba read environment variables so you'd need to write code to do that. In WiX v3.8 you could maybe write a BA function (though I've never tried that myself). Although if you're just going to pass it to the MSI, why not have the MSI get the variable. Windows Installer reads environment variables. _ 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] SECREPAIR: CryptAcquireContext: Could not create the default key container
I haven't been able to reproduce this using signed or unsigned MSIs deploying in an Open or Closed Environment. I would be very happy to take a look at some verbose logs of the failures. -- 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 10:40 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I've now tried a small update. I've never fully understood why you’d use these, but my co-workers wanted to use MSPs for some of our updating, so I built a front end for making those and hence small updates. That all to say that I may be doing something unusual or wrong with them. However, that disclaimer aside, I cannot reproduce any trouble with that either. 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: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: September-08-14 8:41 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container Ah! There seems to be some confusion on this point. I will see. 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: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] Sent: September-06-14 1:27 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container 2014-09-05 17:15 GMT-03:00 keith.doug...@statcan.gc.ca: I've gotten hold of a Windows 7 x64 VM and tried installing, uninstalling, repairing a few dinky products we have built installers for over the last while. Even added a new one with a large (100 megabytes uncompressed) payload. Tried with and without UAC for all. No troubles at all with the trouble KB installed. User was a domain account, for what that is worth. Well, previous messages indicate the problem is with minor updates. Did you try updates, or only install/uninstall/repair? -- Nicolás -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: [WiX-users] Where to get the ClassicTheme.xml/wxl Bootstrapper files?
Thanks Rob, I'll do that. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Where-to-get-the-ClassicTheme-xml-wxl-Bootstrapper-files-tp7596697p7596704.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 built-in variables question
Yes I already do this, but I was trying to get the value so that it could be appended to a property that gets passed to the main installer. Since what gets passed to the install will override what defaults gets set in main install those and therefore you lose the entries. I'll figure something out that involves the least amount of extra work on my side.. Thanks. From: Rob Mensching-7 [via Windows Installer XML (WiX) toolset] [mailto:ml-node+s687559n7596702...@n2.nabble.com] Sent: Monday, September 08, 2014 10:24 AM To: Tim Mayert Subject: Re: Burn built-in variables question Neither Burn nor wixstdba read environment variables so you'd need to write code to do that. In WiX v3.8 you could maybe write a BA function (though I've never tried that myself). Although if you're just going to pass it to the MSI, why not have the MSI get the variable. Windows Installer reads environment variables. _ 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 [hidden email]/user/SendEmail.jtp?type=nodenode=7596702i=0 https://lists.sourceforge.net/lists/listinfo/wix-users If you reply to this email, your message will be added to the discussion below: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-built-in-variables-question-tp7596676p7596702.html To unsubscribe from Burn built-in variables question, click herehttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=7596676code=VGltTWF5ZXJ0QHNtYXJ0dGVjaC5jb218NzU5NjY3NnwtMTcxMzc3MTUwNA==. NAMLhttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-built-in-variables-question-tp7596676p7596705.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] SECREPAIR: CryptAcquireContext: Could not create the default key container
The issue is very easily reproducible for me when doing an upgrade from one bundle to another one. I emailed Keith links to two installers that have 100% repro for me when upgrading from the one to the other while having KB2918614 installed. Repros on any machine. I'm happy to share some logs but given that KB2918614 directly determines whether the upgrade fails or works I don't know if there is anything that can be done to fix this from our end, it seems to me like Microsoft needs to reissue the hotfix or have another hotfix that fixes the broken one. // Sascha On Mon, Sep 8, 2014 at 9:44 AM, John Cooper jocoo...@jackhenry.com wrote: I haven't been able to reproduce this using signed or unsigned MSIs deploying in an Open or Closed Environment. I would be very happy to take a look at some verbose logs of the failures. -- 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 10:40 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I've now tried a small update. I've never fully understood why you’d use these, but my co-workers wanted to use MSPs for some of our updating, so I built a front end for making those and hence small updates. That all to say that I may be doing something unusual or wrong with them. However, that disclaimer aside, I cannot reproduce any trouble with that either. 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: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: September-08-14 8:41 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container Ah! There seems to be some confusion on this point. I will see. 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: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] Sent: September-06-14 1:27 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container 2014-09-05 17:15 GMT-03:00 keith.doug...@statcan.gc.ca: I've gotten hold of a Windows 7 x64 VM and tried installing, uninstalling, repairing a few dinky products we have built installers for over the last while. Even added a new one with a large (100 megabytes uncompressed) payload. Tried with and without UAC for all. No troubles at all with the trouble KB installed. User was a domain account, for what that is worth. Well, previous messages indicate the problem is with minor updates. Did you try updates, or only install/uninstall/repair? -- Nicolás -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential
Re: [WiX-users] Uninstalling bundle with broken BA
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
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? :(
--
Nicolás
--
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
I am sure that Microsoft will ultimately have to make a fix, but I have a lot of installers out in the wild, and I feel very exposed when none of my testers can replicate. I'm much more interested in understanding the mechanism of failure--especially since I can't currently replicate. Also, it is very hard to justify to management invoking our support agreement when the issue does not reproduce with any of our product installers. Much easier if I can replicate. I'm basically trying to figure out what is different in our installers and deployment scenarios such that we don't see this issue. -- 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 1:29 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container The issue is very easily reproducible for me when doing an upgrade from one bundle to another one. I emailed Keith links to two installers that have 100% repro for me when upgrading from the one to the other while having KB2918614 installed. Repros on any machine. I'm happy to share some logs but given that KB2918614 directly determines whether the upgrade fails or works I don't know if there is anything that can be done to fix this from our end, it seems to me like Microsoft needs to reissue the hotfix or have another hotfix that fixes the broken one. // Sascha On Mon, Sep 8, 2014 at 9:44 AM, John Cooper jocoo...@jackhenry.com wrote: I haven't been able to reproduce this using signed or unsigned MSIs deploying in an Open or Closed Environment. I would be very happy to take a look at some verbose logs of the failures. -- 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 10:40 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I've now tried a small update. I've never fully understood why you’d use these, but my co-workers wanted to use MSPs for some of our updating, so I built a front end for making those and hence small updates. That all to say that I may be doing something unusual or wrong with them. However, that disclaimer aside, I cannot reproduce any trouble with that either. 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: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: September-08-14 8:41 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container Ah! There seems to be some confusion on this point. I will see. 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: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] Sent: September-06-14 1:27 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container 2014-09-05 17:15 GMT-03:00 keith.doug...@statcan.gc.ca: I've gotten hold of a Windows 7 x64 VM and tried installing, uninstalling, repairing a few dinky products we have built installers for over the last while. Even added a new one with a large (100 megabytes uncompressed) payload. Tried with and without UAC for all. No troubles at all with the trouble KB installed. User was a domain account, for what that is worth. Well, previous messages indicate the problem is with minor updates. Did you try updates, or only install/uninstall/repair? -- Nicolás -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ 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
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 of the hypotheses around are wrong, unless we're just unlucky. Sascha: I have yet to try your stuff out. I know already now that you are dealing with MSIs in a bundle (correct?), which we don't do - we use bundles to use Windows Update files (MSUs) only, at present. All the rest of our stuff is just MSI. (Or rarely - testing only, I think, MSP.) So there's a difference right off. I wonder (list owners willing) if it is time to play what do we know? 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 2:41 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I am sure that Microsoft will ultimately have to make a fix, but I have a lot of installers out in the wild, and I feel very exposed when none of my testers can replicate. I'm much more interested in understanding the mechanism of failure--especially since I can't currently replicate. Also, it is very hard to justify to management invoking our support agreement when the issue does not reproduce with any of our product installers. Much easier if I can replicate. I'm basically trying to figure out what is different in our installers and deployment scenarios such that we don't see this issue. -- 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 1:29 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container The issue is very easily reproducible for me when doing an upgrade from one bundle to another one. I emailed Keith links to two installers that have 100% repro for me when upgrading from the one to the other while having KB2918614 installed. Repros on any machine. I'm happy to share some logs but given that KB2918614 directly determines whether the upgrade fails or works I don't know if there is anything that can be done to fix this from our end, it seems to me like Microsoft needs to reissue the hotfix or have another hotfix that fixes the broken one. // Sascha On Mon, Sep 8, 2014 at 9:44 AM, John Cooper jocoo...@jackhenry.com wrote: I haven't been able to reproduce this using signed or unsigned MSIs deploying in an Open or Closed Environment. I would be very happy to take a look at some verbose logs of the failures. -- 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 10:40 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I've now tried a small update. I've never fully understood why you’d use these, but my co-workers wanted to use MSPs for some of our updating, so I built a front end for making those and hence small updates. That all to say that I may be doing something unusual or wrong with them. However, that disclaimer aside, I cannot reproduce any trouble with that either. 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: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: September-08-14 8:41 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container Ah! There seems to be some confusion on this point. I will see. 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
Re: [WiX-users] Uninstalling bundle with broken BA
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? :(
--
Nicolás
--
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 javascript:;
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 javascript:;
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Nicolás
--
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
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 of the hypotheses around are wrong, unless we're just unlucky. Sascha: I have yet to try your stuff out. I know already now that you are dealing with MSIs in a bundle (correct?), which we don't do - we use bundles to use Windows Update files (MSUs) only, at present. All the rest of our stuff is just MSI. (Or rarely - testing only, I think, MSP.) So there's a difference right off. I wonder (list owners willing) if it is time to play what do we know? 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 2:41 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I am sure that Microsoft will ultimately have to make a fix, but I have a lot of installers out in the wild, and I feel very exposed when none of my testers can replicate. I'm much more interested in understanding the mechanism of failure--especially since I can't currently replicate. Also, it is very hard to justify to management invoking our support agreement when the issue does not reproduce with any of our product installers. Much easier if I can replicate. I'm basically trying to figure out what is different in our installers and deployment scenarios such that we don't see this issue. -- 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 1:29 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container The issue is very easily reproducible for me when doing an upgrade from one bundle to another one. I emailed Keith links to two installers that have 100% repro for me when upgrading from the one to the other while having KB2918614 installed. Repros on any machine. I'm happy to share some logs but given that KB2918614 directly determines whether the upgrade fails or works I don't know if there is anything that can be done to fix this from our end, it seems to me like Microsoft needs to reissue the hotfix or have another hotfix that fixes the broken one. // Sascha On Mon, Sep 8, 2014 at 9:44 AM, John Cooper jocoo...@jackhenry.com wrote: I haven't been able to reproduce this using signed or unsigned MSIs deploying in an Open or Closed Environment. I would be very happy to take a look at some verbose logs of the failures. -- 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 10:40 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I've now tried a small update. I've never fully understood why you’d use these, but my co-workers wanted to use MSPs for some of our updating, so I built a front end for making those and hence small updates. That all to say that I may be doing something unusual or wrong with them. However, that disclaimer aside, I cannot reproduce any trouble with that either. Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
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? :(
--
Nicolás
--
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 javascript:;
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 javascript:;
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Nicolás
--
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
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 of the hypotheses around are wrong, unless we're just unlucky. Sascha: I have yet to try your stuff out. I know already now that you are dealing with MSIs in a bundle (correct?), which we don't do - we use bundles to use Windows Update files (MSUs) only, at present. All the rest of our stuff is just MSI. (Or rarely - testing only, I think, MSP.) So there's a difference right off. I wonder (list owners willing) if it is time to play what do we know? 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 2:41 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I am sure that Microsoft will ultimately have to make a fix, but I have a lot of installers out in the wild, and I feel very exposed when none of my testers can replicate. I'm much more interested in understanding the mechanism of failure--especially since I can't currently replicate. Also, it is very hard to justify to management invoking our support agreement when the issue does not reproduce with any of our product installers. Much easier if I can replicate. I'm basically trying to figure out what is different in our installers and deployment scenarios such that we don't see this issue. -- 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 1:29 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container The issue is very easily reproducible for me when doing an upgrade from one bundle to another one. I emailed Keith links to two installers that have 100% repro for me when upgrading from the one to the other while having KB2918614 installed. Repros on any machine. I'm happy to share some logs but given that KB2918614 directly determines whether the upgrade fails or works I don't know if there is anything that can be done to fix this from our end, it seems to me like Microsoft needs to reissue the hotfix or have another hotfix that fixes the broken one. // Sascha On Mon, Sep 8, 2014 at 9:44 AM, John Cooper jocoo...@jackhenry.com wrote: I haven't been able to reproduce this using signed or unsigned MSIs deploying in an Open or Closed Environment. I would be very happy to take a look at some verbose logs of the failures. -- 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-
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 of the hypotheses around are wrong, unless we're just unlucky. Sascha: I have yet to try your stuff out. I know already now that you are dealing with MSIs in a bundle (correct?), which we don't do - we use bundles to use Windows Update files (MSUs) only, at present. All the rest of our stuff is just MSI. (Or rarely - testing only, I think, MSP.) So there's a difference right off. I wonder (list owners willing) if it is time to play what do we know? 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 2:41 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I am sure that Microsoft will ultimately have to make a fix, but I have a lot of installers out in the wild, and I feel very exposed when none of my testers can replicate. I'm much more interested in understanding the mechanism of failure--especially since I can't currently replicate. Also, it is very hard to justify to management invoking our support agreement when the issue does not reproduce with any of our product installers. Much easier if I can replicate. I'm basically trying to figure out what is different in our installers and deployment scenarios such that we don't see this issue. -- 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 1:29 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container The issue is very easily reproducible for me when doing an upgrade from one bundle to another one. I emailed Keith links to two installers that have 100% repro for me when upgrading from the one to the other while having KB2918614 installed. Repros on any machine. I'm happy to share some logs but given that KB2918614 directly determines whether the
Re: [WiX-users] Uninstalling bundle with broken BA
MsiZap is evil.. DON'T use it. If you did have a borked MSI, fix the MSI and
then use Orca to match the needed ID's. From there you can recache the fixed
MSI and do a proper uninstall.
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.
It may just be easier to uninstall the packages your bundle installed manually,
then manually remove the bundle from the package cache and ARP.
-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? :(
--
Nicolás
--
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 javascript:;
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 javascript:;
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Nicolás
--
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
Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container
In a successful upgrade AgentLib.Interop.dll gets replaced if there was a newer version (which is the case going from 396 to 1079), looks like MSI doesn't pay much attention to the version but looks at file properties like size and hash code instead. I should fix the version on this, I remember having seen this in the past but forgot to fix it since it wasn't causing any issues then. The two CefSharp dlls don't get replaced because they didn't change. Those come from a third party NuGet package, so I don't control the versioning of those files and will have to live without a version number on them. // Sascha On Mon, Sep 8, 2014 at 12:17 PM, John Cooper jocoo...@jackhenry.com wrote: 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 of the hypotheses around are wrong, unless we're just unlucky. Sascha: I have yet to try your stuff out. I know already now that you are dealing with MSIs in a bundle (correct?), which we don't do - we use bundles to use Windows Update files (MSUs) only, at present. All the rest of our stuff is just MSI. (Or rarely - testing only, I think, MSP.) So there's a difference right off. I wonder (list owners willing) if it is time to play what do we know? 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 2:41 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I am sure that Microsoft will ultimately have to make a fix, but I have a lot of installers out in the wild, and I feel very exposed when none of my testers can replicate. I'm much more interested in understanding the mechanism of failure--especially since I can't currently replicate. Also, it is very hard to justify to management invoking our support agreement when the issue does not reproduce with any of our product installers. Much easier if I can replicate. I'm basically trying to figure out what is different in our installers and deployment scenarios such that we don't see this issue. -- 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 1:29 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container The issue is very easily reproducible for me when doing an upgrade from one bundle to another one. I emailed Keith links to two installers that have 100% repro for me when upgrading from the one to the other while having KB2918614 installed. Repros on any machine. I'm happy to share some logs but given that KB2918614 directly determines whether the
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 of the hypotheses around are wrong, unless we're just unlucky. Sascha: I have yet to try your stuff out. I know already now that you are dealing with MSIs in a bundle (correct?), which we don't do - we use bundles to use Windows Update files (MSUs) only, at present. All the rest of our stuff is just MSI. (Or rarely - testing only, I think, MSP.) So there's a difference right off. I wonder (list owners willing) if it is time to play what do we know? 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 2:41 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container I am sure that Microsoft will ultimately have to make a fix, but I have a lot of installers out in the wild, and I feel very exposed when none of my testers can replicate. I'm much more interested in understanding the mechanism of failure--especially since I can't currently replicate. Also, it is very hard to justify to management invoking our support agreement when the issue does not reproduce with any of our product installers. Much easier if I can replicate. I'm basically trying to figure out what is different in our
Re: [WiX-users] Burn Bootstrapper run executable on exit
Oh and one more thing about customizing the burn bootstrapper theme files. I figured that if it was too much work to simply add a checkbox on the success screen and have it set to launch the app on finish, I figured that maybe just add a text control at the bottom that then informs the user what the Launch button will do and therefore they can choose to click on Launch to launch our tool or Close to finish the install. Again this works, but then during uninstall this text also shows up and therefore it would be great if we have a bit more control over added controls in the theme file so that we could easily condition controls so that they show on Not Installed only. So again if I am missing something that actually does this then let me know where I am going wrong. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Bootstrapper-run-executable-on-exit-tp7580830p7596718.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 Bootstrapper run executable on exit [P]
Classification: Public Tim, Once again I am confused why you are trying to reinvent the wheel. Burn already does this! Check out the LaunchTarget event... http://wixtoolset.org/documentation/manual/v3/xsd/bal/wixstandardbootstrapperapplication.html Steve -Original Message- From: TimM [mailto:timmay...@smarttech.com] Sent: September-08-14 5:25 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Burn Bootstrapper run executable on exit Oh and one more thing about customizing the burn bootstrapper theme files. I figured that if it was too much work to simply add a checkbox on the success screen and have it set to launch the app on finish, I figured that maybe just add a text control at the bottom that then informs the user what the Launch button will do and therefore they can choose to click on Launch to launch our tool or Close to finish the install. Again this works, but then during uninstall this text also shows up and therefore it would be great if we have a bit more control over added controls in the theme file so that we could easily condition controls so that they show on Not Installed only. So again if I am missing something that actually does this then let me know where I am going wrong. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Bootstrapper-run-executable-on-exit-tp7580830p7596718.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 This message has been marked as Public by Steven Ogilvie on September-08-14 5:42:24 PM. The above classification labels were added to the message by TITUS Message Classification. For more information visit www.titus.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] SECREPAIR: CryptAcquireContext: Could not create the default key container
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 of the hypotheses around are wrong, unless we're just unlucky. Sascha: I have yet to try your stuff out. I know already now that you are dealing with MSIs in a bundle (correct?), which we don't do - we use bundles to use Windows Update files (MSUs) only, at present. All the rest of our stuff is just MSI. (Or rarely - testing only, I think, MSP.) So there's a difference right off. I wonder (list owners willing) if it is time to play what do we know? 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 2:41 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] SECREPAIR:
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 of the hypotheses around are wrong, unless we're just unlucky. Sascha: I have yet to try your stuff out. I know already now that you are dealing with MSIs in a bundle (correct?), which we don't do - we use bundles to use Windows Update files (MSUs) only, at present. All the rest of our stuff is just MSI. (Or rarely - testing only, I think, MSP.) So there's a difference right off. I wonder (list owners willing) if it is time to play what do we know? 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 |
Re: [WiX-users] Burn Bootstrapper run executable on exit
I think there is a feature request open for this. _ 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
