Re: [WiX-users] Bootstrap conditioned on OSbittage

2015-07-09 Thread Matt O'Connell
Thank David yes I agree with what your saying. I am a bit concerned the 
3rd party wouldn't like our bundle 'wrapping' and hiding their ARP 
entry. Is it possible to only hide the bundles entry?

dotNetInstaller looks good. (I was worried it was C# but the 
bootstrapper element is C++) . Ta

On 09/07/2015 10:44, David Watson wrote:
 Hi,
 Experience has taught that the best experience for the user and for the 
 developer and the support organisation is to follow the way that the burn 
 bundle works, it has been very carefully designed.

 Fire and forget bootstrappers are an alternative (I used to use this many 
 years ago http://dblock.github.io/dotnetinstaller/)  and are still widely 
 used.

 A single point of entry in ARP that allows your user to control the contents 
 of the bundle is much simpler to support than a whole array of packages.



   [http://cdn.sdl.tridion.sdlproducts.com/static/corporate/SDLlogo2014.png] 
 www.sdl.com/
 www.sdl.com


 SDL PLC confidential, all rights reserved. If you are not the intended 
 recipient of this mail SDL requests and requires that you delete it without 
 acting upon or copying any of its contents, and we further request that you 
 advise us.

 SDL PLC is a public limited company registered in England and Wales. 
 Registered number: 02675207.
 Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 
 7DY, UK.

 -Original Message-
 From: Matt O'Connell [mailto:techsupport...@gmail.com]
 Sent: 09 July 2015 10:06
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Bootstrap conditioned on OSbittage

 Well I only need to install one 3rd party installer based on os bittage.
 On x64- install a_64.exe else install a_32.exe I don't require downloader, 
 and chainer engine for that.

 If I can use the burn chainer to do this AND get an effectively 'invisible' 
 ARP for the un-avoidable bundle that would be 'ok'. If this is possible I'd 
 like to know how. But am also looking for alternatives to WiX's current 
 offering and thought this would be an ok place to ask, since the experience 
 level here is so high!.
 Thanks for your help on this.

 On 09/07/2015 02:16, Hoover, Jacob wrote:
 My first question would be why.  What do you need to do that you can't at 
 least allow your bundle be in the chain and let burn do its work before 
 deferring to your final exe installer?

 -Original Message-
 From: Matt O'Connell [mailto:techsupport...@gmail.com]
 Sent: Wednesday, July 08, 2015 7:41 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Bootstrap conditioned on OSbittage

 Sorry guys can I get some advise on this one please?

 I realise burn can't 'fire and forget' see
 http://www.joyofsetup.com/2013/07/05/burn-zero-one-or-n/
 but what (free) methods are there available to do this? Can anyone 
 reccommend something?

 Alternatively is it possible to bundle (and conditionalise) the exes but 
 hide the bundle's ARP entry and expose the third party exes ARP entries? If 
 so could the user could use that to repair/uninstall so it effectively 
 wouldn't appear that the package had been 'bundled'?

 Many Thanks

 On 17 June 2015 at 12:36, Matt O'Connell techsupport...@gmail.com wrote:

 I've got a third party exe with 2 versions to bootstrap based on OS
 bittage, our current setup code only does this for MSIs. I've found
 how to do this with burn bundle but don't need the bundleness of it
 as per this
 http://stackoverflow.com/questions/30010837/i-dont-want-install-a-boo
 t strapper-project-itself What would you guys recommend for this use
 case?

 --
  Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that you 
 need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

 --
  Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that you 
 need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today

Re: [WiX-users] Bootstrap conditioned on OSbittage

2015-07-09 Thread Matt O'Connell
Well I only need to install one 3rd party installer based on os bittage. 
On x64- install a_64.exe else install a_32.exe I don't require 
downloader, and chainer engine for that.

If I can use the burn chainer to do this AND get an effectively 
'invisible' ARP for the un-avoidable bundle that would be 'ok'. If this 
is possible I'd like to know how. But am also looking for alternatives 
to WiX's current offering and thought this would be an ok place to ask, 
since the experience level here is so high!.
Thanks for your help on this.

On 09/07/2015 02:16, Hoover, Jacob wrote:
 My first question would be why.  What do you need to do that you can't at 
 least allow your bundle be in the chain and let burn do its work before 
 deferring to your final exe installer?

 -Original Message-
 From: Matt O'Connell [mailto:techsupport...@gmail.com]
 Sent: Wednesday, July 08, 2015 7:41 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Bootstrap conditioned on OSbittage

 Sorry guys can I get some advise on this one please?

 I realise burn can't 'fire and forget' see 
 http://www.joyofsetup.com/2013/07/05/burn-zero-one-or-n/
 but what (free) methods are there available to do this? Can anyone reccommend 
 something?

 Alternatively is it possible to bundle (and conditionalise) the exes but hide 
 the bundle's ARP entry and expose the third party exes ARP entries? If so 
 could the user could use that to repair/uninstall so it effectively wouldn't 
 appear that the package had been 'bundled'?

 Many Thanks

 On 17 June 2015 at 12:36, Matt O'Connell techsupport...@gmail.com wrote:

 I've got a third party exe with 2 versions to bootstrap based on OS
 bittage, our current setup code only does this for MSIs. I've found
 how to do this with burn bundle but don't need the bundleness of it as
 per this
 http://stackoverflow.com/questions/30010837/i-dont-want-install-a-boot
 strapper-project-itself What would you guys recommend for this use
 case?

 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that you 
 need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Bootstrap conditioned on OSbittage

2015-07-09 Thread Matt O'Connell
Ah that's great, and I can hide the bundle ARP itself as well?

On 09/07/2015 11:51, Pally Sandher wrote:
 Unless the 3rd party installer is an MSI (which from your previous e-mails, 
 it appears they're executables), Burn won't do that regardless.
 If it is an MSI you can set the Visible attribute on the MsiPackage element 
 to yes  it won't do it either.

 Palbinder Sandher
 Software Platform Engineer
 T:   +44 (0)141 945 8500
 F:   +44 (0)141 945 8501
 http://www.iesve.com

 Integrated Environmental Solutions Limited. Registered in Scotland No. 
 SC151456
 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow 
 G20 0SP
 Email Disclaimer


 -Original Message-
 From: Matt O'Connell [mailto:techsupport...@gmail.com]
 Sent: 09 July 2015 11:33
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Bootstrap conditioned on OSbittage

 Thank David yes I agree with what your saying. I am a bit concerned the 3rd 
 party wouldn't like our bundle 'wrapping' and hiding their ARP entry. Is it 
 possible to only hide the bundles entry?

 dotNetInstaller looks good. (I was worried it was C# but the bootstrapper 
 element is C++) . Ta

 On 09/07/2015 10:44, David Watson wrote:
 Hi,
 Experience has taught that the best experience for the user and for the 
 developer and the support organisation is to follow the way that the burn 
 bundle works, it has been very carefully designed.

 Fire and forget bootstrappers are an alternative (I used to use this many 
 years ago http://dblock.github.io/dotnetinstaller/)  and are still widely 
 used.

 A single point of entry in ARP that allows your user to control the contents 
 of the bundle is much simpler to support than a whole array of packages.




 [http://cdn.sdl.tridion.sdlproducts.com/static/corporate/SDLlogo2014.p
 ng] www.sdl.com/ www.sdl.com


 SDL PLC confidential, all rights reserved. If you are not the intended 
 recipient of this mail SDL requests and requires that you delete it without 
 acting upon or copying any of its contents, and we further request that you 
 advise us.

 SDL PLC is a public limited company registered in England and Wales. 
 Registered number: 02675207.
 Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 
 7DY, UK.

 -Original Message-
 From: Matt O'Connell [mailto:techsupport...@gmail.com]
 Sent: 09 July 2015 10:06
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Bootstrap conditioned on OSbittage

 Well I only need to install one 3rd party installer based on os bittage.
 On x64- install a_64.exe else install a_32.exe I don't require downloader, 
 and chainer engine for that.

 If I can use the burn chainer to do this AND get an effectively 'invisible' 
 ARP for the un-avoidable bundle that would be 'ok'. If this is possible I'd 
 like to know how. But am also looking for alternatives to WiX's current 
 offering and thought this would be an ok place to ask, since the experience 
 level here is so high!.
 Thanks for your help on this.

 On 09/07/2015 02:16, Hoover, Jacob wrote:
 My first question would be why.  What do you need to do that you can't at 
 least allow your bundle be in the chain and let burn do its work before 
 deferring to your final exe installer?

 -Original Message-
 From: Matt O'Connell [mailto:techsupport...@gmail.com]
 Sent: Wednesday, July 08, 2015 7:41 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Bootstrap conditioned on OSbittage

 Sorry guys can I get some advise on this one please?

 I realise burn can't 'fire and forget' see
 http://www.joyofsetup.com/2013/07/05/burn-zero-one-or-n/
 but what (free) methods are there available to do this? Can anyone 
 reccommend something?

 Alternatively is it possible to bundle (and conditionalise) the exes but 
 hide the bundle's ARP entry and expose the third party exes ARP entries? If 
 so could the user could use that to repair/uninstall so it effectively 
 wouldn't appear that the package had been 'bundled'?

 Many Thanks

 On 17 June 2015 at 12:36, Matt O'Connell techsupport...@gmail.com wrote:

 I've got a third party exe with 2 versions to bootstrap based on OS
 bittage, our current setup code only does this for MSIs. I've found
 how to do this with burn bundle but don't need the bundleness of it
 as per this
 http://stackoverflow.com/questions/30010837/i-dont-want-install-a-bo
 o t strapper-project-itself What would you guys recommend for this
 use case?

 -
 -
  Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that you 
 need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https

Re: [WiX-users] Bootstrap conditioned on OSbittage

2015-07-08 Thread Matt O'Connell
Sorry guys can I get some advise on this one please?

I realise burn can't 'fire and forget' see
http://www.joyofsetup.com/2013/07/05/burn-zero-one-or-n/
but what (free) methods are there available to do this? Can anyone
reccommend something?

Alternatively is it possible to bundle (and conditionalise) the exes but
hide the bundle's ARP entry and expose the third party exes ARP entries? If
so could the user could use that to repair/uninstall so it effectively
wouldn't appear that the package had been 'bundled'?

Many Thanks

On 17 June 2015 at 12:36, Matt O'Connell techsupport...@gmail.com wrote:

 I've got a third party exe with 2 versions to bootstrap based on OS
 bittage, our current setup code only does this for MSIs. I've found how to
 do this with burn bundle but don't need the bundleness of it as per this
 http://stackoverflow.com/questions/30010837/i-dont-want-install-a-bootstrapper-project-itself
 What would you guys recommend for this use case?

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Bootstrap conditioned on OSbittage

2015-06-17 Thread Matt O'Connell
I've got a third party exe with 2 versions to bootstrap based on OS 
bittage, our current setup code only does this for MSIs. I've found how 
to do this with burn bundle but don't need the bundleness of it as per 
this 
http://stackoverflow.com/questions/30010837/i-dont-want-install-a-bootstrapper-project-itself
 

What would you guys recommend for this use case?

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] WixShellExec and app window appearing behind other windows

2014-10-10 Thread Matt O'Connell
Many moons ago we stopped adding a 'launch the installed app' check box 
to our final dialog as we had intermittent issues with the launched app 
window appearing behind other windows as per this WiX mailing list issue 
from 2005:
http://sourceforge.net/p/wix/mailman/message/11428915/
We didn't implement the coding fix that was suggested there.

At that time we were using a Custom Action:
CustomAction Id=LaunchProduct FileKey=ApplicationExe ExeCommand= 
Return=asyncNoWait /

Now the WiX CHM suggests using a WiX a Standard Custom Action
http://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/run_program_after_install.html
in WiXCA:
CustomAction Id=LaunchApplication BinaryKey=WixCA 
DllEntry=WixShellExec Impersonate=yes / /Product

Does anyone know if any efforts to sidestep the above issue were made 
when making this a 'Standard Custom Action' in WixShellExecTarget? Or if 
not, do people using WixShellExec to do this commonly experience this 
issue with their apps now (hard for me to test as it was intermittent)?

Many Thanks
Matt
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How to hide a file in WXS configuration file ?

2014-10-09 Thread Matt O'Connell
http://wixtoolset.org/documentation/manual/v3/xsd/wix/file.html
(use Hidden attribute)

On 09/10/2014 07:55, Fabrice MAUPIN wrote:
 Hello everybody,

   

 This is an extract of my WXS configuration file :

   

   DirectoryRef Id=APPLICATIONFOLDER

   Component Id=MyFileId Guid=. Win64=yes

   File Id=MyFileId Name=_dt.xsl
 Source=app\resources\_dt.xsl KeyPath=yes /

  /Component

  Component Id=MyFileCopyId Guid=. Win64=yes

  CopyFile Id=MyFileCopyId FileId=MyFileId
 DestinationDirectory=APPLICATIONFOLDER /

  /Component

   

  /DirectoryRef

  

  Feature Id=MyFeature

   ComponentRef Id=MyFileId /

   ComponentRef Id=MyFileCopyId /

  /Feature

   

 I would like to hide the  _dt.xsl file which was copied : is it possible ?

   

 If yes, how ?

   

 Thanks you.

   

 Fabrice

   

   

   



 ---
 Ce courrier électronique ne contient aucun virus ou logiciel malveillant 
 parce que la protection avast! Antivirus est active.
 http://www.avast.com
 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Possible to install vcruntimes first in MSI?

2014-10-07 Thread Matt O'Connell
Create a stub msi and merge into that?
On 06/10/2014 19:07, shannon wrote:
 Using an msi output only, is it possible to install prereq's first via wix?
 Specifically, I need to install the VC2008/2013 runtimes, and these must be
 completed before the product install begins or the install will fail. (Have
 tried installing the merge modules, but it appears that these install
 alongside the product, not first.)


 NOTE: The output MUST be an msi, not an exe, since we need to be able to use
 group policy as an install mechanism, so using setupbld.exe to create a
 bootstrapper application unfortunately isn't an acceptable solution. My
 understanding is that similarly, burn.exe will only output an exe, not an
 msi.

 Thanks for any advice,

 Shannon





 --
 View this message in context: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible-to-install-vcruntimes-first-in-MSI-tp7597147.html
 Sent from the wix-users mailing list archive at Nabble.com.

 --
 Slashdot TV.  Videos for Nerds.  Stuff that Matters.
 http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/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

2014-08-27 Thread Matt O'Connell
For those without a support contract, where's the most visible place to 
post? msdn forums (clickonce and setup  deployment projects, I've never 
found an MSI one...) or microsoft.public.platformsdk.msi newsgroup?  The 
installer team blog would've been a good place but its not updated anymore..

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

2014-08-26 Thread Matt O'Connell
We've started seeing this a lot recently.
Installed the kb on to Win 7 and Win 8 VMs but it didn't replicate it. 
Our customers with the issue are usually running some sort of antivirus 
and we presumed it's some kind of conflict with that but we've had no 
success with disabling Anti-virus with msconfig. However removing the kb 
update has fixed it for at least one customer. I'm hoping to find a 
recipe to replicate it but we're not there yet.

I'm hoping MS find a fix an re-issue the update.:-)

On 18/08/2014 22:54, Neil Sleightholm wrote:
 Thanks, seen that one and this one 
 https://community.logos.com/forums/p/87997/617278.aspx. Both look similar.

 Neil

 -Original Message-
 From: Phill Hogland [mailto:phogl...@rimage.com]
 Sent: 18 August 2014 20:13
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the 
 default key container

 FYI
 http://www.edugeek.net/forums/windows-7/140586-possible-issue-kb2918614-causing-overlapped-i-o-operation-progress-errors.html




 --
 View this message in context: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/SECREPAIR-CryptAcquireContext-Could-not-create-the-default-key-container-tp7596414p7596418.html
 Sent from the wix-users mailing list archive at Nabble.com.

 --
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

 --
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


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

2014-08-26 Thread Matt O'Connell
We get a slightly different error out of CryptAcquireContext, ours 
follow this pattern:
MSI (s) (28:BC) [10:47:26:837]: SECREPAIR: Hash Database: 
C:\Windows\Installer\SourceHash{xxx----}
MSI (s) (28:BC) [10:47:26:837]: SECREPAIR: SourceHash database file 
already exists. Deleting it.
MSI (s) (28:BC) [10:47:26:839]: Note: 1: 2262 2: SourceHash 3: -2147287038
MSI (s) (28:BC) [10:47:26:852]: SECREPAIR: New Hash Database creation 
complete.
MSI (s) (28:BC) [10:47:26:854]: SECREPAIR: A general error running 
CryptAcquireContext
MSI (s) (28:BC) [10:47:26:854]: SECREPAIR: Crypt Provider not 
initialized. Error:0
MSI (s) (28:BC) [10:47:26:859]: SECREPAIR: A general error running 
CryptAcquireContext
MSI (s) (28:BC) [10:47:26:859]: SECREPAIR: Crypt Provider not 
initialized. Error:0
MSI (s) (28:BC) [10:47:26:860]: SECREPAIR: A general error running 
CryptAcquireContext
MSI (s) (28:BC) [10:47:26:860]: SECREPAIR: Crypt Provider not 
initialized. Error:0
MSI (s) (28:BC) [10:47:26:861]: SECREPAIR: A general error running 
CryptAcquireContext
MSI (s) (28:BC) [10:47:26:861]: SECREPAIR: Crypt Provider not 
initialized. Error:0
MSI (s) (28:BC) [10:47:26:862]: SECREPAIR: A general error running 
CryptAcquireContext
MSI (s) (28:BC) [10:47:26:862]: SECREPAIR: Crypt Provider not 
initialized. Error:997
MSI (s) (28:BC) [10:47:26:862]: SECUREREPAIR: Failed to 
CreateContentHash of the file: \x\.JPG: for computing its 
hash. Error: 997
MSI (s) (28:BC) [10:47:26:862]: SECREPAIR: Failed to create hash for the 
install source files
MSI (s) (28:BC) [10:47:26:862]: SECUREREPAIR: SecureRepair Failed. Error 
code: 3e5F6C634B8

Error 997 being the Windows error 'Overlapped I/O operation is in 
progress.'

On 26/08/2014 11:05, Matt O'Connell wrote:
 We've started seeing this a lot recently.
 Installed the kb on to Win 7 and Win 8 VMs but it didn't replicate it. 
 Our customers with the issue are usually running some sort of 
 antivirus and we presumed it's some kind of conflict with that but 
 we've had no success with disabling Anti-virus with msconfig. However 
 removing the kb update has fixed it for at least one customer. I'm 
 hoping to find a recipe to replicate it but we're not there yet.

 I'm hoping MS find a fix an re-issue the update.:-)

 On 18/08/2014 22:54, Neil Sleightholm wrote:
 Thanks, seen that one and this one 
 https://community.logos.com/forums/p/87997/617278.aspx. Both look 
 similar.

 Neil

 -Original Message-
 From: Phill Hogland [mailto:phogl...@rimage.com]
 Sent: 18 August 2014 20:13
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not 
 create the default key container

 FYI
 http://www.edugeek.net/forums/windows-7/140586-possible-issue-kb2918614-causing-overlapped-i-o-operation-progress-errors.html
  





 -- 
 View this message in context: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/SECREPAIR-CryptAcquireContext-Could-not-create-the-default-key-container-tp7596414p7596418.html
 Sent from the wix-users mailing list archive at Nabble.com.

 --
  

 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

 --
  

 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



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

2014-08-26 Thread Matt O'Connell
Custom Autorun/Setup.exe (elevating) that's been working fine for years, 
OR on the CMD line line msiexec /i path to msi (where it will prompt to 
elevate as well).
On 26/08/2014 16:15, Rob Mensching wrote:
 How are you installing the MSIs? Just double-click the .MSI directly, as part 
 of a Bundle, some other mechanism?

 ___
   FireGiant  |  Dedicated support for the WiX toolset  |  
 http://www.firegiant.com/

 -Original Message-
 From: Matt O'Connell [mailto:techsupport...@gmail.com]
 Sent: Tuesday, August 26, 2014 3:35 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not create the 
 default key container

 We get a slightly different error out of CryptAcquireContext, ours follow 
 this pattern:
 MSI (s) (28:BC) [10:47:26:837]: SECREPAIR: Hash Database:
 C:\Windows\Installer\SourceHash{xxx----}
 MSI (s) (28:BC) [10:47:26:837]: SECREPAIR: SourceHash database file already 
 exists. Deleting it.
 MSI (s) (28:BC) [10:47:26:839]: Note: 1: 2262 2: SourceHash 3: -2147287038 
 MSI (s) (28:BC) [10:47:26:852]: SECREPAIR: New Hash Database creation 
 complete.
 MSI (s) (28:BC) [10:47:26:854]: SECREPAIR: A general error running 
 CryptAcquireContext MSI (s) (28:BC) [10:47:26:854]: SECREPAIR: Crypt Provider 
 not initialized. Error:0 MSI (s) (28:BC) [10:47:26:859]: SECREPAIR: A general 
 error running CryptAcquireContext MSI (s) (28:BC) [10:47:26:859]: SECREPAIR: 
 Crypt Provider not initialized. Error:0 MSI (s) (28:BC) [10:47:26:860]: 
 SECREPAIR: A general error running CryptAcquireContext MSI (s) (28:BC) 
 [10:47:26:860]: SECREPAIR: Crypt Provider not initialized. Error:0 MSI (s) 
 (28:BC) [10:47:26:861]: SECREPAIR: A general error running 
 CryptAcquireContext MSI (s) (28:BC) [10:47:26:861]: SECREPAIR: Crypt Provider 
 not initialized. Error:0 MSI (s) (28:BC) [10:47:26:862]: SECREPAIR: A general 
 error running CryptAcquireContext MSI (s) (28:BC) [10:47:26:862]: SECREPAIR: 
 Crypt Provider not initialized. Error:997 MSI (s) (28:BC) [10:47:26:862]: 
 SECUREREPAIR: Failed to CreateContentHash of the file: \x\.JPG: 
 for computing its hash. Error: 997 M
 SI (s) (28:BC) [10:47:26:862]: SECREPAIR: Failed to create hash for the 
install source files MSI (s) (28:BC) [10:47:26:862]: SECUREREPAIR: SecureRepair 
Failed. Error
 code: 3e5F6C634B8

 Error 997 being the Windows error 'Overlapped I/O operation is in progress.'

 On 26/08/2014 11:05, Matt O'Connell wrote:
 We've started seeing this a lot recently.
 Installed the kb on to Win 7 and Win 8 VMs but it didn't replicate it.
 Our customers with the issue are usually running some sort of
 antivirus and we presumed it's some kind of conflict with that but
 we've had no success with disabling Anti-virus with msconfig. However
 removing the kb update has fixed it for at least one customer. I'm
 hoping to find a recipe to replicate it but we're not there yet.

 I'm hoping MS find a fix an re-issue the update.:-)

 On 18/08/2014 22:54, Neil Sleightholm wrote:
 Thanks, seen that one and this one
 https://community.logos.com/forums/p/87997/617278.aspx. Both look
 similar.

 Neil

 -Original Message-
 From: Phill Hogland [mailto:phogl...@rimage.com]
 Sent: 18 August 2014 20:13
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] SECREPAIR: CryptAcquireContext: Could not
 create the default key container

 FYI
 http://www.edugeek.net/forums/windows-7/140586-possible-issue-kb29186
 14-causing-overlapped-i-o-operation-progress-errors.html





 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/SECREPA
 IR-CryptAcquireContext-Could-not-create-the-default-key-container-tp7
 596414p7596418.html Sent from the wix-users mailing list archive at
 Nabble.com.

 -
 -

 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

 -
 -

 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

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

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

Re: [WiX-users] offline install

2014-03-28 Thread Matt O'Connell
FYI, I had to this issue today and copying the ProjectAggregator2.msi 
next to my wix3.7.exe worked. (I have both VS 2005 and 2008)

Log entries for failure:
[105C:11BC][2014-03-28T15:42:31]i000: Caching bundle from: 
'C:\Users\MOCONN~1.SER\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\.be\WiX37.exe'
 
to: 'C:\ProgramData\Package 
Cache\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\WiX37.exe'
[105C:11BC][2014-03-28T15:42:31]i320: Registering bundle dependency 
provider: {963ac4b4-a882-4471-8db9-c4adc7b42dc4}, version: 3.7.1224.0
[0A24:0C38][2014-03-28T15:42:31]w343: Prompt for source of package: 
ProjectAggregator2, payload: ProjectAggregator2, path: 
PATH\ProjectAggregator2.msi
[0A24:0C38][2014-03-28T15:42:31]i338: Acquiring package: 
ProjectAggregator2, payload: ProjectAggregator2, download from: 
http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
[0A24:0C38][2014-03-28T15:42:32]e000: Error 0x80070032: Failed to send 
request to URL: http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
[0A24:0C38][2014-03-28T15:42:32]e000: Error 0x80070032: Failed to 
connect to URL: http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
[0A24:0C38][2014-03-28T15:42:32]e000: Error 0x80070032: Failed to get 
size and time for URL: 
http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
[0A24:0C38][2014-03-28T15:42:32]e000: Error 0x80070032: Failed attempt 
to download URL: 
'http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi' to: 
'C:\Users\MOCONN~1.SER\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2'
[0A24:0C38][2014-03-28T15:42:32]e000: Error 0x80070032: Failed to 
acquire payload from: 
'http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi' to working 
path: 
'C:\Users\MOCONN~1.SER\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2'
[0A24:0C38][2014-03-28T15:42:32]e313: Failed to acquire payload: 
ProjectAggregator2 to working path: 
C:\Users\MOCONN~1.SER\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2,
 
error: 0x80070032.
[0A24:0ABC][2014-03-28T15:42:32]e000: Error 0x80070032: Failed while 
caching, aborting execution.

Cheers

On 10/09/2013 17:33, Rob Mensching wrote:
 That's because http://wixtoolset.org suffered catastrophic hardware
 failure. It's taking them days to try to recover all the data. You can find
 ProjectAggregator2.msi in the repository at: src\Votive\SDK\Redist and put
 it next to the wix37.exe. That is what /layout would do... if the website
 would respond.


 On Tue, Sep 10, 2013 at 9:26 AM, keith.doug...@statcan.gc.ca wrote:

 I get a failed install with the ProjectAggregator you mentioned:

 [1BA8:1518][2013-09-10T12:24:12]w343: Prompt for source of package:
 ProjectAggregator2, payload: ProjectAggregator2, path:
 G:\WixLayout\ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]i338: Acquiring package:
 ProjectAggregator2, payload: ProjectAggregator2, download from:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to send
 request to URL: http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to connect
 to URL: http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to get
 size and time for URL:
 http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed attempt to
 download URL: 'http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi'
 to:
 'C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2'
 [1BA8:1518][2013-09-10T12:24:12]e000: Error 0x80070002: Failed to acquire
 payload from: 'http://wixtoolset.org/releases/v3.7/ProjectAggregator2.msi'
 to working path:
 'C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2'
 [1BA8:1518][2013-09-10T12:24:12]e313: Failed to acquire payload:
 ProjectAggregator2 to working path:
 C:\Users\dougkei\AppData\Local\Temp\{963ac4b4-a882-4471-8db9-c4adc7b42dc4}\ProjectAggregator2,
 error: 0x80070002.
 [1BA8:0C04][2013-09-10T12:24:12]e000: Error 0x80070002: Failed while
 caching, aborting execution.

 This machine (where I actually develop from) has no internet.




 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-951-4405
 Facsimile | Télécopieur 613-951-1966
 Government of Canada | Gouvernement du Canada


 -Original Message-
 From: Rob Mensching [mailto:r...@robmensching.com]
 Sent: September-10-13 12:17 PM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] offline install

 The wix37.exe is essentially self-contained (except for
 ProjectAggregator2.msi which is only needed for 

Re: [WiX-users] MsiNTProductType support in wix bundle?

2014-01-15 Thread Matt O'Connell
Use NOT VersionNT64 as below:

Condition  Message=!(loc.CONDITION_Message1)
!-- OS must be Windows XP (32-bit) SP3 OR 2003 Server (32-bit) SP2 OR 
Vista and above --
   (VersionNT = 501 AND ServicePackLevel=3 AND NOT (VersionNT64)) 
OR (VersionNT = 502 AND ServicePackLevel=2 AND NOT (VersionNT64)) OR 
(VersionNT = 600)
/Condition

On 15/01/2014 14:24, Goran Malovic wrote:
 Hi,

 I have a requirement to set minimum OS requirement to be XP SP3 and Server 
 2003 sp2. XP 64 bit and Server 2003 have one thing in common - NTVersion - 
 v5.2. This makes it difficult to set a condition based on NTVersion.

 Condition = ((VersionNT = v5.1) AND (ServicePackLevel = 3))  OR ((VersionNT 
 = v5.2) AND (ServicePackLevel = 2)) OR (VersionNT = 6.0)

 This condition will also allow application to be installed on XP 64 bit SP2, 
 which is not my intention. As per this link

 http://msdn.microsoft.com/en-us/library/aa370329%28v=vs.85%29.aspx

 MSI installer offers MsiNTProductType, which can be used in condition to 
 determine if OS is server based or not. However, I do not see this variable 
 listed under bundle varilables, nor I can find any mention of it in the help 
 files.

 Any advise regarding this issue?

 Regards,
 Goran
 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] MsiNTProductType support in wix bundle?

2014-01-15 Thread Matt O'Connell
Sorry that's wrong please disregard.
On 15/01/2014 14:50, Matt O'Connell wrote:
 Use NOT VersionNT64 as below:

 Condition  Message=!(loc.CONDITION_Message1)
 !-- OS must be Windows XP (32-bit) SP3 OR 2003 Server (32-bit) SP2 OR 
 Vista and above --
   (VersionNT = 501 AND ServicePackLevel=3 AND NOT (VersionNT64)) 
 OR (VersionNT = 502 AND ServicePackLevel=2 AND NOT (VersionNT64)) OR 
 (VersionNT = 600)
 /Condition

 On 15/01/2014 14:24, Goran Malovic wrote:
 Hi,

 I have a requirement to set minimum OS requirement to be XP SP3 and 
 Server 2003 sp2. XP 64 bit and Server 2003 have one thing in common - 
 NTVersion - v5.2. This makes it difficult to set a condition based on 
 NTVersion.

 Condition = ((VersionNT = v5.1) AND (ServicePackLevel = 3))  OR 
 ((VersionNT = v5.2) AND (ServicePackLevel = 2)) OR (VersionNT = 6.0)

 This condition will also allow application to be installed on XP 64 
 bit SP2, which is not my intention. As per this link

 http://msdn.microsoft.com/en-us/library/aa370329%28v=vs.85%29.aspx

 MSI installer offers MsiNTProductType, which can be used in condition 
 to determine if OS is server based or not. However, I do not see this 
 variable listed under bundle varilables, nor I can find any mention 
 of it in the help files.

 Any advise regarding this issue?

 Regards,
 Goran
 --
  

 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk 

 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Howto override variables from a file using MSBuild/VS2012

2013-10-08 Thread Matt O'Connell
OK. Does the easy way to do it involve TFS?

On 08/10/2013 01:03, Blair Murri wrote:
 Yes, that can be done. In fact, I did it last month. Someone knowledgeable 
 with MSBuild would be able to set that up in a short time. In fact, that 
 other project could build all or any combination of lang/bitness you want in 
 one invocation.
   
 The rest (of us) buy the book 
 (http://www.amazon.com/gp/product/0735626286?ie=UTF8tag=sedodream-20linkCode=xm2camp=1789creativeASIN=0735626286)
  or read the blog by the author (http://sedodream.com/default.aspx).
   
 I do short off-site contracts if you need it in a hurry.
   
 Date: Mon, 7 Oct 2013 22:38:52 +0100
 From: techsupport...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Howto override variables from a file using  
 MSBuild/VS2012

 Hi,
 I've recently switched from using build cmd files to trying to use
 votive/VS2012 and have run in to a slight issue trying to do something that
 was a lot easier when it was all in cmd files.

 (Not sure if this is a msbuild or WiX issue):I have a WiX Setup project in
 vs2012 (WiX3.7) that I already has eight different language/bittage build
 configurations. I want to override variables for source paths without
 having yet another build configuration or having to check a file out, edit
 the default value and then build. This is mainly so someone, probably not
 me, can build the existing installer with a different set of
 resources/content. So I thought I might be able to have another project in
 the same solution that could set these variables and then build the 'main'
 installer project where I have a 'ifndef variable' which will override if
 the variable exists already (and so if you just call the main installer
 wixproj you get the defaults). Is this feasible, or is there a better way
 to do this?

 Thanks
 Matt O'Connell
 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
   
 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Howto override variables from a file using MSBuild/VS2012

2013-10-07 Thread Matt O'Connell
Hi,
I've recently switched from using build cmd files to trying to use
votive/VS2012 and have run in to a slight issue trying to do something that
was a lot easier when it was all in cmd files.

(Not sure if this is a msbuild or WiX issue):I have a WiX Setup project in
vs2012 (WiX3.7) that I already has eight different language/bittage build
configurations. I want to override variables for source paths without
having yet another build configuration or having to check a file out, edit
the default value and then build. This is mainly so someone, probably not
me, can build the existing installer with a different set of
resources/content. So I thought I might be able to have another project in
the same solution that could set these variables and then build the 'main'
installer project where I have a 'ifndef variable' which will override if
the variable exists already (and so if you just call the main installer
wixproj you get the defaults). Is this feasible, or is there a better way
to do this?

Thanks
Matt O'Connell
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Patch issue

2012-10-15 Thread Matt O'Connell
Use the version lying technique: Change the version of this FileId to 
10.1.1 in your patch upgrade image by editing the msi in orca. Then 
re-build the patch pointing to your edited MSI.

When the patch installs on top of the localised version it won't matter 
that the transform has removed this attribute in the actual local MSI 
being upgraded. Patching only looks at the file table version changes at 
the time the patch was created. I.E. the patch 'thinks': this FileId was 
version incremented when I was built so i'll happily apply the transform 
to it. (Make sure your actual file verison matches your edits otherwise 
you'll get request for source issues on repair).


On 15/10/2012 13:03, Uma Harano wrote:
 Unfortunately the mst has already been released to our customers. We are now 
 trying to release the msp patch and it is not patching the file. So we are 
 trying to see how we can now fix the problem (so that the msp updates the 
 file correctly) caused by the released mst.


--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Error applying Everyone permisisons to key using LockPermsisions table

2012-09-24 Thread Matt O'Connell
I have a 64-Bit MSI that needs to set reg permisions on some keys via 
the LcokPermissions table (my 32-Bit MSI still uses subinacl in a CA). 
It is having a reproducable error that I need to fix.

I have 2 registry entires in referenced in my LockPermissions table. 
Both set to 'Everyone' with GenericAll=yes
One is for a common location:
 HKLM\SOFTWARE\[Company]\common\registration
(Has no values)
And one is app specific:
 HKLM\SOFTWARE\[Company]\[app]\[ver]\registration
(has with various values)

The app specific one always get the correct permisssions. However if 
it's a 'clean' machine Installer sets Everyone GenericAll permissions 
for the 'highest' reg entry of the MSI (HLKM\SOFTWARE\[Company]) and all 
subkeys (app specific and common)!

It only get's it right if there's a existing registry key of the same 
name HKLM\SOFTWARE\[Company]\common\registration**(with or wirthout the 
right permissions)*.
**
*Any Ideas what am I doing wrong here (or is this a bug)?*
*WiX 3.5 3.5.2519.0
Installer V 5.0.7601.17514 *

*Many Thanks!*
*
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Changing product name at install time

2012-08-31 Thread Matt O'Connell
That's not what I've found. I've got  a custom action running which 
changes our ProductName at install time in WiX 3.5. It is one our first 
actions in our InstallExecuteSequence and seems to work. All the Actions 
before it need to not reference [ProductName] or else get the 'wrong' 
result. Can you think of something wrong with this or is this not good 
practice for some reason?

On 30/08/2012 23:26, Christopher Painter wrote:
 No.  The ProductName property is immutable once the installer begins.
 You'd have to do something like asking for the name before starting the
 install and then dynamically generate and apply a transform for
 installation.

 
   From: Jain, Mukesh mukeshj...@kpmg.com
 Sent: Thursday, August 30, 2012 5:07 PM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Changing product name at install time

 Can we change product name at install time?

 Thanks,
 Mukesh

  ANY TAX ADVICE IN THIS COMMUNICATION IS NOT INTENDED OR
 WRITTEN BY KPMG TO BE USED, AND CANNOT BE USED, BY A CLIENT OR ANY
 OTHER PERSON OR ENTITY FOR THE PURPOSE OF (I) AVOIDING PENALTIES
 THAT MAY BE IMPOSED ON ANY TAXPAYER OR (ii) PROMOTING, MARKETING OR
 RECOMMENDING TO ANOTHER PARTY ANY MATTERS ADDRESSED HEREIN. ***

 Any advice in this communication is limited to the conclusions
 specifically set forth herein and is based on the completeness and
 accuracy of the stated facts, assumptions and/or representations
 included.  In rendering our advice, we may consider tax authorities
 that are subject to change, retroactively and/or prospectively, and
 any such changes could affect the validity of our advice.  We will
 not update our advice for subsequent changes or modifications to
 the laws and regulations, or to the judicial and administrative
 interpretations thereof.

 The advice or other information in this document was prepared for
 the sole benefit of KPMG's client and may not be relied upon by any
 other person or organization.  KPMG accepts no responsibility or
 liability in respect of this document to any person or organization
 other than KPMG's client.

 ***
 The information in this email is confidential and may be legally
 privileged. It is intended solely for the addressee. Access to this email
 by anyone else is unauthorized. If you are not the intended recipient, any
 disclosure, copying, distribution or any action taken or omitted to be
 taken in reliance on it, is prohibited and may be unlawful. When addressed
 to our clients any opinions or advice contained in this email are subject
 to the terms and conditions expressed in the governing KPMG client
 engagement letter.
 ***

 
 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Best way to remove a feature in another installed app at install time

2012-08-21 Thread Matt O'Connell
Hi WiX users

I've got a product B that shares a (hidden) feature with it's 
predecessor A. If I install A over B the registry we use toggles back 
the the old app location. Since we may want to have update B's feature 
at some point this is bad.

My company doesn't like to uninstall the old product via major upgrades 
so what is the best way in WiX for me to remove the feaure in app A that 
app B wants to also install?

Many Thanks


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Best way to remove a feature in another installed app at install time

2012-08-21 Thread Matt O'Connell
OK fair enough. I was hoping not to have to patch the older product if 
possible. I was hoping WiX might do something like could be done via the 
automation interface'sFeatureRequestState  
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371662%28v=vs.85%29.aspxproperty.
  
 Is the user expected to remove the old product on
 their own?
Yep, we give the users an extensive 'suck it and see' period in which they can 
return in which users frequently run old and new side by side by side. Our file 
formats weren't previously forwards compatible so it would have been a bit rude 
to lock them in to the latest version. Of course this means we often hear about 
users having all previous versions installed.  :-(

Thanks for the pointers.

On 21/08/2012 16:34, Rob Mensching wrote:
 AFAIK, you can't really do that. You could try to condition the Feature and
 then set something in the new install that causes the old installs Feature
 condition to evaluate to false and then have the user repair the old
 install. That *might* get the feature to turn off (since it's condition is
 false). Of course, the user experience is pretty odd as well.
 Shared registry keys that point at paths are often susceptible to this
 problem. Although, I can't say I quite understand your upgrade path if you
 don't use major upgrades. Is the user expected to remove the old product on
 their own?
 On Tue, Aug 21, 2012 at 3:09 AM, Matt O'Connell 
 techsupport...@gmail.comwrote:

 Hi WiX users

 I've got a product B that shares a (hidden) feature with it's
 predecessor A. If I install A over B the registry we use toggles back
 the the old app location. Since we may want to have update B's feature
 at some point this is bad.

 My company doesn't like to uninstall the old product via major upgrades
 so what is the best way in WiX for me to remove the feaure in app A that
 app B wants to also install?

 Many Thanks



 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Patch to update version of installed product?

2012-07-18 Thread Matt O'Connell
WholeFilesOnly=yes change to no

Order=2 change to 1

patch runnup issue - did you change the package code for the updated msi?


On 18/07/2012 12:34, Farrukhw wrote:
 Thanks all for your replies. I've just posted my resultant patch script here:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patch-can-t-update-installed-product-and-shows-Change-Repair-dialog-td7579479.html

 but with some issues and I need help in these.

 Thanks

 --
 View this message in context: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patch-to-update-version-of-installed-product-tp7579458p7579480.html
 Sent from the wix-users mailing list archive at Nabble.com.

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Patch to update version of installed product?

2012-07-18 Thread Matt O'Connell
Small updates do not require changing the product code! This forces a 
major update and thus your update is massive:-) . All msi file have a 
package code which should probably be left to generate automatically. 
This should be changed in any event.

As an aside, if you can find a reason to update the version number to 
x.x.1.x not x.x.x.1 it's probably safer since if you later
decide to release a patch to x.x.b.x you couldn't use the another patch 
to patch both released versions as you can't mix small and minor updates 
in the same patch.

On 18/07/2012 13:23, Farrukhw wrote:
 Hi Moc
 Thanks for the tips. No, I only changed ProductCode with a new GUID and
 updated in all other tables e.g. Registry, INIFile etc.



 --
 View this message in context: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patch-to-update-version-of-installed-product-tp7579458p7579482.html
 Sent from the wix-users mailing list archive at Nabble.com.

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Wix Weekly Builds?

2012-01-23 Thread Matt O'Connell
Many Thanks. The new WiX home page is great (as WiX deserves). Just in 
case you don't know already (non www) wixtoolset.org still points to old 
redirect page.
Matt O'Connell

On 21/01/2012 07:51, Rob Mensching wrote:
 Just: http://robmensching.com/blog/posts/2012/1/20/The-wixtoolset.org-online
 Whew, that's a load off.


 On Wed, Jan 18, 2012 at 11:31 AM, John Bergman
 john.berg...@xpedienttechnologies.com  wrote:

 Are weekly builds available again yet?

 I was going to upgrade our installers to use a more recent build, but
 could not find them.  Rob's blog mentioned that they were on track, but it
 still points to October's build.


 John


 --
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] UK Localization

2011-12-21 Thread Matt O'Connell
 I cant remember ever seeing a
 specific UK version of any software that I've installed
Install anySerif  http://www.serif.com/  App (you get a choice).

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users