Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

[Namrata Kumari]

Could you please share the complete code. 



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/dual-purpose-installer-ALLUSERS-2-and-Bootstrapper-tp7591740p7596724.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=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 Bootstrapper run executable on exit

[Rob Mensching]

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=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

[Sascha Sertel]

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 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 

Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container

[John Cooper]

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 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: Cryp

Re: [WiX-users] Burn Bootstrapper run executable on exit [P]

[Steven Ogilvie]

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=157508191&iu=/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=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 Bootstrapper run executable on exit

[TimM]

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=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

[John Cooper]

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 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 diff

Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container

[Sascha Sertel]

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  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,  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 insta

Re: [WiX-users] Uninstalling bundle with broken BA

[Hoover, Jacob]

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\\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? :(
> > >
> > > --
> > > 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=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
> >
>
>
> --
> 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=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 re

Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container

[Keith.Douglas]

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 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

Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container

[John Cooper]

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 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 
> 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 | j

Re: [WiX-users] Uninstalling bundle with broken BA

[Sascha Sertel]

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? :(
> > >
> > > --
> > > 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=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
> >
>
>
> --
> 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=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

[Sascha Sertel]

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 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 
> 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.
> >

Re: [WiX-users] Uninstalling bundle with broken BA

[Nicolás Alvarez]

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  >
> 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=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
>


-- 
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=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

[Keith.Douglas]

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  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

Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the default key container

[John Cooper]

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  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  :
> > 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] Uninstalling bundle with broken BA

[Sascha Sertel]

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 
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=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

[Sascha Sertel]

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  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  :
> > 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=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
> 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

Re: [WiX-users] Burn built-in variables question

[TimM]

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=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
[hidden email]
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 
here.
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=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] Where to get the ClassicTheme.xml/wxl Bootstrapper files?

[TimM]

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=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

[John Cooper]

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  :
> 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=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
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=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-user

Re: [WiX-users] Burn built-in variables question

[Rob Mensching]

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=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 Bootstrapper run executable on exit

[TimM]

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=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] Where to get the ClassicTheme.xml/wxl Bootstrapper files?

[Rob Mensching]

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%201&referringTitle=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=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 built-in variables question

[TimM]

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=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

[Keith.Douglas]

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  :
> 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=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

[WiX-users] Where to get the ClassicTheme.xml/wxl Bootstrapper files?

[TimM]

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%201&referringTitle=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=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

[Keith.Douglas]

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  :
> 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=157508191&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users