[WiX-users] Using transforms (regular) to install mulitple times per application
What I am trying to do is to allow customer bootstrappers the ability to install my package for thier application. In some cases the customer has two applications (installed in one setup) that use my product. So how can I use a transform that will allow this customer to install my product twice? And also support patches etc My product is delivered as a msi file. http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n7584257/New_Bitmap_Image.bmp I currently have a msi that implements instance tranforms to do this. If I were using scripts msiexec.exe installs it fine with MSINEWINSTANCE=1 and TRANSFORMS set. And if I were using scripts I could uninstall fine by calling msiexec.exe without the MSINEWINSTANCE=1 parameter. However, using a msiPackage in wix I don't see how I can provide a msiProperty (MSINEWINSTANCE) on Install and not have the msiProperty on uninstall. So we are thinking of abondoning instance transforms and seeing if there is a way to use regular transforms to do the same. Being green on the subject of installer and Wix, I would love some direction on how I can solve this problem. My component is used by several independent applications as well and they want to be able to exist on machines that may have other applications that use my component (thier own copy). - - jon -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-transforms-regular-to-install-mulitple-times-per-application-tp7584257.html Sent from the wix-users mailing list archive at Nabble.com. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using transforms (regular) to install mulitple times per application
Hi, Shared components can be managed several ways how you implement depends on your application. If your application is purely designed to be used by others you can ship a merge module or wixlib that they can include inside their MSI and install privately into their program folder, this puts them in charge of making updates if you release a new version. You can also implement this as a full msi to be included in their bootstrapper as a pre-requisite and be handled like any other pre-requisite, ideally this will be installed into a shared location (common files). Updates to this would be created by you but shipped by your customers, or possible auto-updated directly by you. Small updates would be done in place (by msp or msi), major updates that are not backwards compatible would be installed in parallel (upgrade code and install location change) -so you don't break other software installed on the machine. Burn should handle if multiple products have a shared MSI. Your software architecture has to support this of course. -Original Message- From: jeamis [mailto:jonathan.a...@intergraph.com] Sent: 12 March 2013 10:48 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using transforms (regular) to install mulitple times per application What I am trying to do is to allow customer bootstrappers the ability to install my package for thier application. In some cases the customer has two applications (installed in one setup) that use my product. So how can I use a transform that will allow this customer to install my product twice? And also support patches etc My product is delivered as a msi file. http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n7584257/ New_Bitmap_Image.bmp I currently have a msi that implements instance tranforms to do this. If I were using scripts msiexec.exe installs it fine with MSINEWINSTANCE=1 and TRANSFORMS set. And if I were using scripts I could uninstall fine by calling msiexec.exe without the MSINEWINSTANCE=1 parameter. However, using a msiPackage in wix I don't see how I can provide a msiProperty (MSINEWINSTANCE) on Install and not have the msiProperty on uninstall. So we are thinking of abondoning instance transforms and seeing if there is a way to use regular transforms to do the same. Being green on the subject of installer and Wix, I would love some direction on how I can solve this problem. My component is used by several independent applications as well and they want to be able to exist on machines that may have other applications that use my component (thier own copy). - - jon -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-transform s-regular-to-install-mulitple-times-per-application-tp7584257.html Sent from the wix-users mailing list archive at Nabble.com. - - Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users 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. -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Updating the License Agreement
How are you saving your rtf, I would advise using WordPad as that creates very simple rtf files (compared to Word). -Original Message- From: Chaitanya [mailto:chaita...@pointcross.com] Sent: 12 March 2013 05:27 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Updating the License Agreement How can we Know the Code page is suitable for this line.. I tried with 860 also its not working for me. -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: 12 March 2013 09:57 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Updating the License Agreement Chaitanya, My answer would be that your Licence.rtf file contains one or more characters that don't fit into the 1252 codepage. Either change your codepage to match the one that the RTF file was created in, or remove the characters from that file that don't fit into that codepage. Blair From: afor...@cmu.edu To: wix-users@lists.sourceforge.net Date: Mon, 11 Mar 2013 10:29:05 -0400 Subject: Re: [WiX-users] Updating the License Agreement I'm not sure what might be wrong with your code, but here's what I have for a custom license agreement: UIRef Id=WixUI_Minimal / UIRef Id=WixUI_ErrorProgressText / WixVariable Id=WixUILicenseRtf Value=License.rtf / In the same dir as the wxs, the License.rtf file contains my custom text of the agreement. Alain -Original Message- From: Chaitanya [mailto:chaita...@pointcross.com] Sent: March 11, 2013 03:57 To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] Updating the License Agreement Hi, When iam updating the License agreement its is throwing some error called codepage should be-1252'. I updated my codepage but still it is throwing same error. My code is. ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=24F2B50A-BB6B-49D6-B4D3-3DEAC4FA512C Name=test Language=1033 codepage=1252 Version=3.2.5.0 Manufacturer=test UpgradeCode=c5870159-96cb-45a3-82b8-f2a4af250832 Package InstallerVersion=200 Compressed=yes / Property Id=WIXUI_INSTALLDIR Value=ProgramFilesFolder / WixVariable Id=WixUILicenseRtf Overridable=yes Value=C:\Users\Desktop\License.rtf / Media Id=1 Cabinet=media1.cab EmbedCab=yes / !--MajorUpgrade AllowSameVersionUpgrades=yes DowngradeErrorMessage=A VERSION IS ALREADY INSTALLED/-- Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder / Directory Id=INSTALLLOCATION Name=test Component Id=test DiskId=1 Guid=54FD7816-E770-4738-BDD6-EA118326724B File Id=chaitu.txt Name=chaitu.txt Source=C:\Users\Desktop\New folder\smeu.txt/File /Component /Directory /Directory Feature Id=ProductFeature Title=test Level=1 ComponentRef Id=test/ /Feature UIRef Id=WixUI_InstallDir / /Product /Wix Error is: A string was provided with characters that are not available in the specified database code page '1252'. Either change these characters to ones that exist in the database's code page, or update the database's code page by modifying one of the following attributes: Product/@Codepage, Module/@Codepage, Patch/@Codepage, PatchCreation/@Codepage, or WixLocalization/@Codepage How to over come the error Thanks Regards, avg -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea?
My personal point of view: write custom actions in native code, statically link the CRT and have as few dependencies on the machine as possible. Actually, best option is to have no custom actions. smile/ On Mon, Mar 11, 2013 at 9:57 PM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: Which is fine as long as you don't mind the added dependency of .Net. I seem to remember some issues with newer os's not liking the standard .net installer as it is an optional feature of the OS. On Mar 11, 2013, at 9:57 PM, Christopher Painter chr...@iswix.com wrote: Check out C# / DTF for managed custom action support instead of PowerShell. I have millions of successful installations logged and failure caused by DTF are extremely rare in WiX 3.6 / 3.7. In WiX 3.5 there was a bug that resulted in a 1% failure rate. From: Hoover, Jacob jacob.hoo...@greenheck.com Sent: Monday, March 11, 2013 8:29 PM To: Raghu raghu_ti...@yahoo.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Is using Powershell script as a Wix Custom Action agood idea? I wouldn't, simply because some of the difficulties others have reported as well as introducing another dependency to your installer. A simple C++ CA DLL can be compiled for a minimal footprint and has no dependencies. -Original Message- From: Raghu [mailto:raghu_ti...@yahoo.com] Sent: Monday, March 11, 2013 8:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea? Hello Wix users, I have a very simple custom action something on the lines of validating a key as part of setup, the min requirement that the setup to run is on Win2k8 R2+. Now I can achieve the same thing in a dll but I feel its an overkill and is easily achieved in a script, for a while I was pondering over using vbscript until I read the warning in http://blogs.msdn.com/b/robmen/archive/2004/05/20/136530.aspx and decided against vbscript. Could folks point out if doing the same in powershell is ok? Thanks., Raghu -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea?
Classification: Public I agree, however for simple installs, yes having no custom actions is best. But, for installs that require more work, i.e. web sites, databases not using custom actions is not easy... There are a lot of things that WIX can't handle. Steve -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: March-12-13 10:57 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea? My personal point of view: write custom actions in native code, statically link the CRT and have as few dependencies on the machine as possible. Actually, best option is to have no custom actions. smile/ On Mon, Mar 11, 2013 at 9:57 PM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: Which is fine as long as you don't mind the added dependency of .Net. I seem to remember some issues with newer os's not liking the standard .net installer as it is an optional feature of the OS. On Mar 11, 2013, at 9:57 PM, Christopher Painter chr...@iswix.com wrote: Check out C# / DTF for managed custom action support instead of PowerShell. I have millions of successful installations logged and failure caused by DTF are extremely rare in WiX 3.6 / 3.7. In WiX 3.5 there was a bug that resulted in a 1% failure rate. From: Hoover, Jacob jacob.hoo...@greenheck.com Sent: Monday, March 11, 2013 8:29 PM To: Raghu raghu_ti...@yahoo.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Is using Powershell script as a Wix Custom Action agood idea? I wouldn't, simply because some of the difficulties others have reported as well as introducing another dependency to your installer. A simple C++ CA DLL can be compiled for a minimal footprint and has no dependencies. -Original Message- From: Raghu [mailto:raghu_ti...@yahoo.com] Sent: Monday, March 11, 2013 8:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea? Hello Wix users, I have a very simple custom action something on the lines of validating a key as part of setup, the min requirement that the setup to run is on Win2k8 R2+. Now I can achieve the same thing in a dll but I feel its an overkill and is easily achieved in a script, for a while I was pondering over using vbscript until I read the warning in http://blogs.msdn.com/b/robmen/archive/2004/05/20/136530.aspx and decided against vbscript. Could folks point out if doing the same in powershell is ok? Thanks., Raghu -- -- -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -- -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea?
CA's can be built to target CLR 2.0 and beyond. The dependency / fragility concerns are overblown. .NET just offers too much to be ignored. For vendor extensions and performance sensitive (UI control event DoActions) then native is worth it. From: Rob Mensching r...@robmensching.com Sent: Tuesday, March 12, 2013 9:59 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea? My personal point of view: write custom actions in native code, statically link the CRT and have as few dependencies on the machine as possible. Actually, best option is to have no custom actions. smile/ On Mon, Mar 11, 2013 at 9:57 PM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: Which is fine as long as you don't mind the added dependency of .Net. I seem to remember some issues with newer os's not liking the standard .net installer as it is an optional feature of the OS. On Mar 11, 2013, at 9:57 PM, Christopher Painter chr...@iswix.com wrote: Check out C# / DTF for managed custom action support instead of PowerShell. I have millions of successful installations logged and failure caused by DTF are extremely rare in WiX 3.6 / 3.7. In WiX 3.5 there was a bug that resulted in a 1% failure rate. From: Hoover, Jacob jacob.hoo...@greenheck.com Sent: Monday, March 11, 2013 8:29 PM To: Raghu raghu_ti...@yahoo.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Is using Powershell script as a Wix Custom Action agood idea? I wouldn't, simply because some of the difficulties others have reported as well as introducing another dependency to your installer. A simple C++ CA DLL can be compiled for a minimal footprint and has no dependencies. -Original Message- From: Raghu [mailto:raghu_ti...@yahoo.com] Sent: Monday, March 11, 2013 8:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea? Hello Wix users, I have a very simple custom action something on the lines of validating a key as part of setup, the min requirement that the setup to run is on Win2k8 R2+. Now I can achieve the same thing in a dll but I feel its an overkill and is easily achieved in a script, for a while I was pondering over using vbscript until I read the warning in http://blogs.msdn.com/b/robmen/archive/2004/05/20/136530.aspx and decided against vbscript. Could folks point out if doing the same in powershell is ok? Thanks., Raghu -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Bootstrapper - Second Patch does not supersede first Patch
Got anywhere with this? I have the same problem
I don't mind having both patches appear in the add remove - updates side by
side, but the second patch doesn't replace the files at all...
If I install it without the first patch already installed then that patch works
great.
Tomer.
Thanks.
-Original Message-
From: Brian_Covington [mailto:briancoving...@yahoo.com]
Sent: יום ה 15 נובמבר 2012 00:41
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Managed Bootstrapper - Second Patch does not supersede
first Patch
Same results with versions 10.00.35.0004, 10.00.36.0004 (HF1), and
10.00.37.0004 (HF2).
I am changing the bundle version as well as the version of the msi, but still
the second patch for the bundle appears alongside the first one, not replacing
it as I would expect.
Do I need to do something to hide the first patch when the second one is
applied? And if so, how would I undo this when uninstalling the second patch?
As these are cumulative, removable patches, only one entry must exist in the
Installed Updates of ARP.
I do see where it realized the first patch bundle was installed, but did
nothing with it.
Plan 3 packages, action: Install
[0F98:0E38][2012-11-14T16:19:55]: Skipping dependency registration on package
with no dependency providers: Netfx4Full
[0F98:0E38][2012-11-14T16:19:55]: Skipping dependency registration on package
with no dependency providers: S3DInstallPatch
[0F98:0E38][2012-11-14T16:19:55]: Setting string variable
'WixBundleLog_S3DInstallPatch' to value
'C:\Users\sp3dtest\AppData\Local\Temp\PRODUCT_S3D_HotFix_2_20121114161952_{C193CA79-FACC-4874-AF85-6CCC6B10851C}_0_S3DInstallPatch.log'
[0F98:0E38][2012-11-14T16:19:55]: Setting string variable
'WixBundleRollbackLog_S3DInstallPatch' to value
'C:\Users\sp3dtest\AppData\Local\Temp\PRODUCT_S3D_HotFix_2_20121114161952_{C193CA79-FACC-4874-AF85-6CCC6B10851C}_0_S3DInstallPatch_rollback.log'
[0F98:0E38][2012-11-14T16:19:55]: Skipping dependency registration on package
with no dependency providers: RADInstallPatch
[0F98:0E38][2012-11-14T16:19:55]: Planned package: Netfx4Full, state:
Present, default requested: Present, ba requested: Present, execute: None,
rollback: None, cache: No, uncache: No, dependency: None
[0F98:0E38][2012-11-14T16:19:55]: Planned package: S3DInstallPatch, state:
Absent, default requested: Present, ba requested: Present, execute: Install,
rollback: Uninstall, cache: Yes, uncache: No, dependency: None
[0F98:0E38][2012-11-14T16:19:55]: Planned package: RADInstallPatch, state:
Present, default requested: Present, ba requested: Present, execute: None,
rollback: None, cache: No, uncache: No, dependency: None
*[0F98:0E38][2012-11-14T16:19:55]: Planned related bundle:
{1ca42db4-c103-4fa2-ba05-d3c20f8f5d70}, type: Dependent, default requested:
None, ba requested: None, execute: None, rollback: None, dependency: None*
Then in the msi install log, I see
Final Patch Application Order:
MSI (s) (44:2C) [16:20:06:348]: {379A67FF-1175-42B8-B7B7-8F8ED98CA7EB} -
C:\ProgramData\Package
Cache\{379A67FF-1175-42B8-B7B7-8F8ED98CA7EB}\S3DInstallPatch
MSI (s) (44:2C) [16:20:06:349]: Other Patches:
*MSI (s) (44:2C) [16:20:06:349]: Superseded:
{ADC561F5-6FC8-4EA1-8DB1-E79A7F18A7DD} - *
Which I can only assume is the First Patch being superseeded, so it looks like
the MSI is correct, just not the Bootstrapper.
Is no one else facing this problem? Or does no one do cumulative patching?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Managed-Bootstrapper-Second-Patch-does-not-supersede-first-Patch-tp7581779p7581928.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Monitor your physical, virtual and cloud infrastructure from a single web
console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud
infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea?
Before NETFX 4.0 came out it was not possible to build assemblies that targeted NETFX2.0 and beyond. That means, any packages with old managed custom actions in them that are not updated can fail to install by default on newer operating systems (where NETFX2.0 is not on by default). It is difficult to predict what happens with NETFX5.0 or if there is an NETFX5.0. For example, WiX v2.0 is still used today and it's custom actions continue to work on current operating systems as well as they did back then. You can provide mitigations (like make sure your install/repair/patch/uninstall always happens via a bootstrapper) to get your NETFX in the correct state before your MSI with managed custom actions runs. IMHO, the best way to avoid all the issues is to build native code custom actions with as few dependencies as possible. Really, the native part of that is just saying fewer dependencies. Do as you wish. smile/ DTF exists for those that want to write managed custom actions and it will help you do so *correctly* in environments you control. But if you are doing anything platform-like (such as the WiX toolset smile/) keep in mind the depth of your dependencies because the world out there is mean and nasty and setup is supposed to fix it. I really should turn this into a blog entry. smile/ On Tue, Mar 12, 2013 at 8:08 AM, Christopher Painter chr...@iswix.comwrote: CA's can be built to target CLR 2.0 and beyond. The dependency / fragility concerns are overblown. .NET just offers too much to be ignored. For vendor extensions and performance sensitive (UI control event DoActions) then native is worth it. From: Rob Mensching r...@robmensching.com Sent: Tuesday, March 12, 2013 9:59 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea? My personal point of view: write custom actions in native code, statically link the CRT and have as few dependencies on the machine as possible. Actually, best option is to have no custom actions. smile/ On Mon, Mar 11, 2013 at 9:57 PM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: Which is fine as long as you don't mind the added dependency of .Net. I seem to remember some issues with newer os's not liking the standard .net installer as it is an optional feature of the OS. On Mar 11, 2013, at 9:57 PM, Christopher Painter chr...@iswix.com wrote: Check out C# / DTF for managed custom action support instead of PowerShell. I have millions of successful installations logged and failure caused by DTF are extremely rare in WiX 3.6 / 3.7. In WiX 3.5 there was a bug that resulted in a 1% failure rate. From: Hoover, Jacob jacob.hoo...@greenheck.com Sent: Monday, March 11, 2013 8:29 PM To: Raghu raghu_ti...@yahoo.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Is using Powershell script as a Wix Custom Action agood idea? I wouldn't, simply because some of the difficulties others have reported as well as introducing another dependency to your installer. A simple C++ CA DLL can be compiled for a minimal footprint and has no dependencies. -Original Message- From: Raghu [mailto:raghu_ti...@yahoo.com] Sent: Monday, March 11, 2013 8:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea? Hello Wix users, I have a very simple custom action something on the lines of validating a key as part of setup, the min requirement that the setup to run is on Win2k8 R2+. Now I can achieve the same thing in a dll but I feel its an overkill and is easily achieved in a script, for a while I was pondering over using vbscript until I read the warning in http://blogs.msdn.com/b/robmen/archive/2004/05/20/136530.aspx and decided against vbscript. Could folks point out if doing the same in powershell is ok? Thanks., Raghu -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space.
Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea?
Hence why I said native was well suited to vendor extensions. The take a dependency argument goes back a long ways. An example would be the Excel approach vs the VS/DevDiv approach. It would make a good blog provided that you cover the pro's and con's of each approach. FWIW, DTF custom actions can easily be decompiled, examined, tweaked,recompiled and reapplied to an MSI. Try doing that with native. :-) From: Rob Mensching r...@robmensching.com Sent: Tuesday, March 12, 2013 10:27 AM To: Christopher Painter chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea? Before NETFX 4.0 came out it was not possible to build assemblies that targeted NETFX2.0 and beyond. That means, any packages with old managed custom actions in them that are not updated can fail to install by default on newer operating systems (where NETFX2.0 is not on by default). It is difficult to predict what happens with NETFX5.0 or if there is an NETFX5.0. For example, WiX v2.0 is still used today and it's custom actions continue to work on current operating systems as well as they did back then. You can provide mitigations (like make sure your install/repair/patch/uninstall always happens via a bootstrapper) to get your NETFX in the correct state before your MSI with managed custom actions runs. IMHO, the best way to avoid all the issues is to build native code custom actions with as few dependencies as possible. Really, the native part of that is just saying fewer dependencies. Do as you wish. smile/ DTF exists for those that want to write managed custom actions and it will help you do so *correctly* in environments you control. But if you are doing anything platform-like (such as the WiX toolset smile/) keep in mind the depth of your dependencies because the world out there is mean and nasty and setup is supposed to fix it. I really should turn this into a blog entry. smile/ On Tue, Mar 12, 2013 at 8:08 AM, Christopher Painter chr...@iswix.com wrote: CA's can be built to target CLR 2.0 and beyond. The dependency / fragility concerns are overblown. .NET just offers too much to be ignored. For vendor extensions and performance sensitive (UI control event DoActions) then native is worth it. From: Rob Mensching r...@robmensching.com Sent: Tuesday, March 12, 2013 9:59 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea? My personal point of view: write custom actions in native code, statically link the CRT and have as few dependencies on the machine as possible. Actually, best option is to have no custom actions. smile/ On Mon, Mar 11, 2013 at 9:57 PM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: Which is fine as long as you don't mind the added dependency of .Net. I seem to remember some issues with newer os's not liking the standard .net installer as it is an optional feature of the OS. On Mar 11, 2013, at 9:57 PM, Christopher Painter chr...@iswix.com wrote: Check out C# / DTF for managed custom action support instead of PowerShell. I have millions of successful installations logged and failure caused by DTF are extremely rare in WiX 3.6 / 3.7. In WiX 3.5 there was a bug that resulted in a 1% failure rate. From: Hoover, Jacob jacob.hoo...@greenheck.com Sent: Monday, March 11, 2013 8:29 PM To: Raghu raghu_ti...@yahoo.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Is using Powershell script as a Wix Custom Action agood idea? I wouldn't, simply because some of the difficulties others have reported as well as introducing another dependency to your installer. A simple C++ CA DLL can be compiled for a minimal footprint and has no dependencies. -Original Message- From: Raghu [mailto:raghu_ti...@yahoo.com] Sent: Monday, March 11, 2013 8:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea? Hello Wix users, I have a very simple custom action something on the lines of validating a key as part of setup, the min requirement that the setup to run is on Win2k8 R2+. Now I can achieve the same thing in a dll but I feel its an overkill and is easily achieved in a script, for a while I was pondering over using vbscript until I read the warning in http://blogs.msdn.com/b/robmen/archive/2004/05/20/136530.aspx and decided against vbscript. Could folks point out if doing the same in powershell is ok? Thanks., Raghu -- Symantec Endpoint
Re: [WiX-users] How to localize WiX bootstrapper
Thanks, it worked out, the problem was to create the folder structure where WPF bootstrapper is searching for the resources. I updated the .wsx bundle file. From: Payload SourceFile=$(var.BootstrapperBuildPath)de\Application.resources.dll/ To: Payload Name= de\Application.resources.dll SourceFile=$(var.BootstrapperBuildPath)de\Application.resources.dll/ Now it works as expected. / Tomas -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: den 8 mars 2013 18:35 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to localize WiX bootstrapper If you wrote a custom bootstrapper application then it's more a question for the technology you used to create the UI. You'll be better served asking on a forum that supports the technology, in your case it sounds like WPF. On Thu, Mar 7, 2013 at 2:19 AM, Tomas Köhn tomas.k...@cellavision.sewrote: Hi We have created a bootstrapper in WiX for our .msi; and need to localize it. I have failed to find out how to do it, any help is appreciated. I tried to do it in the same way as in WPF: *Before rootVisual resources is loaded, set CultureInfo.DefaultThreadCurrentUICulture and Thread.CurrentThread.CurrentUICulture with new CultureInfo(de-De) *Created directory for German language with the translated resources de/BootStrapperApplication.resources.dll Added the resource as a payload in Bundle.wxs together with all other .dll which is used by the installer BootstrapperApplicationRef Id=ManagedBootstrapperApplicationHost Payload SourceFile=de\CellaVision.CRRS.Setup.Bootstrapper.Application.resourc es.dll/ ... How to tell the bootstrapper which resource to use? / Tomas -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea?
I have successfully executed PowerShell scripts as CustomActions in MSI packages. If you MUST use PowerShell, then all of the warnings concerning difficulty in debugging apply. You MUST fully understand the context under which the script is executing (user context, filesystem and registry redirection, etc). If you have alternatives for your CustomAction, then you should use those alternatives. If you are deploying a native application, then write a native CustomAction. If you are deploying a .NET application, then write a .NET CustomAction. If you MUST use PowerShell to perform a task because the API available to you is a cmdlet provided by thirdparty *AND* you have no other way to perform the same task, then and only then is it appropriate to use a PowerShell script as a CustomAction to perform that task. Don't bother writing .NET code to host the PowerShell engine to avoid using a PowerShell script as that is very, very hard to do correctly. Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com -Original Message- From: Raghu [mailto:raghu_ti...@yahoo.com] Sent: Monday, March 11, 2013 6:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea? Hello Wix users, I have a very simple custom action something on the lines of validating a key as part of setup, the min requirement that the setup to run is on Win2k8 R2+. Now I can achieve the same thing in a dll but I feel its an overkill and is easily achieved in a script, for a while I was pondering over using vbscript until I read the warning in http://blogs.msdn.com/b/robmen/archive/2004/05/20/136530.aspx and decided against vbscript. Could folks point out if doing the same in powershell is ok? Thanks., Raghu -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] TFS 2012 Build failing on HeatDirectory task
Hi, I am looking for some help. We have a Continuous Integration Build that is running a Wix project that I have created. It runs fine locally but when you run the build job it keeps failing. The error that I am getting is: Task HeatDirectory Command: C:\Program Files (x86)\WiX Toolset v3.7\bin\Heat.exe dir C:\Builds\SOMEPATH\obj\Debug\Package\PackageTmp -cg WebProject_Project -dr INSTALLLOCATION -scom -sreg -srd -var var.BasePath -gg -sfrag -out WebProject.wxs Could not load file or assembly 'file:///C:\Program Files (x86)\WiX Toolset v3.7\bin\Heat.exe' or one of its dependencies. An attempt was made to load a program with an incorrect format. at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark stackMark) at System.Reflection.Assembly.LoadFrom(String assemblyFile) at Microsoft.Tools.WindowsInstallerXml.Build.Tasks.WixToolTask.ExecuteToolThread(Object parameters) I can't see anything wrong with the set up and I have installed wix to the server. I have modified the BeforeBuild which is: Target Name=BeforeBuild MSBuild Projects=%(ProjectReference.FullPath) Targets=Package Properties=Configuration=$(Configuration);Platform=AnyCPU Condition='%(ProjectReference.PackageThisProject)'=='True' / PropertyGroup DefineConstantsBasePath=%(ProjectReference.RootDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\PackageTmp\;/DefineConstants LinkerBaseInputPaths%(ProjectReference.RootDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\PackageTmp\/LinkerBaseInputPaths /PropertyGroup HeatDirectory OutputFile=%(ProjectReference.Filename).wxs Directory=%(ProjectReference.RootDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\PackageTmp DirectoryRefId=INSTALLLOCATION ComponentGroupName=%(ProjectReference.Filename)_Project SuppressCom=true SuppressFragments=true SuppressRegistry=true SuppressRootDirectory=true AutoGenerateGuids=false GenerateGuidsNow=true ToolPath=$(WixToolPath) PreprocessorVariable=var.BasePath Condition='%(ProjectReference.PackageThisProject)'=='True' / /Target Also I am using Wix 3.7. Any help is appreciated. Brian -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Execute a custom action only on uninstall?
Steve: Thanks for the reply. I hadn't had a chance to experiment with this till today. I was looking at the two InstallExecuteSequence sections you show below and I guess I'm just not getting what makes the script only execute the customaction only on *UNinstall*, and not on install? Also, is the second example (the one labeled Now let's do something for uninstall:) an addition to the first one as in would both of those code pieces be included to make a working example? Vern On 3/5/2013 1:02 PM, Steven Ogilvie wrote: Classification: Public You use the install sequence to set up your custom actions... So let's say I have custom action 1 which does something during install: CustomAction Id= CA_Set_Something Property=SOME_PROPERTY Value=[ComputerName]/ UI ProgressText Action= CA_Set_Something CA: Setting a property.../ProgressText /UI InstallExecuteSequence Custom Action=CA_Set_Something After=InstallValidateNOT Installed/Custom Now let's do something for uninstall: CustomAction Id=CA_Set_DELETE_SOME_FILE Property= CA_DELETE_SOME_FILE Value=[SOME_PATH]\MyFile.txt|/ CustomAction Id=CA_ DELETE_SOME_FILE BinaryKey=BIN_CustomAction DllEntry=RemoveFileOnUninstall Impersonate=no Execute=deferred Return=ignore/ UI ProgressText Action=CA_ DELETE_SOME_FILE CA: Delete some file.../ProgressText /UI [InstallExecuteSequence] Custom Action= CA_Set_DELETE_SOME_FILE After=InstallValidateInstalled and Not REINSTALL/Custom Custom Action=CA_DELETE_SOME_FILE After=InstallFilesInstalled and Not REINSTALL/Custom Steve -- Vern Graner CNE/CNA/SSE| If the network is down, then you're Senior Systems Engineer| obviously incompetent so why are we Texas Information Services | paying you? Of course, if the network http://www.txis.com| is up, then we obviously don't need Austin Office 512 328-8947 | you, so why are we paying you? ©VLG -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea?
Put another way, I think it's more important to fully, and I do mean fully, understand the MSI model including the declarative and transactional aspects. I've seen far too many installers that ignore all this and then do some crap in a .BAT or .VBS file. It's more important to focus on this then argue the finer points of native vs managed code. As Rob once blogged, the strategic considerations remain but DTF has solved the tactical considerations. From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com Sent: Tuesday, March 12, 2013 12:06 PM To: Raghu raghu_ti...@yahoo.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea? I have successfully executed PowerShell scripts as CustomActions in MSI packages. If you MUST use PowerShell, then all of the warnings concerning difficulty in debugging apply. You MUST fully understand the context under which the script is executing (user context, filesystem and registry redirection, etc). If you have alternatives for your CustomAction, then you should use those alternatives. If you are deploying a native application, then write a native CustomAction. If you are deploying a .NET application, then write a .NET CustomAction. If you MUST use PowerShell to perform a task because the API available to you is a cmdlet provided by thirdparty *AND* you have no other way to perform the same task, then and only then is it appropriate to use a PowerShell script as a CustomAction to perform that task. Don't bother writing .NET code to host the PowerShell engine to avoid using a PowerShell script as that is very, very hard to do correctly. Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com -Original Message- From: Raghu [mailto:raghu_ti...@yahoo.com] Sent: Monday, March 11, 2013 6:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea? Hello Wix users, I have a very simple custom action something on the lines of validating a key as part of setup, the min requirement that the setup to run is on Win2k8 R2+. Now I can achieve the same thing in a dll but I feel its an overkill and is easily achieved in a script, for a while I was pondering over using vbscript until I read the warning in http://blogs.msdn.com/b/robmen/archive/2004/05/20/136530.aspx and decided against vbscript. Could folks point out if doing the same in powershell is ok? Thanks., Raghu -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] calling a soap service during installation
Hi, I am writing an installation that needs to call a soap web service. I was wondering whether anybody has done this using c++ and therefore has any custom actions. I'm using wix 3.8 for reference. Regards Sean. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn: hang after Apply Complete on Vista
I have a bundle built using WiX 3.7.1224.0 that installs 2 MSI files. It works perfectly when run from the desktop on Server 2008 (R1) but when run (with /quiet /norestart) from a service which is logged on as Administrator it installs the last package, logs Apply Complete, result: 0x0, restart: None, ba requested restart: No and then always hangs, with all 3 threads stuck in GetMessageW. It works with 2008R2: is there a known bug with Vista/2008R1? -- Bruce Cran -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Using Update Element of the Bundle?
I want to create a self updating setup.exe with Burn. I hope that using the Update element of the Bundle with Wix 3.7 will work. The Help says this piece wasn't working yet but it looks like you use it for Wix updates. True? Is there a reason you use a feed or was it just convenience? My plan: Set up a folder and file tree off a web server. From the Wix 3.7 source it looks like the UpdateURL attribute of the Bundle element in the refers to the root URL where all subsequent updates of this version of product will be. For example: http://ourhouse/releases/myAppName. Or Is Update Location='' / the critical element? Or are both necessary? For each update we would add a folder under MyAppName with a unique ID such as the setup.exe version number (1.0.0.0, 1.0.0.1 etc) If we have 4 packages per setup.exe would each sub folder have to all of the packages referenced by the bundle? I'm open to other ideas and I'd be happy to contribute code back or to the Help if I am on a useful track? Blaine Wheeler Department of Social and Health Services Project Coordinator SEMS Operations 360.664.5416 blaine.whee...@dshs.wa.gov -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: hang after Apply Complete on Vista
Is the task scheduler enabled and running? If not, try that and see if the problem goes away. On Tue, Mar 12, 2013 at 12:32 PM, Bruce Cran br...@cran.org.uk wrote: I have a bundle built using WiX 3.7.1224.0 that installs 2 MSI files. It works perfectly when run from the desktop on Server 2008 (R1) but when run (with /quiet /norestart) from a service which is logged on as Administrator it installs the last package, logs Apply Complete, result: 0x0, restart: None, ba requested restart: No and then always hangs, with all 3 threads stuck in GetMessageW. It works with 2008R2: is there a known bug with Vista/2008R1? -- Bruce Cran -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Showing bootstrapped MSI UI during repair/change/uninstall
I've been having a lot of trouble getting this to work the way I'd like and I was hoping someone could point me in the right direction. I've got a custom managed BA that is pretty bare bones and chains a .NET prerequisite and my product's MSI. I'm specifying MsiPackage/@DisplayInternalUI=yes and using a combination of custom and off-the-shelf dialogs to collect all the installation details I need. This works great for installations but the MSI UI is suppressed whenever I try to run the BA once the product is already installed. Whichever mode I try to initiate, and whether from the command line or Programs and Features, the MSI UI seems to be shut down, presumably by msiengine.cpp:MsiEngineCalculateInstallUiLevel, which 'suppresses internal UI during uninstall to mimic ARP and msiexec /x behavior'. Although I'm curious why the function enforces that behavior in the first place, I'd really just like to know how I'm supposed take advantage of the MSI's UI during repairs or changes. From the customers' perspective, running the installer a second time doesn't do anything when they should be seeing the change/repair/uninstall dialog that works fine when I run it from the MSI. Thanks in advance for any assistance, and I'd also like to thank you all for the help you've given me with my previous questions. Jacob Baughman -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: hang after Apply Complete on Vista
On 12/03/2013 20:49, Rob Mensching wrote: Is the task scheduler enabled and running? If not, try that and see if the problem goes away. Unfortunately it is already running. I'll do some more debugging to see what's going on. -- Bruce On Tue, Mar 12, 2013 at 12:32 PM, Bruce Cran br...@cran.org.uk wrote: I have a bundle built using WiX 3.7.1224.0 that installs 2 MSI files. It works perfectly when run from the desktop on Server 2008 (R1) but when run (with /quiet /norestart) from a service which is logged on as Administrator it installs the last package, logs Apply Complete, result: 0x0, restart: None, ba requested restart: No and then always hangs, with all 3 threads stuck in GetMessageW. It works with 2008R2: is there a known bug with Vista/2008R1? -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Showing bootstrapped MSI UI during repair/change/uninstall
MSI UI shows basic on uninstall. I thought there was a fix to allow Modify to show Full UI... haven't looked in a long while. On Tue, Mar 12, 2013 at 1:39 PM, Jacob Baughman jbaugh...@atlas-sys.comwrote: I've been having a lot of trouble getting this to work the way I'd like and I was hoping someone could point me in the right direction. I've got a custom managed BA that is pretty bare bones and chains a .NET prerequisite and my product's MSI. I'm specifying MsiPackage/@DisplayInternalUI=yes and using a combination of custom and off-the-shelf dialogs to collect all the installation details I need. This works great for installations but the MSI UI is suppressed whenever I try to run the BA once the product is already installed. Whichever mode I try to initiate, and whether from the command line or Programs and Features, the MSI UI seems to be shut down, presumably by msiengine.cpp:MsiEngineCalculateInstallUiLevel, which 'suppresses internal UI during uninstall to mimic ARP and msiexec /x behavior'. Although I'm curious why the function enforces that behavior in the first place, I'd really just like to know how I'm supposed take advantage of the MSI's UI during repairs or changes. From the customers' perspective, running the installer a second time doesn't do anything when they should be seeing the change/repair/uninstall dialog that works fine when I run it from the MSI. Thanks in advance for any assistance, and I'd also like to thank you all for the help you've given me with my previous questions. Jacob Baughman -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Project with merge modules defeating incremental build facility
This was not a problem in WiX 3.5, but apparently as part of 3.6 support was added to the MSBuild targets for incremental builds by testing the timestamps on all input files to the link task to see if they were newer than the output files. I haven't been able to find any documentation - Bob Arnson mentions it at the end of this thread in May 2011, http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Developer-with-WiX-experience-needed-proper-incremental-build-support-td6380785.html#a6383958 and it's mentioned with a single line in the 3.6 release notes, .wixproj MSBuild projects support incremental build. http://wix.codeplex.com/releases/view/93929 This is a nice facility, although it would have been even nicer with more information and maybe an option to turn it off. Anyway, my problem with it is that when I have the C++ runtime merge module in my project this forces a link to be done every time, even if no input is changed. As far as I can determine the processing of the merge module involves the creation of three temporary files: C:\Users\rp\AppData\Local\Temp\4q3ufw1n\MergeId.49012\F_CENTRAL_msvcp110_x86.D371D00B_69EC_3F8E_A622_74710A89ADC1 C:\Users\rp\AppData\Local\Temp\4q3ufw1n\MergeId.49012\F_CENTRAL_msvcr110_x86.D371D00B_69EC_3F8E_A622_74710A89ADC1 C:\Users\rp\AppData\Local\Temp\4q3ufw1n\MergeId.49012\F_CENTRAL_vccorlib110_x86.D371D00B_69EC_3F8E_A622_74710A89ADC1 I've extracted these filenames from the BindContentsFileList file, and I see them in the MSBuild log. I've never actually seen these files themselves with my own eyes - they are apparently created, consumed, and then deleted so quickly that human reflexes can't cope. But my guess is that they have a timestamp of now, instead of being given a timestamp corresponding to the merge module, and this sabotages the incremental build testing. Which in turn sabotages all of the following incremental builds in the overall project. For now I've modified the WiX target so the link task no longer includes _BindInputs as part of its Inputs= list. Have I understood the situation correctly? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Project-with-merge-modules-defeating-incremental-build-facility-tp7584279.html Sent from the wix-users mailing list archive at Nabble.com. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] issue with fragments in the same project
Hi, I'm currently creating an installer. In one file I have my folder structure: Fragment Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=CONPANYFOLDER Name=SalamanderSoft Directory Id=INSTALLFOLDER Name=Connector /Directory /Directory /Directory /Directory /Fragment in another file in the same project I have fragments with components defined.I've tried to refer to the INSTALLFOLDER element with both the directory/DirectoryRef element but understandably get a lght0091/92. My second file is as follows: Fragment !--Salamander host executable.-- DirectoryRef Id=INSTALLFOLDER Component Id=Salamander.Host.exe Guid=d535001e-c4cb-4043-9e4b-1abdec33d0f2 File Id=Salamander.Host.exeFile Source=..\..\..\bin\obfuscated\Salamander.Host.exe KeyPath=yes Checksum=yes/ /Component /DirectoryRef /FragmentI understand why this is happening, but what is the best way around this? Any help appreciated. Regards Sean. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Bootstrapper - Second Patch does not supersede first Patch
Sorry, no. We are weeks away from having to release and the plan for now is to
not use cumulative patches.
From: Tomer Cohen [via Windows Installer XML (WiX) toolset]
ml-node+s687559n758426...@n2.nabble.com
To: Brian_Covington briancoving...@yahoo.com
Sent: Tuesday, March 12, 2013 10:11 AM
Subject: Re: Managed Bootstrapper - Second Patch does not supersede first Patch
Got anywhere with this? I have the same problem
I don't mind having both patches appear in the add remove - updates side by
side, but the second patch doesn't replace the files at all...
If I install it without the first patch already installed then that patch works
great.
Tomer.
Thanks.
-Original Message-
From: Brian_Covington [mailto:[hidden email]]
Sent: יום ה 15 נובמבר 2012 00:41
To: [hidden email]
Subject: Re: [WiX-users] Managed Bootstrapper - Second Patch does not supersede
first Patch
Same results with versions 10.00.35.0004, 10.00.36.0004 (HF1), and
10.00.37.0004 (HF2).
I am changing the bundle version as well as the version of the msi, but still
the second patch for the bundle appears alongside the first one, not replacing
it as I would expect.
Do I need to do something to hide the first patch when the second one is
applied? And if so, how would I undo this when uninstalling the second patch?
As these are cumulative, removable patches, only one entry must exist in the
Installed Updates of ARP.
I do see where it realized the first patch bundle was installed, but did
nothing with it.
Plan 3 packages, action: Install
[0F98:0E38][2012-11-14T16:19:55]: Skipping dependency registration on package
with no dependency providers: Netfx4Full
[0F98:0E38][2012-11-14T16:19:55]: Skipping dependency registration on package
with no dependency providers: S3DInstallPatch
[0F98:0E38][2012-11-14T16:19:55]: Setting string variable
'WixBundleLog_S3DInstallPatch' to value
'C:\Users\sp3dtest\AppData\Local\Temp\PRODUCT_S3D_HotFix_2_20121114161952_{C193CA79-FACC-4874-AF85-6CCC6B10851C}_0_S3DInstallPatch.log'
[0F98:0E38][2012-11-14T16:19:55]: Setting string variable
'WixBundleRollbackLog_S3DInstallPatch' to value
'C:\Users\sp3dtest\AppData\Local\Temp\PRODUCT_S3D_HotFix_2_20121114161952_{C193CA79-FACC-4874-AF85-6CCC6B10851C}_0_S3DInstallPatch_rollback.log'
[0F98:0E38][2012-11-14T16:19:55]: Skipping dependency registration on package
with no dependency providers: RADInstallPatch
[0F98:0E38][2012-11-14T16:19:55]: Planned package: Netfx4Full, state:
Present, default requested: Present, ba requested: Present, execute: None,
rollback: None, cache: No, uncache: No, dependency: None
[0F98:0E38][2012-11-14T16:19:55]: Planned package: S3DInstallPatch, state:
Absent, default requested: Present, ba requested: Present, execute: Install,
rollback: Uninstall, cache: Yes, uncache: No, dependency: None
[0F98:0E38][2012-11-14T16:19:55]: Planned package: RADInstallPatch, state:
Present, default requested: Present, ba requested: Present, execute: None,
rollback: None, cache: No, uncache: No, dependency: None
*[0F98:0E38][2012-11-14T16:19:55]: Planned related bundle:
{1ca42db4-c103-4fa2-ba05-d3c20f8f5d70}, type: Dependent, default requested:
None, ba requested: None, execute: None, rollback: None, dependency: None*
Then in the msi install log, I see
Final Patch Application Order:
MSI (s) (44:2C) [16:20:06:348]: {379A67FF-1175-42B8-B7B7-8F8ED98CA7EB} -
C:\ProgramData\Package
Cache\{379A67FF-1175-42B8-B7B7-8F8ED98CA7EB}\S3DInstallPatch
MSI (s) (44:2C) [16:20:06:349]: Other Patches:
*MSI (s) (44:2C) [16:20:06:349]: Superseded:
{ADC561F5-6FC8-4EA1-8DB1-E79A7F18A7DD} - *
Which I can only assume is the First Patch being superseeded, so it looks like
the MSI is correct, just not the Bootstrapper.
Is no one else facing this problem? Or does no one do cumulative patching?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Managed-Bootstrapper-Second-Patch-does-not-supersede-first-Patch-tp7581779p7581928.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Monitor your physical, virtual and cloud infrastructure from a single web
console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud
infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security
Re: [WiX-users] issue with fragments in the same project
Where is the ComponentRef to Salamander.Host.exeFile? On Tue, Mar 12, 2013 at 5:31 PM, Sean Farrow sean.far...@seanfarrow.co.ukwrote: Hi, I'm currently creating an installer. In one file I have my folder structure: Fragment Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=CONPANYFOLDER Name=SalamanderSoft Directory Id=INSTALLFOLDER Name=Connector /Directory /Directory /Directory /Directory /Fragment in another file in the same project I have fragments with components defined.I've tried to refer to the INSTALLFOLDER element with both the directory/DirectoryRef element but understandably get a lght0091/92. My second file is as follows: Fragment !--Salamander host executable.-- DirectoryRef Id=INSTALLFOLDER Component Id=Salamander.Host.exe Guid=d535001e-c4cb-4043-9e4b-1abdec33d0f2 File Id=Salamander.Host.exeFile Source=..\..\..\bin\obfuscated\Salamander.Host.exe KeyPath=yes Checksum=yes/ /Component /DirectoryRef /FragmentI understand why this is happening, but what is the best way around this? Any help appreciated. Regards Sean. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
