Re: [WiX-users] Patching a product without ProductVersion property
Patchwiz - Nir Bar Freelance Developer Mail: nir@panel-sw.com Web: www.panel-sw.com - C++ On Windows, Linux and Embedded Platforms - WiX InstallShield -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-a-product-without-ProductVersion-property-tp7600732p7600738.html Sent from the wix-users mailing list archive at Nabble.com. -- 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] Patching a product without ProductVersion property
We have a legacy product that was distributed without ProductVersion authored into the MSI. I don't know how this was done, since ProductVersion is a required property; however I can only fix that in future major-upgrade releases. The problem now is that we want to deliver a patch package for this product. Building the patch fails because the base is missing the ProductVersion. Is there any way to work around that? Thanks, Nir. - Nir Bar Freelance Developer Mail: nir@panel-sw.com Web: www.panel-sw.com - C++ On Windows, Linux and Embedded Platforms - WiX InstallShield -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-a-product-without-ProductVersion-property-tp7600732.html Sent from the wix-users mailing list archive at Nabble.com. -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching a product without ProductVersion property
Patchwiz or Pure WiX style? From: Nir Bar [nir@panel-sw.com] Sent: June 28, 2015 6:34 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching a product without ProductVersion property We have a legacy product that was distributed without ProductVersion authored into the MSI. I don't know how this was done, since ProductVersion is a required property; however I can only fix that in future major-upgrade releases. The problem now is that we want to deliver a patch package for this product. Building the patch fails because the base is missing the ProductVersion. Is there any way to work around that? Thanks, Nir. - Nir Bar Freelance Developer Mail: nir@panel-sw.com Web: www.panel-sw.com - C++ On Windows, Linux and Embedded Platforms - WiX InstallShield -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-a-product-without-ProductVersion-property-tp7600732.html Sent from the wix-users mailing list archive at Nabble.com. -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching with melt.exe and pyro - Custom Action and Merge Module issues.
Hi All, I'm having some success with creating patches using the melt.exe approach. However, I have a stumbling block with custom actions and merge modules, as outlined here: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-Wix-Pure-patch-with-Melt-exe-and-Pyro-exe-fails-td7590635.html#a7590638 I've picked up the development build and ran with the -xn switch, which fixes up the custom action issue, but I am still left with the merge module one. Is there a way around this? Nick Ball -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching and null KeyPath
Generally, I put my service authoring in the same component as the File element
referencing the service binary. That way, the KeyPath is the service binary,
and I don't have these issues.
--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing
Development
Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: vcur...@hotmail.com [mailto:vcur...@hotmail.com]
Sent: Thursday, January 22, 2015 1:42 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching and null KeyPath
The component is a service install\remove. We have not set a KeyPath so I guess
Wix is choosing one, but looking at the component table in InstEd the KeyPath
is null for this component.
The machine (A) that is actioning the component I have found has been through a
few product upgrades whereas the other (B) is a clean install.
Would MigrateFeatureStates be causing the component to be reaction-ed?
Component Id=COMPONENTNAME
Guid={085BDB56-E445-40A0-BEDA-4D35C1A7C6EF}
Directory=INSTALLDIR
CreateFolder/
ConditionOLDAPPFOUND/Condition
ServiceControl Id=sclMU_svcName
Name=svcName
Stop=install
Remove=install
Wait=yes /
/Component
Thanks,
V.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-and-null-KeyPath-tp7598944p7598953.html
Sent from the wix-users mailing list archive at Nabble.com.
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are
intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged
information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching and null KeyPath
Hello. I'm having an issue with a patch behaving differently on two machine with the same target installation. On one machine (A) the component is action-ed during the patch install and on the other (B) it is not. Other components are behaving the same way, I notice that these all have null KeyPaths in the component table. (A) is a Server 2008R2 O/S (B) is a Server 2012 O/S I have tried multiple combinations of ALLUSER, REINSTALL, and REINSTALLMODE switches with no luck. I am actually looking for the (B) behaviour. Any ideas on the difference in behaviour? Action ended 10:26:48: MigrateFeatureStates. Return value 0. MSI (s) (28:A8) [10:26:48:506]: Feature: Server; Installed: Local; Request: Reinstall; Action: Reinstall MSI (s) (28:A8) [10:26:48:506]: Component: COMPONENTNAME; Installed: Local; Request: Local; Action: Local (B) Action ended 163540 MigrateFeatureStates. Return value 0. MSI (s) (1C34) [163540699] Feature Server; Installed Local; Request Reinstall; Action Reinstall MSI (s) (1C34) [163540699] Component COMPONENTNAME; Installed Local; Request Null; Action Null -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-and-null-KeyPath-tp7598944.html Sent from the wix-users mailing list archive at Nabble.com. -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching and null KeyPath
Need more information. What is the authoring for the component installing the file? What is the actual path to the file in both A and B cases? In the authoring, is the file the KeyPath, or is another file or registry entry the KeyPath? -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: vcur...@hotmail.com [mailto:vcur...@hotmail.com] Sent: Wednesday, January 21, 2015 2:19 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching and null KeyPath Hello. I'm having an issue with a patch behaving differently on two machine with the same target installation. On one machine (A) the component is action-ed during the patch install and on the other (B) it is not. Other components are behaving the same way, I notice that these all have null KeyPaths in the component table. (A) is a Server 2008R2 O/S (B) is a Server 2012 O/S I have tried multiple combinations of ALLUSER, REINSTALL, and REINSTALLMODE switches with no luck. I am actually looking for the (B) behaviour. Any ideas on the difference in behaviour? Action ended 10:26:48: MigrateFeatureStates. Return value 0. MSI (s) (28:A8) [10:26:48:506]: Feature: Server; Installed: Local; Request: Reinstall; Action: Reinstall MSI (s) (28:A8) [10:26:48:506]: Component: COMPONENTNAME; Installed: Local; Request: Local; Action: Local (B) Action ended 163540 MigrateFeatureStates. Return value 0. MSI (s) (1C34) [163540699] Feature Server; Installed Local; Request Reinstall; Action Reinstall MSI (s) (1C34) [163540699] Component COMPONENTNAME; Installed Local; Request Null; Action Null -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-and-null-KeyPath-tp7598944.html Sent from the wix-users mailing list archive at Nabble.com. -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching and null KeyPath
The component is a service install\remove. We have not set a KeyPath so I
guess Wix is choosing one, but looking at the component table in InstEd the
KeyPath is null for this component.
The machine (A) that is actioning the component I have found has been
through a few product upgrades whereas the other (B) is a clean install.
Would MigrateFeatureStates be causing the component to be reaction-ed?
Component Id=COMPONENTNAME
Guid={085BDB56-E445-40A0-BEDA-4D35C1A7C6EF}
Directory=INSTALLDIR
CreateFolder/
ConditionOLDAPPFOUND/Condition
ServiceControl Id=sclMU_svcName
Name=svcName
Stop=install
Remove=install
Wait=yes /
/Component
Thanks,
V.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-and-null-KeyPath-tp7598944p7598953.html
Sent from the wix-users mailing list archive at Nabble.com.
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching bundle with MSP
That worked great. For future reference of folks who are perusing the archives, the SP1 RelatedBundle points back to the original bundle's upgrade code, and has a new guid as its upgrade code. I also learned that problems result if the SP1 bundle is built with 3.9 (the original bundle is built with 3.8); when the SP1 patch is uninstalled, a repair operation is triggered and the patch is reinstalled. I don't know if this is a regression or just an incompatibility. You want the OptionalUpdateRegistration element: http://wixtoolset.org/documentation/manual/v3/xsd/wix/optionalupdateregistration.html _ Short replies here. Complete answers over there: http://www.firegiant.com/ -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-bundle-with-MSP-tp7598156p7598183.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching bundle with MSP
Hi all -- things have gone well with our product and Wix 3.8. We are using the stdba and now I'm working on service pack 1, using torch/pyro/etc. via a .msp file. When I create a bundle to install the .msp, a new entry is put into the ARP. Let's say the original bundle is called My App. The new ARP entry is called My App SP1. I was sort of hoping that My App SP1 would only appear in View installed updates under My App. That said, it would seem uninstalling SP1 does the right thing, as does repairing My App (it seems to also re-apply SP1). SP1 has a RelatedBundle with an ID that points back to the original bundle's UpdateCode. The UpgradeCode of SP1 is also set to the original bundle's UpdateCode. I'm not sure what the best practice is here. But the primary question I have is why SP1 is not in View installed updates. Does this point to something flagrantly wrong I am doing, or is this just the way it works when you install .msp's via burn ? Thanks for any assistance ! -Rob -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-bundle-with-MSP-tp7598156.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching bundle with MSP
You want the OptionalUpdateRegistration element: http://wixtoolset.org/documentation/manual/v3/xsd/wix/optionalupdateregistration.html _ Short replies here. Complete answers over there: http://www.firegiant.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching msi
Great! I'll go with option one then. Thanks! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-msi-tp7597706p7597756.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] Patching msi
Hi I have a MyProduct_1.0.0.msi that I'm going to release and I am planning for the patchwork that will come. When doing patch 1.0.1 I'll create a patch comparing the two versions. So far so good... But the patch 1.0.2. Should that be made comparing againts 1.0.0 or 1.0.1? Thanks? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-msi-tp7597706.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
Re: [WiX-users] Patching msi
Thanks! That part I got though. I think you misunderstood my question a bit. The question was on how to generate patch 1.0.2. Should I generate that so that it contains the difference between: 1.0.0 -1.0.1 or 1.0.0 - 1.0.2 -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-msi-tp7597706p7597748.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] Patching Multiple MSI
Hi All, I have 2 msi of the same product(on with version 2.0.0.0 and other with version 2.0.2) Both msi have the same ProductID,UpgradeID I have created 2 small patch (msp) on version 2.0.0.0 to upgrade to 2.0.2 Now i want to create a small patch with version 2.0.3 which should work on both the msi's The newly created patch will work on either of the msi Please help how to create a patch that should work on both the msi's Thanks and Regards Ravi Shankar -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching a Application installed with BURN BA
Hello, I'm just new to WiX and maybe, my question don't make sense, this might be because I'm not an English native speaker. So here my question: I'll like to patch / hotfix an application that was installed by an Bootstrapper Application. One more question, is it enough to simply increment the last number of the file version : 1.0.0.0 to 1.0.0.13906 Will an MSP display in Programs and Features if I don't use a BA? Thank you all! Best Regards, Sascha -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching compressed VS uncompressed image?
To help avoid prompts for source in patch-on-patch scenarios Windows Installer has been known to cache originals of files that are patched, but that behavior can be turned off. Maybe it is off for uncompressed sources? Date: Wed, 8 Jan 2014 13:40:48 -0800 From: dtkob...@gmail.com To: WiX-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching compressed VS uncompressed image? My patches are whole file patches. There is no UI either in the patches either. I'll have to check out the hash table and see what files may mismatch. It never mentions anything about the file it's trying to access, it just keeps mentioning the product it looking for. About every 45 seconds the time out happens and starts the query again. It just goes on and on and on until it decides to apply the patch. There are uninstallable patches as well. I would assume a compressed and uncompressed would behave the same. I get why an uncompressed install might be different in that the files get unpacked in a temp directory for install which the uninstall doesn't need to do. The non stop attempt to access source is what bugs me. If you install from an administrative installation which is uncompressed and then apply my patch 1 and patch 2, I don't get this issue. I now the MSI is marked as administrative installation and it has a reference to the external cab file, but what would make them behave different? Are those entries enough to make it act this way? -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/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] Patching strategy
We've decided to go with the approach you've suggested, and I will look into delta patches to reduce the patch size (although since most of our changed files will be videos, I would guess deltas wouldn't help much). As far as each patch superseding the last, is this something we need to specify in the xml or is it just based on the base MSI we use when building the patch transform (i.e., version 5.0.2 would supersede version 5.0.1 just because we built 5.0.2 as a diff from 5.0; or we need to specifically say that 5.0.2 superseded 5.0.1)? As far as chaining patches together, we are having a small issue (or maybe it's working as designed). We have version 5.0 of a bundle with three MSIs installed initially. We are trying to release version 5.0.1 which consists of two MSPs. After installing, we see version 5.0.1 of the patch in the Installed Updates control panel, but in the Programs and Features control panel (uninstall a program) we see version 5.0. Is this by design? When doing testing of the MSIs and MSPs (installing them directly as opposed to bundling them), I see what I would expect - in both control panels version 5.0.1 is displayed, and when the 5.0.1 update is removed, the Programs and Features control panel goes back to showing 5.0. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-strategy-tp7591585p7591676.html Sent from the wix-users mailing list archive at Nabble.com. -- 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
[WiX-users] Patching compressed VS uncompressed image?
Can someone tell me why patching a uncompressed image requires the attempt
to look for source? I am not prompted asking for credentials, but the
patch log shows it keeps looking for the original install location like
this:
Resolving source.
MSI (s) (9C:30) [08:23:26:466]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (9C:30) [08:23:26:466]: User policy value 'DisableMedia' is 0
MSI (s) (9C:30) [08:23:26:466]: Machine policy value 'AllowLockdownMedia'
is 1
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Looking for sourcelist for
product {F15CB215-59FA-4643-AE03-FDB6655BF13F}
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Adding
{F15CB215-59FA-4643-AE03-FDB6655BF13F}; to potential sourcelist list
(pcode;disk;relpath).
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Now checking product
{F15CB215-59FA-4643-AE03-FDB6655BF13F}
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Attempting to use
LastUsedSource from source list.
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Trying source
\\dkwin8\E\reflection_wit15_trunk\installers\Alloy\release_base_uncomp608\x86\prod\2014\.
MSI (s) (9C:30) [08:24:13:562]: Note: 1: 1314 2:
\\dkwin8\E\reflection_wit15_trunk\installers\Alloy\release_base_uncomp608\x86\prod\2014\
MSI (s) (9C:30) [08:24:13:562]: ConnectToSource: CreatePath/CreateFilePath
failed with: -2147483648 1314 -2147483648
MSI (s) (9C:30) [08:24:13:562]: ConnectToSource (con't):
CreatePath/CreateFilePath failed with: -2147483648 -2147483648
MSI (s) (9C:30) [08:24:13:562]: SOURCEMGMT: net source
'\\dkwin8\E\reflection_wit15_trunk\installers\Alloy\release_base_uncomp608\x86\prod\2014\'
is invalid.
MSI (s) (9C:30) [08:24:13:562]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:13:562]: SOURCEMGMT: Processing net source list.
MSI (s) (9C:30) [08:24:13:562]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:13:562]: SOURCEMGMT: Processing media source list.
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 2203 2: 3: -2147287037
MSI (s) (9C:30) [08:24:14:638]: SOURCEMGMT: Source is invalid due to
missing/inaccessible package.
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:14:638]: SOURCEMGMT: Processing URL source list.
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1402 2: UNKNOWN\URL 3: 2
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1706 2: 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:14:638]: SOURCEMGMT: Failed to resolve source
MSI (s) (9C:30) [08:24:14:638]: Failed to generate patch cache opcodes for:
{F15CB215-59FA-4643-AE03-FDB6655BF13F} product
MSI (s) (9C:30) [08:24:14:638]: Resolving source.
... and it seems to loop for hours.
The cached MSI is on the machine as isn't missing. I've read some other
posts where this was the case.
I see the Resolve source text, but I don't have the ResolveSource action in
my MSI. It continues to look with this same text until some time it
decides to proceed with applying the patch. It could take a few hours or a
day and it finally applies successfully.
To give some background, I am installing an uncompressed image (I built it
uncompressed and it's not an administrative installation uncompress image)
from a UNC path (mapped drive doesn't matter either). I've then
disconnected from that source (rebooted to make sure it can't connect).
I've then created 2 patches. Lets just say patch 1 and patch 2. My first
patch applies in less than 5 minutes. My second patch is what has this
problem. If I leave it connected to the original source location, the
second patch applies in under five minutes as well.
If I create the same install image but have a compressed image (all files
are in an external cab file), then disconnect from source and apply patches
1 and 2 (which were rebuilt with the compressed image build), it never
loops like the patch log above. The second patch applies in under 5
minutes.
Is this normal behavior? It seems like the installer either needs to
prompt me for credentials to original source or move on and apply my patch.
Taking hours to apply the patch is not acceptable. I am baffled by this
behavior.
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching compressed VS uncompressed image?
It could be useful to examine the log where the patching accesses the
network MSI to see what actually happens. Typical reasons include installed
files that no longer match the cached MSI. For example the cached (MSI plus
patches) has entries in the file table that say the version of the file on
disk is one thing, but actually on disk it's something else. Windows
doesn't know whether the patch should be applied until it repairs the
install and gets the right file to do the version test. This is why
version lying is a bad idea. Similar things happen with data files with
mismatched file hashes. That's about all I can think of right now. If
the patch is uninstallable the behavior is a bit different. The timeout is
more like a network/TCP timeout - are the times the same or do they get
larger after each failure?
Does the patch have a UI? If it's trying to resolve the source inside the
execute sequence it may not pop up a UI there, where I'd expect that it
would in the UI sequence, assuming of course it knows that early that the
source is required.
Phil Wilson
On Wed, Jan 8, 2014 at 7:47 AM, darenko6874 . dtkob...@gmail.com wrote:
Can someone tell me why patching a uncompressed image requires the attempt
to look for source? I am not prompted asking for credentials, but the
patch log shows it keeps looking for the original install location like
this:
Resolving source.
MSI (s) (9C:30) [08:23:26:466]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (9C:30) [08:23:26:466]: User policy value 'DisableMedia' is 0
MSI (s) (9C:30) [08:23:26:466]: Machine policy value 'AllowLockdownMedia'
is 1
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Looking for sourcelist for
product {F15CB215-59FA-4643-AE03-FDB6655BF13F}
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Adding
{F15CB215-59FA-4643-AE03-FDB6655BF13F}; to potential sourcelist list
(pcode;disk;relpath).
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Now checking product
{F15CB215-59FA-4643-AE03-FDB6655BF13F}
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Attempting to use
LastUsedSource from source list.
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Trying source
\\dkwin8\E\reflection_wit15_trunk\installers\Alloy\release_base_uncomp608\x86\prod\2014\.
MSI (s) (9C:30) [08:24:13:562]: Note: 1: 1314 2:
\\dkwin8\E\reflection_wit15_trunk\installers\Alloy\release_base_uncomp608\x86\prod\2014\
MSI (s) (9C:30) [08:24:13:562]: ConnectToSource: CreatePath/CreateFilePath
failed with: -2147483648 1314 -2147483648
MSI (s) (9C:30) [08:24:13:562]: ConnectToSource (con't):
CreatePath/CreateFilePath failed with: -2147483648 -2147483648
MSI (s) (9C:30) [08:24:13:562]: SOURCEMGMT: net source
'\\dkwin8\E\reflection_wit15_trunk\installers\Alloy\release_base_uncomp608\x86\prod\2014\'
is invalid.
MSI (s) (9C:30) [08:24:13:562]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:13:562]: SOURCEMGMT: Processing net source list.
MSI (s) (9C:30) [08:24:13:562]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:13:562]: SOURCEMGMT: Processing media source list.
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 2203 2: 3: -2147287037
MSI (s) (9C:30) [08:24:14:638]: SOURCEMGMT: Source is invalid due to
missing/inaccessible package.
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:14:638]: SOURCEMGMT: Processing URL source list.
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1402 2: UNKNOWN\URL 3: 2
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1706 2: 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:14:638]: SOURCEMGMT: Failed to resolve source
MSI (s) (9C:30) [08:24:14:638]: Failed to generate patch cache opcodes for:
{F15CB215-59FA-4643-AE03-FDB6655BF13F} product
MSI (s) (9C:30) [08:24:14:638]: Resolving source.
... and it seems to loop for hours.
The cached MSI is on the machine as isn't missing. I've read some other
posts where this was the case.
I see the Resolve source text, but I don't have the ResolveSource action in
my MSI. It continues to look with this same text until some time it
decides to proceed with applying the patch. It could take a few hours or a
day and it finally applies successfully.
To give some background, I am installing an uncompressed image (I built it
uncompressed and it's not an administrative installation uncompress image)
from a UNC path (mapped drive doesn't matter either). I've then
disconnected from that source (rebooted to make sure it can't connect).
I've then created 2 patches. Lets just say patch 1 and patch 2. My first
patch applies in less than 5 minutes. My second patch is what has this
problem. If I leave it connected to the original source location, the
second patch applies in under five minutes as well.
If I create the same install image but have a compressed image (all files
are in an external cab file), then disconnect from source and apply patches
1
Re: [WiX-users] Patching compressed VS uncompressed image?
Are your patches delta or whole file?
Date: Wed, 8 Jan 2014 10:46:06 -0800
From: phildgwil...@gmail.com
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching compressed VS uncompressed image?
It could be useful to examine the log where the patching accesses the
network MSI to see what actually happens. Typical reasons include installed
files that no longer match the cached MSI. For example the cached (MSI plus
patches) has entries in the file table that say the version of the file on
disk is one thing, but actually on disk it's something else. Windows
doesn't know whether the patch should be applied until it repairs the
install and gets the right file to do the version test. This is why
version lying is a bad idea. Similar things happen with data files with
mismatched file hashes. That's about all I can think of right now. If
the patch is uninstallable the behavior is a bit different. The timeout is
more like a network/TCP timeout - are the times the same or do they get
larger after each failure?
Does the patch have a UI? If it's trying to resolve the source inside the
execute sequence it may not pop up a UI there, where I'd expect that it
would in the UI sequence, assuming of course it knows that early that the
source is required.
Phil Wilson
On Wed, Jan 8, 2014 at 7:47 AM, darenko6874 . dtkob...@gmail.com wrote:
Can someone tell me why patching a uncompressed image requires the attempt
to look for source? I am not prompted asking for credentials, but the
patch log shows it keeps looking for the original install location like
this:
Resolving source.
MSI (s) (9C:30) [08:23:26:466]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (9C:30) [08:23:26:466]: User policy value 'DisableMedia' is 0
MSI (s) (9C:30) [08:23:26:466]: Machine policy value 'AllowLockdownMedia'
is 1
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Looking for sourcelist for
product {F15CB215-59FA-4643-AE03-FDB6655BF13F}
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Adding
{F15CB215-59FA-4643-AE03-FDB6655BF13F}; to potential sourcelist list
(pcode;disk;relpath).
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Now checking product
{F15CB215-59FA-4643-AE03-FDB6655BF13F}
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Attempting to use
LastUsedSource from source list.
MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Trying source
\\dkwin8\E\reflection_wit15_trunk\installers\Alloy\release_base_uncomp608\x86\prod\2014\.
MSI (s) (9C:30) [08:24:13:562]: Note: 1: 1314 2:
\\dkwin8\E\reflection_wit15_trunk\installers\Alloy\release_base_uncomp608\x86\prod\2014\
MSI (s) (9C:30) [08:24:13:562]: ConnectToSource: CreatePath/CreateFilePath
failed with: -2147483648 1314 -2147483648
MSI (s) (9C:30) [08:24:13:562]: ConnectToSource (con't):
CreatePath/CreateFilePath failed with: -2147483648 -2147483648
MSI (s) (9C:30) [08:24:13:562]: SOURCEMGMT: net source
'\\dkwin8\E\reflection_wit15_trunk\installers\Alloy\release_base_uncomp608\x86\prod\2014\'
is invalid.
MSI (s) (9C:30) [08:24:13:562]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:13:562]: SOURCEMGMT: Processing net source list.
MSI (s) (9C:30) [08:24:13:562]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:13:562]: SOURCEMGMT: Processing media source list.
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 2203 2: 3: -2147287037
MSI (s) (9C:30) [08:24:14:638]: SOURCEMGMT: Source is invalid due to
missing/inaccessible package.
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:14:638]: SOURCEMGMT: Processing URL source list.
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1402 2: UNKNOWN\URL 3: 2
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1706 2: 3: 2014R1c.msi
MSI (s) (9C:30) [08:24:14:638]: SOURCEMGMT: Failed to resolve source
MSI (s) (9C:30) [08:24:14:638]: Failed to generate patch cache opcodes for:
{F15CB215-59FA-4643-AE03-FDB6655BF13F} product
MSI (s) (9C:30) [08:24:14:638]: Resolving source.
... and it seems to loop for hours.
The cached MSI is on the machine as isn't missing. I've read some other
posts where this was the case.
I see the Resolve source text, but I don't have the ResolveSource action in
my MSI. It continues to look with this same text until some time it
decides to proceed with applying the patch. It could take a few hours or a
day and it finally applies successfully.
To give some background, I am installing an uncompressed image (I built it
uncompressed and it's not an administrative installation uncompress image)
from a UNC path (mapped drive doesn't matter either). I've then
disconnected from that source (rebooted to make sure it can't connect).
I've then created 2 patches. Lets just say patch 1 and patch 2. My first
patch applies in less than 5 minutes. My second
Re: [WiX-users] Patching compressed VS uncompressed image?
My patches are whole file patches. There is no UI either in the patches either. I'll have to check out the hash table and see what files may mismatch. It never mentions anything about the file it's trying to access, it just keeps mentioning the product it looking for. About every 45 seconds the time out happens and starts the query again. It just goes on and on and on until it decides to apply the patch. There are uninstallable patches as well. I would assume a compressed and uncompressed would behave the same. I get why an uncompressed install might be different in that the files get unpacked in a temp directory for install which the uninstall doesn't need to do. The non stop attempt to access source is what bugs me. If you install from an administrative installation which is uncompressed and then apply my patch 1 and patch 2, I don't get this issue. I now the MSI is marked as administrative installation and it has a reference to the external cab file, but what would make them behave different? Are those entries enough to make it act this way? -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching strategy
This sounds like a good way to start at least. My one concern is what happens when the accumulated patches start to get large enough to make size a concern? Lets say the original data is 2GB, and every month we need to release a patch that changes 5% of it. After 5 months we're up to a 500MB accumulated patch. Would it be possible to release a small burn bootstrapper that detects which patches are installed and only downloads the ones that the user doesn't already have? Thanks! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-strategy-tp7591585p7591600.html Sent from the wix-users mailing list archive at Nabble.com. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching strategy
If you create whole file patches then you might get that size issue, but patches can be smaller, the delta between the files. I don't know if Burn can do that, but the question is: how does the customer know when to run it? It's not too difficult for the app to call a company web service passing the ProductCodes and ProductVersions of what's installed and having it tell you if there are updates to download, but it does take that infrastructure work. Phil Wilson On Mon, Jan 6, 2014 at 9:03 AM, KG kelly.gr...@toltech.net wrote: This sounds like a good way to start at least. My one concern is what happens when the accumulated patches start to get large enough to make size a concern? Lets say the original data is 2GB, and every month we need to release a patch that changes 5% of it. After 5 months we're up to a 500MB accumulated patch. Would it be possible to release a small burn bootstrapper that detects which patches are installed and only downloads the ones that the user doesn't already have? Thanks! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-strategy-tp7591585p7591600.html Sent from the wix-users mailing list archive at Nabble.com. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching strategy
The flip side of this would be incremental patching. Release a RTM version and then all servicing from there would be handled as a patch. The down side is the patches being cached over time would bloat the local system, so you'd want to consider doing a major upgrade every so often to clean out all of the patches. I'm in process of getting self-updating bundles in 3.9 and I have a pull request for the core changes in place. If accepted, I intend on doing another pull request for WixStdBA to be able to self-update. Note, I just completed the changes that were fleshed out but incomplete. My implementation relies on the Update element pointing to an Atom feed containing a list of possible updates for the application. It's left up to the BA to process each update and decide if the update is applicable or not. -Original Message- From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: Monday, January 06, 2014 3:46 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Patching strategy If you create whole file patches then you might get that size issue, but patches can be smaller, the delta between the files. I don't know if Burn can do that, but the question is: how does the customer know when to run it? It's not too difficult for the app to call a company web service passing the ProductCodes and ProductVersions of what's installed and having it tell you if there are updates to download, but it does take that infrastructure work. Phil Wilson On Mon, Jan 6, 2014 at 9:03 AM, KG kelly.gr...@toltech.net wrote: This sounds like a good way to start at least. My one concern is what happens when the accumulated patches start to get large enough to make size a concern? Lets say the original data is 2GB, and every month we need to release a patch that changes 5% of it. After 5 months we're up to a 500MB accumulated patch. Would it be possible to release a small burn bootstrapper that detects which patches are installed and only downloads the ones that the user doesn't already have? Thanks! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching -strategy-tp7591585p7591600.html Sent from the wix-users mailing list archive at Nabble.com. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.c lktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching strategy
The simplest strategy for maintenance per MSI is to build a single accumulating patch that includes and supersedes previous patches. You build an updated MSI to create the patch, and the patch is therefore the changes between the original shipped MSI and the new MSI. Then you have a max of three patches for your three MSIs at any point in time. New customers (and that includes existing customers of the old product) should get something that will major upgrade the old MSIs. This is not likely to be the same MSI that you use to build the patches with because: 1 Patches shouldn't do a major upgrade, which they would if you built the patch as a diff between the original MSI and the major upgrade for new customers. 2. Your app (and maybe some new data) may have new features that you want to ship only to new customers. That means that you'll be building maintenance-only MSIs to ship patches and new product MSIs with new customers. That seems to be typical and effective practice in my experience. Phil Wilson On Fri, Jan 3, 2014 at 10:23 PM, KG kelly.gr...@toltech.net wrote: I am implementing a new installer for a product that needs to include several GB of data. I'm planning on having a single MSI for the application, several MSIs for the data, and using burn to chain everything together. The data will change periodically and updates will be delivered online, so patching is a must. I've never had to implement patches in a user facing product before, and am confused about the following: The first installer will obviously be very large (as all of the data must be included). Once we start releasing updates, do we release a full update with all of the data for new users alongside a patch update for existing users? Is there a way to just release the patches and have the bootstrapper download the initial msi if it's being installed by a new user? Or do we always download the initial data msi to keep the user experience consistent (ie, the first installer would be very small, but download the full data)? Any advice would be greatly appreciated! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-strategy-tp7591585.html Sent from the wix-users mailing list archive at Nabble.com. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching strategy
I am implementing a new installer for a product that needs to include several GB of data. I'm planning on having a single MSI for the application, several MSIs for the data, and using burn to chain everything together. The data will change periodically and updates will be delivered online, so patching is a must. I've never had to implement patches in a user facing product before, and am confused about the following: The first installer will obviously be very large (as all of the data must be included). Once we start releasing updates, do we release a full update with all of the data for new users alongside a patch update for existing users? Is there a way to just release the patches and have the bootstrapper download the initial msi if it's being installed by a new user? Or do we always download the initial data msi to keep the user experience consistent (ie, the first installer would be very small, but download the full data)? Any advice would be greatly appreciated! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-strategy-tp7591585.html Sent from the wix-users mailing list archive at Nabble.com. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching with Burn - What makes my feature become advertise?
Hi, I am implementing removable patches with Burn Such that if I Install RTM, HF1, HF2 then both HFs should be visible And when I uninstall HF2 ,the machine will return to the state where RTM, HF1 was installed. All my HF are cumulative and I build the HF against RTM only, Meaning HF2 will target RTM Based on the input I got from several developers in this forum I am doing the following: In the main bundle I am using ReleatedBundle with Action=Detect. In HF i am using ReleatedBundle with Action=Patch. The Id of ReleatedBundle is shared by all bundles and it is different from the upgrade code. Each HF bundle has its own upgrade code. My bundle contain either MSI for RTM or MSP for HF. When I create a new MSP i change the version of ALL(this is a requirement) my dlls,and create a MSI with new product version(is this correct?) and them using PCP i create a MSP All MSP are of type of Windows installer QFE. Questions: 1.If I install RTM and HF1 and then remove HF1 ,Then when uninstalling RTM all files left on the machine, Looking into the log file I see that bundle detect that my features become advertised So RTM will not install them If I don't remove HF1 then uninstall of RTM is working!. Can anyone think of a reason why features become advertised if i uninstall HF1? 2.In my patch log i see something like this Overwrite; Won't patch; When should I see Will Patch? Thanks in advance -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-with-Burn-What-makes-my-feature-become-advertise-tp7590910.html Sent from the wix-users mailing list archive at Nabble.com. -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching with Burn - What makes my feature become advertise?
Features become advertised when the component rules are broken. To ensure that this issue doesn't happen, set the property MSIENFORCEUPGRADECOMPONENTRULES to 1 (the attempt to patch will instead have failed, and a verbose log would tell you what the offending component rule violation was). Sometime I think we should set that all the time, unless an explicit opt-out is used in the authoring... To workaround this issue once it happens, run a repair. -Blair Date: Sun, 24 Nov 2013 11:24:11 -0800 From: tomer.d...@intergraph.com To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching with Burn - What makes my feature become advertise? Hi, I am implementing removable patches with Burn Such that if I Install RTM, HF1, HF2 then both HFs should be visible And when I uninstall HF2 ,the machine will return to the state where RTM, HF1 was installed. All my HF are cumulative and I build the HF against RTM only, Meaning HF2 will target RTM Based on the input I got from several developers in this forum I am doing the following: In the main bundle I am using ReleatedBundle with Action=Detect. In HF i am using ReleatedBundle with Action=Patch. The Id of ReleatedBundle is shared by all bundles and it is different from the upgrade code. Each HF bundle has its own upgrade code. My bundle contain either MSI for RTM or MSP for HF. When I create a new MSP i change the version of ALL(this is a requirement) my dlls,and create a MSI with new product version(is this correct?) and them using PCP i create a MSP All MSP are of type of Windows installer QFE. Questions: 1.If I install RTM and HF1 and then remove HF1 ,Then when uninstalling RTM all files left on the machine, Looking into the log file I see that bundle detect that my features become advertised So RTM will not install them If I don't remove HF1 then uninstall of RTM is working!. Can anyone think of a reason why features become advertised if i uninstall HF1? 2.In my patch log i see something like this Overwrite; Won't patch; When should I see Will Patch? Thanks in advance -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-with-Burn-What-makes-my-feature-become-advertise-tp7590910.html Sent from the wix-users mailing list archive at Nabble.com. -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching with BURN-how a patch knows about original install folder?
Use the WiX remember property pattern if you want to preserve the value of INSTALLFOLDER from the original install. Phil Wilson On Tue, Oct 22, 2013 at 10:53 AM, Dror, Tomer tomer.d...@intergraph.comwrote: Some of my registry keys use values from the Directory structure: Directory Id=TARGETDIR Name=SourceDir Directory Id=INSTALLFOLDER Name=Intergraph PPM SDKs Directory Id=MA Name=SDK Directory Id=Documents Name=Documents/ /Directory /Directory /Directory RegistryKey Root=HKLM Key=SOFTWARE RegistryKey Key=Intergraph RegistryKey Key=SDK RegistryValue Name=Path Type=string Value=[Documents] /RegistryKey /RegistryKey /RegistryKey When applying a patch i am loosing the value of the Documents folder in the Path registry value. because i only asked for a path in the RTM which is passed to INSTALLFOLDER msi property Tomer Dror Intergraph Corporation. Intergraph Israel. P: +972 (4) 8779191-1222 Skype:tomer.dee http://www.intergraph.com . From: Phil Wilson [phildgwil...@gmail.com] Sent: Tuesday, October 22, 2013 7:15 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Patching with BURN-how a patch knows about original install folder? A patch that is an update to installed components doesn't need to know folder locations unless you need to specify them for some other reason. For an update of component C-Guid of product code P-Guid it can locate the path to any component (as can any program) by calling MsiGetComponentPath (P-Guid, C-Guid...). This is one of the reasons that a having each file be the key of its component is a good thing. Phil Wilson On Tue, Oct 22, 2013 at 7:40 AM, tom tomer.d...@intergraph.com wrote: I wonder when running a patch bundle how the patch bundle (acatually the MSP) knows what is the install folder used by the RTM? Looks like we are missing this values in the MSP and many of the registration we do use a directory defined in wix msp project Thanks in advance -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-with-BURN-how-a-patch-knows-about-original-install-folder-tp7589894.html Sent from the wix-users mailing list archive at Nabble.com. -- 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=60135991iu=/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=60135991iu=/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=60135991iu=/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=60135991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching with BURN-how a patch knows about original install folder?
Phil Thanks How come this not needed for pure MSP? Tomer Dror Intergraph Corporation. Intergraph Israel. P: +972 (4) 8779191-1222 Skype:tomer.dee http://www.intergraph.com . From: Phil Wilson [phildgwil...@gmail.com] Sent: Wednesday, October 23, 2013 7:04 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Patching with BURN-how a patch knows about original install folder? Use the WiX remember property pattern if you want to preserve the value of INSTALLFOLDER from the original install. Phil Wilson On Tue, Oct 22, 2013 at 10:53 AM, Dror, Tomer tomer.d...@intergraph.comwrote: Some of my registry keys use values from the Directory structure: Directory Id=TARGETDIR Name=SourceDir Directory Id=INSTALLFOLDER Name=Intergraph PPM SDKs Directory Id=MA Name=SDK Directory Id=Documents Name=Documents/ /Directory /Directory /Directory RegistryKey Root=HKLM Key=SOFTWARE RegistryKey Key=Intergraph RegistryKey Key=SDK RegistryValue Name=Path Type=string Value=[Documents] /RegistryKey /RegistryKey /RegistryKey When applying a patch i am loosing the value of the Documents folder in the Path registry value. because i only asked for a path in the RTM which is passed to INSTALLFOLDER msi property Tomer Dror Intergraph Corporation. Intergraph Israel. P: +972 (4) 8779191-1222 Skype:tomer.dee http://www.intergraph.com . From: Phil Wilson [phildgwil...@gmail.com] Sent: Tuesday, October 22, 2013 7:15 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Patching with BURN-how a patch knows about original install folder? A patch that is an update to installed components doesn't need to know folder locations unless you need to specify them for some other reason. For an update of component C-Guid of product code P-Guid it can locate the path to any component (as can any program) by calling MsiGetComponentPath (P-Guid, C-Guid...). This is one of the reasons that a having each file be the key of its component is a good thing. Phil Wilson On Tue, Oct 22, 2013 at 7:40 AM, tom tomer.d...@intergraph.com wrote: I wonder when running a patch bundle how the patch bundle (acatually the MSP) knows what is the install folder used by the RTM? Looks like we are missing this values in the MSP and many of the registration we do use a directory defined in wix msp project Thanks in advance -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-with-BURN-how-a-patch-knows-about-original-install-folder-tp7589894.html Sent from the wix-users mailing list archive at Nabble.com. -- 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=60135991iu=/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=60135991iu=/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=60135991iu=/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
Re: [WiX-users] Patching with BURN-how a patch knows about original install folder?
...because of my previous comment. Windows Installer knows where every component's key file is installed, so you don't need to tell it the location of the installed files. Phil Wilson On Wed, Oct 23, 2013 at 10:15 AM, Dror, Tomer tomer.d...@intergraph.comwrote: Phil Thanks How come this not needed for pure MSP? Tomer Dror Intergraph Corporation. Intergraph Israel. P: +972 (4) 8779191-1222 Skype:tomer.dee http://www.intergraph.com . From: Phil Wilson [phildgwil...@gmail.com] Sent: Wednesday, October 23, 2013 7:04 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Patching with BURN-how a patch knows about original install folder? Use the WiX remember property pattern if you want to preserve the value of INSTALLFOLDER from the original install. Phil Wilson On Tue, Oct 22, 2013 at 10:53 AM, Dror, Tomer tomer.d...@intergraph.com wrote: Some of my registry keys use values from the Directory structure: Directory Id=TARGETDIR Name=SourceDir Directory Id=INSTALLFOLDER Name=Intergraph PPM SDKs Directory Id=MA Name=SDK Directory Id=Documents Name=Documents/ /Directory /Directory /Directory RegistryKey Root=HKLM Key=SOFTWARE RegistryKey Key=Intergraph RegistryKey Key=SDK RegistryValue Name=Path Type=string Value=[Documents] /RegistryKey /RegistryKey /RegistryKey When applying a patch i am loosing the value of the Documents folder in the Path registry value. because i only asked for a path in the RTM which is passed to INSTALLFOLDER msi property Tomer Dror Intergraph Corporation. Intergraph Israel. P: +972 (4) 8779191-1222 Skype:tomer.dee http://www.intergraph.com . From: Phil Wilson [phildgwil...@gmail.com] Sent: Tuesday, October 22, 2013 7:15 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Patching with BURN-how a patch knows about original install folder? A patch that is an update to installed components doesn't need to know folder locations unless you need to specify them for some other reason. For an update of component C-Guid of product code P-Guid it can locate the path to any component (as can any program) by calling MsiGetComponentPath (P-Guid, C-Guid...). This is one of the reasons that a having each file be the key of its component is a good thing. Phil Wilson On Tue, Oct 22, 2013 at 7:40 AM, tom tomer.d...@intergraph.com wrote: I wonder when running a patch bundle how the patch bundle (acatually the MSP) knows what is the install folder used by the RTM? Looks like we are missing this values in the MSP and many of the registration we do use a directory defined in wix msp project Thanks in advance -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-with-BURN-how-a-patch-knows-about-original-install-folder-tp7589894.html Sent from the wix-users mailing list archive at Nabble.com. -- 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=60135991iu=/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=60135991iu=/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=60135991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users
Re: [WiX-users] Patching with BURN-how a patch knows about original install folder?
Do you suggest that I should use something like [$componentkey] in the value instead of [Documents] directory id? RegistryKey Key=SDK RegistryValue Name=Path Type=string Value=[Documents] In any case i dont understand what will be the value of INSTALLFOLDER in pure msp? Directory Id=TARGETDIR Name=SourceDir Directory Id=INSTALLFOLDER Name=Intergraph PPM SDKs Directory Id=MA Name=SDK Directory Id=Documents Name=Documents/ /Directory /Directory /Directory Tomer Dror Intergraph Corporation. Intergraph Israel. P: +972 (4) 8779191-1222 Skype:tomer.dee http://www.intergraph.com . From: Phil Wilson [phildgwil...@gmail.com] Sent: Wednesday, October 23, 2013 8:51 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Patching with BURN-how a patch knows about original install folder? ...because of my previous comment. Windows Installer knows where every component's key file is installed, so you don't need to tell it the location of the installed files. Phil Wilson On Wed, Oct 23, 2013 at 10:15 AM, Dror, Tomer tomer.d...@intergraph.comwrote: Phil Thanks How come this not needed for pure MSP? Tomer Dror Intergraph Corporation. Intergraph Israel. P: +972 (4) 8779191-1222 Skype:tomer.dee http://www.intergraph.com . From: Phil Wilson [phildgwil...@gmail.com] Sent: Wednesday, October 23, 2013 7:04 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Patching with BURN-how a patch knows about original install folder? Use the WiX remember property pattern if you want to preserve the value of INSTALLFOLDER from the original install. Phil Wilson On Tue, Oct 22, 2013 at 10:53 AM, Dror, Tomer tomer.d...@intergraph.com wrote: Some of my registry keys use values from the Directory structure: Directory Id=TARGETDIR Name=SourceDir Directory Id=INSTALLFOLDER Name=Intergraph PPM SDKs Directory Id=MA Name=SDK Directory Id=Documents Name=Documents/ /Directory /Directory /Directory RegistryKey Root=HKLM Key=SOFTWARE RegistryKey Key=Intergraph RegistryKey Key=SDK RegistryValue Name=Path Type=string Value=[Documents] /RegistryKey /RegistryKey /RegistryKey When applying a patch i am loosing the value of the Documents folder in the Path registry value. because i only asked for a path in the RTM which is passed to INSTALLFOLDER msi property Tomer Dror Intergraph Corporation. Intergraph Israel. P: +972 (4) 8779191-1222 Skype:tomer.dee http://www.intergraph.com . From: Phil Wilson [phildgwil...@gmail.com] Sent: Tuesday, October 22, 2013 7:15 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Patching with BURN-how a patch knows about original install folder? A patch that is an update to installed components doesn't need to know folder locations unless you need to specify them for some other reason. For an update of component C-Guid of product code P-Guid it can locate the path to any component (as can any program) by calling MsiGetComponentPath (P-Guid, C-Guid...). This is one of the reasons that a having each file be the key of its component is a good thing. Phil Wilson On Tue, Oct 22, 2013 at 7:40 AM, tom tomer.d...@intergraph.com wrote: I wonder when running a patch bundle how the patch bundle (acatually the MSP) knows what is the install folder used by the RTM? Looks like we are missing this values in the MSP and many of the registration we do use a directory defined in wix msp project Thanks in advance -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-with-BURN-how-a-patch-knows-about-original-install-folder-tp7589894.html Sent from the wix-users mailing list archive at Nabble.com. -- 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=60135991iu=/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
[WiX-users] Patching with BURN-how a patch knows about original install folder?
I wonder when running a patch bundle how the patch bundle (acatually the MSP) knows what is the install folder used by the RTM? Looks like we are missing this values in the MSP and many of the registration we do use a directory defined in wix msp project Thanks in advance -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-with-BURN-how-a-patch-knows-about-original-install-folder-tp7589894.html Sent from the wix-users mailing list archive at Nabble.com. -- 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=60135991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching with BURN-how a patch knows about original install folder?
A patch that is an update to installed components doesn't need to know folder locations unless you need to specify them for some other reason. For an update of component C-Guid of product code P-Guid it can locate the path to any component (as can any program) by calling MsiGetComponentPath (P-Guid, C-Guid...). This is one of the reasons that a having each file be the key of its component is a good thing. Phil Wilson On Tue, Oct 22, 2013 at 7:40 AM, tom tomer.d...@intergraph.com wrote: I wonder when running a patch bundle how the patch bundle (acatually the MSP) knows what is the install folder used by the RTM? Looks like we are missing this values in the MSP and many of the registration we do use a directory defined in wix msp project Thanks in advance -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-with-BURN-how-a-patch-knows-about-original-install-folder-tp7589894.html Sent from the wix-users mailing list archive at Nabble.com. -- 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=60135991iu=/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=60135991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching with BURN-how a patch knows about original install folder?
Some of my registry keys use values from the Directory structure: Directory Id=TARGETDIR Name=SourceDir Directory Id=INSTALLFOLDER Name=Intergraph PPM SDKs Directory Id=MA Name=SDK Directory Id=Documents Name=Documents/ /Directory /Directory /Directory RegistryKey Root=HKLM Key=SOFTWARE RegistryKey Key=Intergraph RegistryKey Key=SDK RegistryValue Name=Path Type=string Value=[Documents] /RegistryKey /RegistryKey /RegistryKey When applying a patch i am loosing the value of the Documents folder in the Path registry value. because i only asked for a path in the RTM which is passed to INSTALLFOLDER msi property Tomer Dror Intergraph Corporation. Intergraph Israel. P: +972 (4) 8779191-1222 Skype:tomer.dee http://www.intergraph.com . From: Phil Wilson [phildgwil...@gmail.com] Sent: Tuesday, October 22, 2013 7:15 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Patching with BURN-how a patch knows about original install folder? A patch that is an update to installed components doesn't need to know folder locations unless you need to specify them for some other reason. For an update of component C-Guid of product code P-Guid it can locate the path to any component (as can any program) by calling MsiGetComponentPath (P-Guid, C-Guid...). This is one of the reasons that a having each file be the key of its component is a good thing. Phil Wilson On Tue, Oct 22, 2013 at 7:40 AM, tom tomer.d...@intergraph.com wrote: I wonder when running a patch bundle how the patch bundle (acatually the MSP) knows what is the install folder used by the RTM? Looks like we are missing this values in the MSP and many of the registration we do use a directory defined in wix msp project Thanks in advance -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-with-BURN-how-a-patch-knows-about-original-install-folder-tp7589894.html Sent from the wix-users mailing list archive at Nabble.com. -- 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=60135991iu=/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=60135991iu=/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=60135991iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching error
George, On initial installations Windows Installer seems to be a little more lenient in passing public properties that are not secure while being more stringent in maintenance operations (such as repairs). There are rules (search MSDN for secure properties in the windows installer section) but the upshot is if you will use either the commandline or the UI to set the values (especially in maintenance mode transactions) you need to secure the properties. If you use the remember pattern in the execute sequence you don't need to secure the properties to reuse the previously used ones (although passwords and the remember pattern don't work well together). Hope this helps. Blair Murri From: r...@robmensching.com Date: Fri, 14 Jun 2013 21:25:30 -0700 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching error Did you remember those properties? Remember, patching is really just a repair. If repairing (without providing any extra parameters) fails patching will too. On Fri, Jun 14, 2013 at 4:42 PM, George Fleming gef...@microsoft.comwrote: If that's the case, I don't understand how normal installs work, but only patching fails. I have no problem if I type: Msiexec /i My.msi /L*v log SERVICEACCOUNT=xxx SERVICEPASSWORD=yyy i.e. use /i instead of /p. Why does secure matter in patching, but not in normal install? -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Friday, June 14, 2013 3:25 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patching error It's the ignoring part that is the issue, that's David's point. Properties will not be propagated from the UI sequence (and command lines) unless they are marked secure. Internally that's here in the MSI file: http://msdn.microsoft.com/en-us/library/windows/desktop/aa371571(v=vs.85).as px So they need to be secure or they are gone when your code runs on the server side. Phil -Original Message- From: George Fleming [mailto:gef...@microsoft.com] Sent: Friday, June 14, 2013 1:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching error I installed the patch using command line... Msiexec /p My.msi /L*v log SERVICEACCOUNT=xxx SERVICEPASSWORD=yyy I know parameters don't persist, but shouldn't they be defined if you explicitly supply them via command line parameters? -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Friday, June 14, 2013 10:00 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching error If you install your program on a test machine then run a repair from ARP or the command line does it fail with the same error? If you have not persisted these settings then they will be undefined or set to whatever default you specified during a repair or patch, unless you only install patches from the command line and re-specify the parameters. Error 0x80070103 is No more data is available. which suggests that the properties are unset. The 'ignoring' message is a warning when properties are not secure (i.e. you did not set the @secure attribute on the property definition) that means it does not get passed between the execute and ui sequences. It's usually a good idea to do this for public properties. Dave -Original Message- From: George Fleming [mailto:gef...@microsoft.com] Sent: 14 June 2013 17:25 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching error What do you mean by repairs correctly? The patch log shows errors, so I assumed that means it didn't repair correctly? I don't store the values of SERVICEACCOUNT or SERVICEPASSWORD, but they are provided via command-line parameters. However, I just noticed from the log these lines: Ignoring disallowed property SERVICEACCOUNT Ignoring disallowed property SERVICEPASSWORD -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Friday, June 14, 2013 1:50 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching error A patch application is just a repair with all relevant patch transformations applied to the msi. Check if your MSI repairs correctly. Do you persist SERVICEACCOUNT and SERVICEPASSWORD? -Original Message- From: George Fleming [mailto:gef...@microsoft.com] Sent: 13 June 2013 22:54 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Patching error I following online instructions and created a patch (msp file). There were no errors during the creation. When I tried to verify the patch by applying it, I got following error: MSI (s) (C0:F0) [13:36:29:463]: Executing op: ActionStart(Name=CreateUser,,) MSI (s) (C0:F0) [13:36:29:463]: Executing op
Re: [WiX-users] Patching error
A patch application is just a repair with all relevant patch transformations
applied to the msi.
Check if your MSI repairs correctly.
Do you persist SERVICEACCOUNT and SERVICEPASSWORD?
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: 13 June 2013 22:54
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Patching error
I following online instructions and created a patch (msp file). There were
no errors during the creation. When I tried to verify the patch by applying
it, I got following error:
MSI (s) (C0:F0) [13:36:29:463]: Executing op: ActionStart(Name=CreateUser,,)
MSI (s) (C0:F0) [13:36:29:463]: Executing op:
CustomActionSchedule(Action=CreateUser,ActionType=11265,Source=BinaryData,Tar
get=**,CustomActionData=**)
MSI (s) (C0:88) [13:36:29:463]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSIA410.tmp, Entrypoint: CreateUser MSI (s) (C0:9C)
[13:36:29:463]: Generating random cookie.
MSI (s) (C0:9C) [13:36:29:463]: Created Custom Action Server with PID 3760
(0xEB0).
MSI (s) (C0:A8) [13:36:29:495]: Running as a service.
MSI (s) (C0:FC) [13:36:29:495]: Hello, I'm your 32bit Elevated custom action
server.
CreateUser: Error 0x80070103: failed to read attributes from custom action
data CustomAction CreateUser returned actual error code 1603 (note this may
not be 100% accurate if translation happened inside sandbox) Action ended
13:36:29: InstallFinalize. Return value 3.
My code that has CreateUser in it is:
Component Id='' Win64=$(var.Win64)
Guid='{*}'
util:User Id='***' Name='[SERVICEACCOUNT]'
Password='[SERVICEPASSWORD]' CreateUser='no' LogonAsService='yes'/
File Id=*** Name=** KeyPath=yes
Source=* /
ServiceInstall Id='*'
Name='**'
DisplayName='***'
Type='ownProcess'
Start='auto'
ErrorControl='normal'
Description='**'
Account='[SERVICEACCOUNT]'
Password='[SERVICEPASSWORD]'
Vital='yes'
util:ServiceConfig FirstFailureActionType='restart'
SecondFailureActionType='restart' ThirdFailureActionType='none'
RestartServiceDelayInSeconds='10'
ResetPeriodInDays='1'/
/ServiceInstall
ServiceControl Id=StartService Stop=both Remove=uninstall
Name=** Wait=yes /
/Component
I am a bit at loss as to how to fix this problem. I have heard that when
patching, custom actions lose their parameters. Is this true? If util:user
is internally implemented as a custom action, how do I get around this?
Thanks,
George
-
-
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-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.
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching error
What do you mean by repairs correctly? The patch log shows errors, so I
assumed that means it didn't repair correctly?
I don't store the values of SERVICEACCOUNT or SERVICEPASSWORD, but they are
provided via command-line parameters. However, I just noticed from the log
these lines:
Ignoring disallowed property SERVICEACCOUNT
Ignoring disallowed property SERVICEPASSWORD
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Friday, June 14, 2013 1:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
A patch application is just a repair with all relevant patch transformations
applied to the msi.
Check if your MSI repairs correctly.
Do you persist SERVICEACCOUNT and SERVICEPASSWORD?
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: 13 June 2013 22:54
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Patching error
I following online instructions and created a patch (msp file). There were no
errors during the creation. When I tried to verify the patch by applying it, I
got following error:
MSI (s) (C0:F0) [13:36:29:463]: Executing op: ActionStart(Name=CreateUser,,)
MSI (s) (C0:F0) [13:36:29:463]: Executing op:
CustomActionSchedule(Action=CreateUser,ActionType=11265,Source=BinaryData,Tar
get=**,CustomActionData=**)
MSI (s) (C0:88) [13:36:29:463]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSIA410.tmp, Entrypoint: CreateUser MSI (s) (C0:9C)
[13:36:29:463]: Generating random cookie.
MSI (s) (C0:9C) [13:36:29:463]: Created Custom Action Server with PID 3760
(0xEB0).
MSI (s) (C0:A8) [13:36:29:495]: Running as a service.
MSI (s) (C0:FC) [13:36:29:495]: Hello, I'm your 32bit Elevated custom action
server.
CreateUser: Error 0x80070103: failed to read attributes from custom action
data CustomAction CreateUser returned actual error code 1603 (note this may not
be 100% accurate if translation happened inside sandbox) Action ended
13:36:29: InstallFinalize. Return value 3.
My code that has CreateUser in it is:
Component Id='' Win64=$(var.Win64)
Guid='{*}'
util:User Id='***' Name='[SERVICEACCOUNT]'
Password='[SERVICEPASSWORD]' CreateUser='no' LogonAsService='yes'/
File Id=*** Name=** KeyPath=yes
Source=* /
ServiceInstall Id='*'
Name='**'
DisplayName='***'
Type='ownProcess'
Start='auto'
ErrorControl='normal'
Description='**'
Account='[SERVICEACCOUNT]'
Password='[SERVICEPASSWORD]'
Vital='yes'
util:ServiceConfig FirstFailureActionType='restart'
SecondFailureActionType='restart' ThirdFailureActionType='none'
RestartServiceDelayInSeconds='10'
ResetPeriodInDays='1'/
/ServiceInstall
ServiceControl Id=StartService Stop=both Remove=uninstall
Name=** Wait=yes /
/Component
I am a bit at loss as to how to fix this problem. I have heard that when
patching, custom actions lose their parameters. Is this true? If util:user is
internally implemented as a custom action, how do I get around this?
Thanks,
George
-
-
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-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.
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching error
If you install your program on a test machine then run a repair from ARP or
the command line does it fail with the same error?
If you have not persisted these settings then they will be undefined or set
to whatever default you specified during a repair or patch, unless you only
install patches from the command line and re-specify the parameters. Error
0x80070103 is No more data is available. which suggests that the properties
are unset.
The 'ignoring' message is a warning when properties are not secure (i.e. you
did not set the @secure attribute on the property definition) that means it
does not get passed between the execute and ui sequences. It's usually a good
idea to do this for public properties.
Dave
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: 14 June 2013 17:25
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
What do you mean by repairs correctly? The patch log shows errors, so I
assumed that means it didn't repair correctly?
I don't store the values of SERVICEACCOUNT or SERVICEPASSWORD, but they are
provided via command-line parameters. However, I just noticed from the log
these lines:
Ignoring disallowed property SERVICEACCOUNT Ignoring disallowed property
SERVICEPASSWORD
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Friday, June 14, 2013 1:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
A patch application is just a repair with all relevant patch transformations
applied to the msi.
Check if your MSI repairs correctly.
Do you persist SERVICEACCOUNT and SERVICEPASSWORD?
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: 13 June 2013 22:54
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Patching error
I following online instructions and created a patch (msp file). There were
no errors during the creation. When I tried to verify the patch by applying
it, I got following error:
MSI (s) (C0:F0) [13:36:29:463]: Executing op: ActionStart(Name=CreateUser,,)
MSI (s) (C0:F0) [13:36:29:463]: Executing op:
CustomActionSchedule(Action=CreateUser,ActionType=11265,Source=BinaryData,Tar
get=**,CustomActionData=**)
MSI (s) (C0:88) [13:36:29:463]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSIA410.tmp, Entrypoint: CreateUser MSI (s) (C0:9C)
[13:36:29:463]: Generating random cookie.
MSI (s) (C0:9C) [13:36:29:463]: Created Custom Action Server with PID 3760
(0xEB0).
MSI (s) (C0:A8) [13:36:29:495]: Running as a service.
MSI (s) (C0:FC) [13:36:29:495]: Hello, I'm your 32bit Elevated custom action
server.
CreateUser: Error 0x80070103: failed to read attributes from custom action
data CustomAction CreateUser returned actual error code 1603 (note this may
not be 100% accurate if translation happened inside sandbox) Action ended
13:36:29: InstallFinalize. Return value 3.
My code that has CreateUser in it is:
Component Id='' Win64=$(var.Win64)
Guid='{*}'
util:User Id='***' Name='[SERVICEACCOUNT]'
Password='[SERVICEPASSWORD]' CreateUser='no' LogonAsService='yes'/
File Id=*** Name=** KeyPath=yes
Source=* /
ServiceInstall Id='*'
Name='**'
DisplayName='***'
Type='ownProcess'
Start='auto'
ErrorControl='normal'
Description='**'
Account='[SERVICEACCOUNT]'
Password='[SERVICEPASSWORD]'
Vital='yes'
util:ServiceConfig FirstFailureActionType='restart'
SecondFailureActionType='restart' ThirdFailureActionType='none'
RestartServiceDelayInSeconds='10'
ResetPeriodInDays='1'/
/ServiceInstall
ServiceControl Id=StartService Stop=both Remove=uninstall
Name=** Wait=yes /
/Component
I am a bit at loss as to how to fix this problem. I have heard that when
patching, custom actions lose their parameters. Is this true? If util:user
is internally implemented as a custom action, how do I get around this?
Thanks,
George
-
-
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-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
Re: [WiX-users] Patching error
I installed the patch using command line...
Msiexec /p My.msi /L*v log SERVICEACCOUNT=xxx SERVICEPASSWORD=yyy
I know parameters don't persist, but shouldn't they be defined if you
explicitly supply them via command line parameters?
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Friday, June 14, 2013 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
If you install your program on a test machine then run a repair from ARP or the
command line does it fail with the same error?
If you have not persisted these settings then they will be undefined or set to
whatever default you specified during a repair or patch, unless you only
install patches from the command line and re-specify the parameters. Error
0x80070103 is No more data is available. which suggests that the properties
are unset.
The 'ignoring' message is a warning when properties are not secure (i.e. you
did not set the @secure attribute on the property definition) that means it
does not get passed between the execute and ui sequences. It's usually a good
idea to do this for public properties.
Dave
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: 14 June 2013 17:25
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
What do you mean by repairs correctly? The patch log shows errors, so I
assumed that means it didn't repair correctly?
I don't store the values of SERVICEACCOUNT or SERVICEPASSWORD, but they are
provided via command-line parameters. However, I just noticed from the log
these lines:
Ignoring disallowed property SERVICEACCOUNT Ignoring disallowed property
SERVICEPASSWORD
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Friday, June 14, 2013 1:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
A patch application is just a repair with all relevant patch transformations
applied to the msi.
Check if your MSI repairs correctly.
Do you persist SERVICEACCOUNT and SERVICEPASSWORD?
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: 13 June 2013 22:54
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Patching error
I following online instructions and created a patch (msp file). There were no
errors during the creation. When I tried to verify the patch by applying it, I
got following error:
MSI (s) (C0:F0) [13:36:29:463]: Executing op: ActionStart(Name=CreateUser,,)
MSI (s) (C0:F0) [13:36:29:463]: Executing op:
CustomActionSchedule(Action=CreateUser,ActionType=11265,Source=BinaryData,Tar
get=**,CustomActionData=**)
MSI (s) (C0:88) [13:36:29:463]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSIA410.tmp, Entrypoint: CreateUser MSI (s) (C0:9C)
[13:36:29:463]: Generating random cookie.
MSI (s) (C0:9C) [13:36:29:463]: Created Custom Action Server with PID 3760
(0xEB0).
MSI (s) (C0:A8) [13:36:29:495]: Running as a service.
MSI (s) (C0:FC) [13:36:29:495]: Hello, I'm your 32bit Elevated custom action
server.
CreateUser: Error 0x80070103: failed to read attributes from custom action
data CustomAction CreateUser returned actual error code 1603 (note this may not
be 100% accurate if translation happened inside sandbox) Action ended
13:36:29: InstallFinalize. Return value 3.
My code that has CreateUser in it is:
Component Id='' Win64=$(var.Win64)
Guid='{*}'
util:User Id='***' Name='[SERVICEACCOUNT]'
Password='[SERVICEPASSWORD]' CreateUser='no' LogonAsService='yes'/
File Id=*** Name=** KeyPath=yes
Source=* /
ServiceInstall Id='*'
Name='**'
DisplayName='***'
Type='ownProcess'
Start='auto'
ErrorControl='normal'
Description='**'
Account='[SERVICEACCOUNT]'
Password='[SERVICEPASSWORD]'
Vital='yes'
util:ServiceConfig FirstFailureActionType='restart'
SecondFailureActionType='restart' ThirdFailureActionType='none'
RestartServiceDelayInSeconds='10'
ResetPeriodInDays='1'/
/ServiceInstall
ServiceControl Id=StartService Stop=both Remove=uninstall
Name=** Wait=yes /
/Component
I am a bit at loss as to how to fix this problem. I have heard that when
patching, custom actions lose their parameters. Is this true? If util:user is
internally implemented as a custom action, how do I get around this?
Thanks,
George
-
-
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
Re: [WiX-users] Patching error
It's the ignoring part that is the issue, that's David's point. Properties
will not be propagated from the UI sequence (and command lines) unless they
are marked secure. Internally that's here in the MSI file:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371571(v=vs.85).as
px
So they need to be secure or they are gone when your code runs on the server
side.
Phil
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: Friday, June 14, 2013 1:17 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
I installed the patch using command line...
Msiexec /p My.msi /L*v log SERVICEACCOUNT=xxx SERVICEPASSWORD=yyy
I know parameters don't persist, but shouldn't they be defined if you
explicitly supply them via command line parameters?
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Friday, June 14, 2013 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
If you install your program on a test machine then run a repair from ARP or
the command line does it fail with the same error?
If you have not persisted these settings then they will be undefined or set
to whatever default you specified during a repair or patch, unless you only
install patches from the command line and re-specify the parameters. Error
0x80070103 is No more data is available. which suggests that the
properties are unset.
The 'ignoring' message is a warning when properties are not secure (i.e. you
did not set the @secure attribute on the property definition) that means it
does not get passed between the execute and ui sequences. It's usually a
good idea to do this for public properties.
Dave
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: 14 June 2013 17:25
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
What do you mean by repairs correctly? The patch log shows errors, so I
assumed that means it didn't repair correctly?
I don't store the values of SERVICEACCOUNT or SERVICEPASSWORD, but they are
provided via command-line parameters. However, I just noticed from the log
these lines:
Ignoring disallowed property SERVICEACCOUNT Ignoring disallowed property
SERVICEPASSWORD
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Friday, June 14, 2013 1:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
A patch application is just a repair with all relevant patch transformations
applied to the msi.
Check if your MSI repairs correctly.
Do you persist SERVICEACCOUNT and SERVICEPASSWORD?
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: 13 June 2013 22:54
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Patching error
I following online instructions and created a patch (msp file). There were
no errors during the creation. When I tried to verify the patch by applying
it, I got following error:
MSI (s) (C0:F0) [13:36:29:463]: Executing op: ActionStart(Name=CreateUser,,)
MSI (s) (C0:F0) [13:36:29:463]: Executing op:
CustomActionSchedule(Action=CreateUser,ActionType=11265,Source=BinaryData,Ta
r
get=**,CustomActionData=**)
MSI (s) (C0:88) [13:36:29:463]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSIA410.tmp, Entrypoint: CreateUser MSI (s) (C0:9C)
[13:36:29:463]: Generating random cookie.
MSI (s) (C0:9C) [13:36:29:463]: Created Custom Action Server with PID 3760
(0xEB0).
MSI (s) (C0:A8) [13:36:29:495]: Running as a service.
MSI (s) (C0:FC) [13:36:29:495]: Hello, I'm your 32bit Elevated custom action
server.
CreateUser: Error 0x80070103: failed to read attributes from custom action
data CustomAction CreateUser returned actual error code 1603 (note this may
not be 100% accurate if translation happened inside sandbox) Action ended
13:36:29: InstallFinalize. Return value 3.
My code that has CreateUser in it is:
Component Id='' Win64=$(var.Win64)
Guid='{*}'
util:User Id='***' Name='[SERVICEACCOUNT]'
Password='[SERVICEPASSWORD]' CreateUser='no' LogonAsService='yes'/
File Id=*** Name=** KeyPath=yes
Source=* /
ServiceInstall Id='*'
Name='**'
DisplayName='***'
Type='ownProcess'
Start='auto'
ErrorControl='normal'
Description='**'
Account='[SERVICEACCOUNT]'
Password='[SERVICEPASSWORD]'
Vital='yes'
util:ServiceConfig FirstFailureActionType='restart'
SecondFailureActionType='restart' ThirdFailureActionType='none'
RestartServiceDelayInSeconds='10'
ResetPeriodInDays
Re: [WiX-users] Patching error
If that's the case, I don't understand how normal installs work, but only
patching fails. I have no problem if I type:
Msiexec /i My.msi /L*v log SERVICEACCOUNT=xxx SERVICEPASSWORD=yyy
i.e. use /i instead of /p. Why does secure matter in patching, but not in
normal install?
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: Friday, June 14, 2013 3:25 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Patching error
It's the ignoring part that is the issue, that's David's point. Properties
will not be propagated from the UI sequence (and command lines) unless they are
marked secure. Internally that's here in the MSI file:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371571(v=vs.85).as
px
So they need to be secure or they are gone when your code runs on the server
side.
Phil
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: Friday, June 14, 2013 1:17 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
I installed the patch using command line...
Msiexec /p My.msi /L*v log SERVICEACCOUNT=xxx SERVICEPASSWORD=yyy
I know parameters don't persist, but shouldn't they be defined if you
explicitly supply them via command line parameters?
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Friday, June 14, 2013 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
If you install your program on a test machine then run a repair from ARP or the
command line does it fail with the same error?
If you have not persisted these settings then they will be undefined or set to
whatever default you specified during a repair or patch, unless you only
install patches from the command line and re-specify the parameters. Error
0x80070103 is No more data is available. which suggests that the properties
are unset.
The 'ignoring' message is a warning when properties are not secure (i.e. you
did not set the @secure attribute on the property definition) that means it
does not get passed between the execute and ui sequences. It's usually a good
idea to do this for public properties.
Dave
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: 14 June 2013 17:25
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
What do you mean by repairs correctly? The patch log shows errors, so I
assumed that means it didn't repair correctly?
I don't store the values of SERVICEACCOUNT or SERVICEPASSWORD, but they are
provided via command-line parameters. However, I just noticed from the log
these lines:
Ignoring disallowed property SERVICEACCOUNT Ignoring disallowed property
SERVICEPASSWORD
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Friday, June 14, 2013 1:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
A patch application is just a repair with all relevant patch transformations
applied to the msi.
Check if your MSI repairs correctly.
Do you persist SERVICEACCOUNT and SERVICEPASSWORD?
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: 13 June 2013 22:54
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Patching error
I following online instructions and created a patch (msp file). There were no
errors during the creation. When I tried to verify the patch by applying it, I
got following error:
MSI (s) (C0:F0) [13:36:29:463]: Executing op: ActionStart(Name=CreateUser,,)
MSI (s) (C0:F0) [13:36:29:463]: Executing op:
CustomActionSchedule(Action=CreateUser,ActionType=11265,Source=BinaryData,Ta
r
get=**,CustomActionData=**)
MSI (s) (C0:88) [13:36:29:463]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSIA410.tmp, Entrypoint: CreateUser MSI (s) (C0:9C)
[13:36:29:463]: Generating random cookie.
MSI (s) (C0:9C) [13:36:29:463]: Created Custom Action Server with PID 3760
(0xEB0).
MSI (s) (C0:A8) [13:36:29:495]: Running as a service.
MSI (s) (C0:FC) [13:36:29:495]: Hello, I'm your 32bit Elevated custom action
server.
CreateUser: Error 0x80070103: failed to read attributes from custom action
data CustomAction CreateUser returned actual error code 1603 (note this may not
be 100% accurate if translation happened inside sandbox) Action ended
13:36:29: InstallFinalize. Return value 3.
My code that has CreateUser in it is:
Component Id='' Win64=$(var.Win64)
Guid='{*}'
util:User Id='***' Name='[SERVICEACCOUNT]'
Password='[SERVICEPASSWORD]' CreateUser='no' LogonAsService='yes'/
File Id=*** Name=** KeyPath=yes
Source=* /
ServiceInstall Id='*'
Name='**'
DisplayName
Re: [WiX-users] Patching error
Did you remember those properties? Remember, patching is really just a
repair. If repairing (without providing any extra parameters) fails
patching will too.
On Fri, Jun 14, 2013 at 4:42 PM, George Fleming gef...@microsoft.comwrote:
If that's the case, I don't understand how normal installs work, but only
patching fails. I have no problem if I type:
Msiexec /i My.msi /L*v log SERVICEACCOUNT=xxx SERVICEPASSWORD=yyy
i.e. use /i instead of /p. Why does secure matter in patching, but not
in normal install?
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: Friday, June 14, 2013 3:25 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Patching error
It's the ignoring part that is the issue, that's David's point.
Properties will not be propagated from the UI sequence (and command lines)
unless they are marked secure. Internally that's here in the MSI file:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371571(v=vs.85).as
px
So they need to be secure or they are gone when your code runs on the
server side.
Phil
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: Friday, June 14, 2013 1:17 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
I installed the patch using command line...
Msiexec /p My.msi /L*v log SERVICEACCOUNT=xxx SERVICEPASSWORD=yyy
I know parameters don't persist, but shouldn't they be defined if you
explicitly supply them via command line parameters?
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Friday, June 14, 2013 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
If you install your program on a test machine then run a repair from ARP
or the command line does it fail with the same error?
If you have not persisted these settings then they will be undefined or
set to whatever default you specified during a repair or patch, unless you
only install patches from the command line and re-specify the parameters.
Error
0x80070103 is No more data is available. which suggests that the
properties are unset.
The 'ignoring' message is a warning when properties are not secure (i.e.
you did not set the @secure attribute on the property definition) that
means it does not get passed between the execute and ui sequences. It's
usually a good idea to do this for public properties.
Dave
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: 14 June 2013 17:25
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
What do you mean by repairs correctly? The patch log shows errors, so I
assumed that means it didn't repair correctly?
I don't store the values of SERVICEACCOUNT or SERVICEPASSWORD, but they
are provided via command-line parameters. However, I just noticed from the
log these lines:
Ignoring disallowed property SERVICEACCOUNT Ignoring disallowed property
SERVICEPASSWORD
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Friday, June 14, 2013 1:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
A patch application is just a repair with all relevant patch
transformations applied to the msi.
Check if your MSI repairs correctly.
Do you persist SERVICEACCOUNT and SERVICEPASSWORD?
-Original Message-
From: George Fleming [mailto:gef...@microsoft.com]
Sent: 13 June 2013 22:54
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Patching error
I following online instructions and created a patch (msp file). There
were no errors during the creation. When I tried to verify the patch by
applying it, I got following error:
MSI (s) (C0:F0) [13:36:29:463]: Executing op:
ActionStart(Name=CreateUser,,) MSI (s) (C0:F0) [13:36:29:463]: Executing op:
CustomActionSchedule(Action=CreateUser,ActionType=11265,Source=BinaryData,Ta
r
get=**,CustomActionData=**)
MSI (s) (C0:88) [13:36:29:463]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSIA410.tmp, Entrypoint: CreateUser MSI (s) (C0:9C)
[13:36:29:463]: Generating random cookie.
MSI (s) (C0:9C) [13:36:29:463]: Created Custom Action Server with PID 3760
(0xEB0).
MSI (s) (C0:A8) [13:36:29:495]: Running as a service.
MSI (s) (C0:FC) [13:36:29:495]: Hello, I'm your 32bit Elevated custom
action server.
CreateUser: Error 0x80070103: failed to read attributes from custom
action data CustomAction CreateUser returned actual error code 1603 (note
this may not be 100% accurate if translation happened inside sandbox)
Action ended
13:36:29: InstallFinalize. Return value 3.
My code that has CreateUser in it is:
Component Id='' Win64=$(var.Win64)
Guid='{*}'
util:User Id='***' Name
[WiX-users] Patching error
I following online instructions and created a patch (msp file). There were no
errors during the creation. When I tried to verify the patch by applying it, I
got following error:
MSI (s) (C0:F0) [13:36:29:463]: Executing op: ActionStart(Name=CreateUser,,)
MSI (s) (C0:F0) [13:36:29:463]: Executing op:
CustomActionSchedule(Action=CreateUser,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**)
MSI (s) (C0:88) [13:36:29:463]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSIA410.tmp, Entrypoint: CreateUser
MSI (s) (C0:9C) [13:36:29:463]: Generating random cookie.
MSI (s) (C0:9C) [13:36:29:463]: Created Custom Action Server with PID 3760
(0xEB0).
MSI (s) (C0:A8) [13:36:29:495]: Running as a service.
MSI (s) (C0:FC) [13:36:29:495]: Hello, I'm your 32bit Elevated custom action
server.
CreateUser: Error 0x80070103: failed to read attributes from custom action data
CustomAction CreateUser returned actual error code 1603 (note this may not be
100% accurate if translation happened inside sandbox)
Action ended 13:36:29: InstallFinalize. Return value 3.
My code that has CreateUser in it is:
Component Id='' Win64=$(var.Win64)
Guid='{*}'
util:User Id='***' Name='[SERVICEACCOUNT]'
Password='[SERVICEPASSWORD]' CreateUser='no' LogonAsService='yes'/
File Id=*** Name=** KeyPath=yes
Source=* /
ServiceInstall Id='*'
Name='**'
DisplayName='***'
Type='ownProcess'
Start='auto'
ErrorControl='normal'
Description='**'
Account='[SERVICEACCOUNT]'
Password='[SERVICEPASSWORD]'
Vital='yes'
util:ServiceConfig FirstFailureActionType='restart'
SecondFailureActionType='restart' ThirdFailureActionType='none'
RestartServiceDelayInSeconds='10'
ResetPeriodInDays='1'/
/ServiceInstall
ServiceControl Id=StartService Stop=both Remove=uninstall
Name=** Wait=yes /
/Component
I am a bit at loss as to how to fix this problem. I have heard that when
patching, custom actions lose their parameters. Is this true? If util:user is
internally implemented as a custom action, how do I get around this?
Thanks,
George
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching with multiple instances
Hi, I'm having issues trying to get a patch built with WiX (using the Patch Creation Properties method) to apply to an MSI (also built with WiX) that has been multi instance transformed. I've logged my efforts to get it working on StackOverflow: http://stackoverflow.com/questions/14814014/msi-multi-instance-installation-with-patches Whenever I try and install the patch the Windows Installer immediately fails with The upgrade patch cannot be installed by the Windows Installer service because the program to upgraded may be missing, or the upgrade patch may update a different version of the program. - so I'm assuming I need to do something to the patch to make it work with the product code my instance is setup with. I thought I'd only need to set AllowProductCodeMismatches=yes on the PatchCreation element, but that doesn't seem to have made the patch installable - it will still install against a none-multi instance install though. Is there anything else I need to do? I've tried suggestions to modify the patch after build so that includes the new product code, but that doesn't seem to fix the issue either. Thanks, Gareth Oakley gareth.oak...@appsense.com -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] patching issue: adding new file works but this throws out old files Sequence numbers in msi
Did you rebuild any of the files when you created the second MSI ? If so,
then they will be different and will potentially be pulled into the patch.
I assume you mean file sequence numbers, rather than component. Its normal
for patched files to get new file sequence numbers.
-Original Message-
From: Muzikayise Flynn Buthelezi [mailto:muzkay...@gmail.com]
Sent: 05 October 2012 10:26
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] patching issue: adding new file works but this throws
out old files Sequence numbers in msi
Good Morning Team, trust everyone is well today.
We have a complex installer made up of many wxs files, and we are now
investigating wix patching.
As an example
Product.wxs
OtherA.wxs
OtherB.wxs
FeatureY.wxs.
We want to add a new component to OtherA.wxs. So we do that like this and add
the component ref to the existing component group
Component Id=SampleComponent2
Guid={0487C0F6-DE1F-443C-8D75-1F38FD098E4F} DiskId=1
File Id=ANewfiletxt Name=A New file.txt Source=A New
file.txt /
/Component
We run the commands candle, light and torch.
Then update the patch.wxs to include the new componentref created above and
create the patch using candle, light and pyro.
The issue is that the patch is 50Mb or higher, and secondly when opening up
the Original .msi in orca and viewing the patch the component sequence
numbers for some files are being changed.
So the questions are
1. Why is the patch so large? it should only be about 1MB since we only added
1 file 2. Are the component sequence numbers being changed because we are
adding a new component in the middle (ie. in OtherA.wxs)? Should new
components be added to a new feature to avoid this?
3. Is there logging or a method of determining why certain files are being
included in the patch when running pyro, as we don't expect such a large
patch.
this is confusing because when we do the same test on a simple test project
we get the desired results but when we apply this to main complex project we
get this weird behavior.
thanks,
--
Best always,
Muzi
082 594 4807
Light, Love Prosperity in Abundance!!!
-
-
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
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.
--
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] Patching Components with different GUIDs?
Hi Guys, Is that possible to Patch a Component whose GUID was changed in Updated build? Pyro gives an error: I know if I change the GUID in my updated msi back to the one which was in Original msi. But I have a case in which a great number of GUIDs (might be in thousands) have to be updated then. Any suggestions please?? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-Components-with-different-GUIDs-tp7579493.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
Re: [WiX-users] Patching Components with different GUIDs?
That would be a violation of the component rules and would go horribly wrong. If you want to change component GUIDs, you will need to use a major upgrade as Neil suggested previously: ensure that all MSIs that install those components are removed by the major upgrade and schedule RemoveExistingProducts early. See the MSDN sections on patching and major upgrades for full details. If you use * for the component GUID in future MSIs, it will reduce the number of GUIDs you need to manage manually. -Original Message- From: Farrukhw [mailto:farru...@gmail.com] Sent: 19 July 2012 15:08 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching Components with different GUIDs? Hi Guys, Is that possible to Patch a Component whose GUID was changed in Updated build? Pyro gives an error: I know if I change the GUID in my updated msi back to the one which was in Original msi. But I have a case in which a great number of GUIDs (might be in thousands) have to be updated then. Any suggestions please?? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-Compon ents-with-different-GUIDs-tp7579493.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 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. -- 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] Patching Components with different GUIDs?
Hi Peter, Thanks for your reply.. I've given msi builds which were not designed by me and after Pyro's complaint, I investigated that in every build, same named components got new Component ID (GUID). Although, I've informed the owners and asked them if they are changing the Component IDs for each build, but I'm also thinking to write a script to extract the GUIDs from original msi and update/correct in updated msi, but I know it would not be a good idea... Regards Farrukh -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-Components-with-different-GUIDs-tp7579493p7579496.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
Re: [WiX-users] Patching registry changes for COM components
On 07-Jun-12 15:21, Vishnu wrote: How to include registry changes in patching ? They are, if the registry changes are reflected in the upgrade MSI and the component that contains them is being installed. See a verbose patch-install log to see what MSI is doing with each component. -- sig://boB http://joyofsetup.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
Re: [WiX-users] Patching registry changes for COM components
Install log shows registry is updated from previous (cached) msi values. I applied patch using ORCA tool, and didnt find any new registry changes in the patch file (msp). Do we need to create a component for each registry values and reference it in ComponentRef section in PatchFamily element? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-registry-changes-for-COM-components-tp7578720p7578762.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
Re: [WiX-users] Patching registry changes for COM components
On 11-Jun-12 14:20, Vishnu wrote: Install log shows registry is updated from previous (cached) msi values. I applied patch using ORCA tool, and didnt find any new registry changes in the patch file (msp). Do we need to create a component for each registry values and reference it in ComponentRef section in PatchFamily element? If you have any ComponentRefs under PatchFamily, then you must include ComponentRefs for everything you want in the patch. Otherwise, the default behavior is for Pyro to find everything that changed. -- sig://boB http://joyofsetup.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
[WiX-users] Patching registry changes for COM components
We have legacy VB6 COM components dll in our installer. Some of the them are modified, so we are creating patches to update dlls in client machine. Based on WIX patching (using Pyro), I created a patch applied successfully. All the modified components are getting replaced but registry changes are not reflected. I used REINSTALLMODE = emus while applying patch. How to include registry changes in patching ? Thanks in advance. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-registry-changes-for-COM-components-tp7578720.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
Re: [WiX-users] Patching and Pyro Warning PYRO1110
With someone's help, I figured out the approach. After CostFinalize action, before InstallValidate action, add a customer action, say UpdateFeatureChange, which changes the feature's reqire state accordingly. In DTF, it is as simple as FeatureInfo featureA2= this.Session.Features[FeatureA2]; featureA2.RequestState = InstallState.Absent; // Or Local/Source/Advertise... according to other conditions The DTF is using MsiSetFeatureState API to set the state. The condition is complex, because I need to handle different scenarios like repair/change/update/uninstall. However, this is a workable approach. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-and-Pyro-Warning-PYRO1110-tp7256794p7282912.html Sent from the wix-users mailing list archive at Nabble.com. -- 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
Re: [WiX-users] Patching and Pyro Warning PYRO1110
Echo on the question. I have exactly the same problem: In my product V1.0, I have FeatureCommon (always be installed) Common.dll FeatureA (optional) A1.dll FeatureB (optional) B1.dll In my product V1.1 I added A2.dll to feature A FeatureCommon (always be installed) Common.dll FeatureA (optional) A1.dll A2.dll FeatureB (optional) B1.dll Thus I add ComponentRef Id=cmpA2DLL to the PatchFamily, then I got error of Component 'cmpA2DLL' was added to feature FeatureA. If you cannot guarantee this feature will always be installed, you should consider adding new components to top-level features to prevent prompts for source when installing this patch. Does it mean, if I want to add A2.dll, I must have a new top-level FeatureA2? Then I could I make sure FeatureA2 will be installed when patching if and only if FeatureA is installed? Manually write several pre-check? Anyone can give me a sample of how to make the patch correct for this scenario? Thanks, -Elfe -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-and-Pyro-Warning-PYRO1110-tp7256794p7271713.html Sent from the wix-users mailing list archive at Nabble.com. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching and Pyro Warning PYRO1110
Further to my original question, I have been doing some testing. If find that: (1) if the patch contains a _new_ file that belongs to a feature that the is not installed on the user machine, then the patch effectively installs the feature (and uninstalling the patch does not remove the feature) along with the new file. (2) If the patch contains an _existing_ file update from a feature that is not installed, it has no effect (it doesn't install the file or alter the features installed on the machine). Can someone confirm this is what you would expect (and provide an explanation)? Thanks sanjay -Original Message- From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] Sent: 05 February 2012 21:21 To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] Patching and Pyro Warning PYRO1110 I have created an MSI product installer for a product that has a main feature (call it MF) and a sub feature (call it SF). It is mandatory to install the main feature but the sub feature is optional. I am experimenting with creating patches (small updates) using Wix 3.5 for this product. I have a patch which adds a couple of new files to the distribution. Using Pyro to generate the msp file using the diff.wixmst between the two builds (the original and the one with added files), Pyro gives me the waning: Pyro.exe: warning PYRO1110 : Component 'XXX' was added to feature SF. If you cannot guarantee this feature will always be installed, you should consider adding new components to top-level features to prevent prompts for source when installing this patch. I would have expected that if you initially installed the product without feature SF, then you install the patch, that the relevant component 'XXX' would not be installed (because you don't the feature that it belongs to). Then if you ever modified the original installation to include feature SF (with the patch already installed), a new view of the product would be generated that includes component XXX. It seems that this is not the case? Can anyone explain how MSI works in this case? I have found this blog (http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something- you-didnt-build-with-wix-using-wix-.aspx ) where Peter Marcu says that you should create a new top level feature (presumably that is always installed?) in order to add these new files via a patch. Otherwise Adding them to existing features that are not always installed can leave you in some pretty unfortunate situations. Can someone explain to me what these unfortunate situations are? Also, If I have to create a new top level feature in the patch that always installs the components, that would be pretty odd because I would have to potentially install many redundant files (in the cases where the user never installs the sub feature). Can I avoid this? Thanks in advance sanjay -- 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
[WiX-users] Patching and Pyro Warning PYRO1110
I have created an MSI product installer for a product that has a main feature (call it MF) and a sub feature (call it SF). It is mandatory to install the main feature but the sub feature is optional. I am experimenting with creating patches (small updates) using Wix 3.5 for this product. I have a patch which adds a couple of new files to the distribution. Using Pyro to generate the msp file using the diff.wixmst between the two builds (the original and the one with added files), Pyro gives me the waning: Pyro.exe: warning PYRO1110 : Component 'XXX' was added to feature SF. If you cannot guarantee this feature will always be installed, you should consider adding new components to top-level features to prevent prompts for source when installing this patch. I would have expected that if you initially installed the product without feature SF, then you install the patch, that the relevant component 'XXX' would not be installed (because you don't the feature that it belongs to). Then if you ever modified the original installation to include feature SF (with the patch already installed), a new view of the product would be generated that includes component XXX. It seems that this is not the case? Can anyone explain how MSI works in this case? I have found this blog (http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something-you-didnt-build-with-wix-using-wix-.aspx ) where Peter Marcu says that you should create a new top level feature (presumably that is always installed?) in order to add these new files via a patch. Otherwise Adding them to existing features that are not always installed can leave you in some pretty unfortunate situations. Can someone explain to me what these unfortunate situations are? Also, If I have to create a new top level feature in the patch that always installs the components, that would be pretty odd because I would have to potentially install many redundant files (in the cases where the user never installs the sub feature). Can I avoid this? Thanks in advance sanjay -- 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] Patching
Thanks again Peter. I think I will read the MS whitepaper on patching because it is clear that our current strategy does not fit with the MSI model of updates. We may take the opportunity to change our model as you suggest. Regards snajay -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 12 January 2012 10:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching 1. There are a couple of ways that might work for you. It depends if you have to stick with your current upgrade strategy or if you have an opportunity to alter it. Firstly, most people find that producing major upgrade MSIs is by far the easiest way to support upgrades. You cant apply these out of order though. This blog post describes your scenario http://blogs.msdn.com/b/heaths/archive/2006/06/14/cumulative-service- packs-wi th-minorupdatetargetrtm.aspx This also won't allow you to apply patches out of order. You can apply a later patch first but, being cumulative, the earlier patch is included. It does however simplify the problem of supporting a product with many possible combinations of patches involved. You could also create patches that target multiple versions of the MSI. That fits your requirement better but problem with those is that, if you produce many patches that can be applied in any order, the number of possible installed products that need to be targeted increases rapidly. This increases patch size and testing complexity. If the patches are independent and don't change the product version, that may not be a problem. I believe you could also create small updates that do not alter the product version and could be combined freely. As long as all your files are versioned and backwards compatible, then you could mix these freely and the MSI versioning rules would always ensure the highest is installed. The number of possible combinations you allow could grow quickly and will be inherently tricky to support. Finding the best solution is really only something you can decide, knowing what your constraints are. Whatever you decide on, you should definitely make some test patches. I also strongly recommend reading the MS whitepaper. Its long and dry but explains many ways in which you can use patching and has some example scenarios too. 3. I think heat automatically generates components in fragments unless you use the -sfrag switch. Torch works with all kinds of files. Windows Installer works best if your executable files have a version resource that specifies the file version but it'll will handle unversioned binaries too. -Original Message- From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] Sent: 11 January 2012 23:09 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patching Thanks for the information Peter. Some follow up: 1) In previous versions of our app, we distributed patches to the customer as a set of files in a zip that the customer simply unzips into the application directory. While this isn't ideal (because of the problems associated with uninstalling patches etc.) it is very flexible in that we can distribute any number of patches that are not dependant on each other, and the customer can install and test the features in any order. For example, If we deliver patch P1 and P2 to the customer in that order, they may decide to install P2 first because it requires a smaller test effort than P1. I'm not sure how I achieve the same using the MSI patching. Let's say we have 3 wixpdb files: mainprod.wixpdb, patch1.wixpdb, patch2.wixpdb. When release Patch1 we use the transform (mainprod-patch1). Then we release patch2 which is not dependant on patch1 so we use the transforms (mainprod-patch2 and patch1-patch2) to generate it. But that wouldn't work if the customer decided to install patch2 first and then patch1 would it? Might be that i'm missing something obvious here! 3) I think I prefer to segment my components into different fragments and use the wixpdb to generate the mappings as doing admin install is a bit of a pain and potentially more error prone for us. Does anyone know if there is an easy way to do this (eg, if I harvest files using heat for my initial release, can it generate a different fragment for each component?). Another question and potential issue I thought of: Most of the files we distribute are binary (PowerBuilder) files. Will torch be able to generate the transform correctly for these? thanks sanjay -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 11 January 2012 10:49 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching I'll try and answer this but it's best to seek some other opinions too. 1. The order of patch installation wont usually matter. When
Re: [WiX-users] Patching
1. There are a couple of ways that might work for you. It depends if you have to stick with your current upgrade strategy or if you have an opportunity to alter it. Firstly, most people find that producing major upgrade MSIs is by far the easiest way to support upgrades. You cant apply these out of order though. This blog post describes your scenario http://blogs.msdn.com/b/heaths/archive/2006/06/14/cumulative-service-packs-wi th-minorupdatetargetrtm.aspx This also won't allow you to apply patches out of order. You can apply a later patch first but, being cumulative, the earlier patch is included. It does however simplify the problem of supporting a product with many possible combinations of patches involved. You could also create patches that target multiple versions of the MSI. That fits your requirement better but problem with those is that, if you produce many patches that can be applied in any order, the number of possible installed products that need to be targeted increases rapidly. This increases patch size and testing complexity. If the patches are independent and don't change the product version, that may not be a problem. I believe you could also create small updates that do not alter the product version and could be combined freely. As long as all your files are versioned and backwards compatible, then you could mix these freely and the MSI versioning rules would always ensure the highest is installed. The number of possible combinations you allow could grow quickly and will be inherently tricky to support. Finding the best solution is really only something you can decide, knowing what your constraints are. Whatever you decide on, you should definitely make some test patches. I also strongly recommend reading the MS whitepaper. Its long and dry but explains many ways in which you can use patching and has some example scenarios too. 3. I think heat automatically generates components in fragments unless you use the -sfrag switch. Torch works with all kinds of files. Windows Installer works best if your executable files have a version resource that specifies the file version but it'll will handle unversioned binaries too. -Original Message- From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] Sent: 11 January 2012 23:09 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patching Thanks for the information Peter. Some follow up: 1) In previous versions of our app, we distributed patches to the customer as a set of files in a zip that the customer simply unzips into the application directory. While this isn't ideal (because of the problems associated with uninstalling patches etc.) it is very flexible in that we can distribute any number of patches that are not dependant on each other, and the customer can install and test the features in any order. For example, If we deliver patch P1 and P2 to the customer in that order, they may decide to install P2 first because it requires a smaller test effort than P1. I'm not sure how I achieve the same using the MSI patching. Let's say we have 3 wixpdb files: mainprod.wixpdb, patch1.wixpdb, patch2.wixpdb. When release Patch1 we use the transform (mainprod-patch1). Then we release patch2 which is not dependant on patch1 so we use the transforms (mainprod-patch2 and patch1-patch2) to generate it. But that wouldn't work if the customer decided to install patch2 first and then patch1 would it? Might be that i'm missing something obvious here! 3) I think I prefer to segment my components into different fragments and use the wixpdb to generate the mappings as doing admin install is a bit of a pain and potentially more error prone for us. Does anyone know if there is an easy way to do this (eg, if I harvest files using heat for my initial release, can it generate a different fragment for each component?). Another question and potential issue I thought of: Most of the files we distribute are binary (PowerBuilder) files. Will torch be able to generate the transform correctly for these? thanks sanjay -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 11 January 2012 10:49 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching I'll try and answer this but it's best to seek some other opinions too. 1. The order of patch installation wont usually matter. When you create a patch, you target it at a particular version or even multiple versions (eg patched/upgraded installations) and MSI works out the right sequence. See the MS patching whitepaper at http://www.microsoft.com/download/en/details.aspx?id=19013 You do this by creating one or more transforms (diffs) with the torch tool and passing them when you create the patch with pyro. 2. The 4th version field of the MSI product version is ignored by Windows installer. You can use it for information but we don't - some APIs will retrieve the 4th field however. We
Re: [WiX-users] Patching
I'll try and answer this but it's best to seek some other opinions too. 1. The order of patch installation wont usually matter. When you create a patch, you target it at a particular version or even multiple versions (eg patched/upgraded installations) and MSI works out the right sequence. See the MS patching whitepaper at http://www.microsoft.com/download/en/details.aspx?id=19013 You do this by creating one or more transforms (diffs) with the torch tool and passing them when you create the patch with pyro. 2. The 4th version field of the MSI product version is ignored by Windows installer. You can use it for information but we don't - some APIs will retrieve the 4th field however. We use [major version].[service pack].[build] The files in your installer have no such restrictions. Version those in whatever way suits you. 3. The way we do that currently is to build the patch from administrative installations of the released and updated MSIs instead of using wixpdbs. http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something-you-didn t-build-with-wix-using-wix-.aspx and other articles in that blog. 4. MSI records what patches are applied to a product. It depends on how you want to retrieve the information. You can use MsiEnumPatches() from C++ for example. You could also install something to act as a marker. Useful links include: MSDN on Windows installer Peter Marcu's blog Heath Stewart's blog Rob Menchsings blog (and others on the Wix team) This mailing list's archives Wix docs -Original Message- From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] Sent: 10 January 2012 23:18 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching I am in the process of writing an installer for a company product (we were previously using Installshield). Once, released we will need the produce patches for bug fixes and enhancements. The expectation that these patches will consist of simply updating some of the released files and/or adding new files not part of the initial distribution. I think we will generally do a minor upgrade. In some cases the patches are dependent on a previous patch and in other cases not. Therefore I've been reading material about how we should structure our initial release of the product to best enable but still have some questions about things that aren't clear. Can someone help me here: 1. How can we generate the diff against the installed version for the patches that can be installed in any order. We are not sure what the users machine will have because they may have already applied one of the other patches. Surely we don't need to generate a patch for each possible order of installation of all the patches. 2. We can update the 3rd or 4th component of product version when doing an upgrade/patch for some. Can someone explain the consequences of each option. When we generate a diff for the patch, does the generated patch use the product version and only patch against it or does it only patch products with matching Product GUID and file versions. 3. When creating a patch, I want to explicitly specify the collection of files (DLLs etc.) to be upgraded. I don't want any other existing files to be touched. I have read that when you specify a patch components (i.e. via ComponentRef) inside a PatchFamily element, any components in the same fragment will also be updated. Can I avoid this without having to create different fragments for every component in my product which is a bit of a pain. 4. As far as I can tell, you can always apply a patch (msp) multiple times even if the product is already patched. Is there a way to flag that the patch is already installed without updating the product version. If there are any good sources of material which answer some of these questions, please point them out to me. Thanks in advance sanjay - - 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 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. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast
Re: [WiX-users] Patching
Thanks for the information Peter. Some follow up: 1) In previous versions of our app, we distributed patches to the customer as a set of files in a zip that the customer simply unzips into the application directory. While this isn't ideal (because of the problems associated with uninstalling patches etc.) it is very flexible in that we can distribute any number of patches that are not dependant on each other, and the customer can install and test the features in any order. For example, If we deliver patch P1 and P2 to the customer in that order, they may decide to install P2 first because it requires a smaller test effort than P1. I'm not sure how I achieve the same using the MSI patching. Let's say we have 3 wixpdb files: mainprod.wixpdb, patch1.wixpdb, patch2.wixpdb. When release Patch1 we use the transform (mainprod-patch1). Then we release patch2 which is not dependant on patch1 so we use the transforms (mainprod-patch2 and patch1-patch2) to generate it. But that wouldn't work if the customer decided to install patch2 first and then patch1 would it? Might be that i'm missing something obvious here! 3) I think I prefer to segment my components into different fragments and use the wixpdb to generate the mappings as doing admin install is a bit of a pain and potentially more error prone for us. Does anyone know if there is an easy way to do this (eg, if I harvest files using heat for my initial release, can it generate a different fragment for each component?). Another question and potential issue I thought of: Most of the files we distribute are binary (PowerBuilder) files. Will torch be able to generate the transform correctly for these? thanks sanjay -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 11 January 2012 10:49 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching I'll try and answer this but it's best to seek some other opinions too. 1. The order of patch installation wont usually matter. When you create a patch, you target it at a particular version or even multiple versions (eg patched/upgraded installations) and MSI works out the right sequence. See the MS patching whitepaper at http://www.microsoft.com/download/en/details.aspx?id=19013 You do this by creating one or more transforms (diffs) with the torch tool and passing them when you create the patch with pyro. 2. The 4th version field of the MSI product version is ignored by Windows installer. You can use it for information but we don't - some APIs will retrieve the 4th field however. We use [major version].[service pack].[build] The files in your installer have no such restrictions. Version those in whatever way suits you. 3. The way we do that currently is to build the patch from administrative installations of the released and updated MSIs instead of using wixpdbs. http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something- you-didn t-build-with-wix-using-wix-.aspx and other articles in that blog. 4. MSI records what patches are applied to a product. It depends on how you want to retrieve the information. You can use MsiEnumPatches() from C++ for example. You could also install something to act as a marker. Useful links include: MSDN on Windows installer Peter Marcu's blog Heath Stewart's blog Rob Menchsings blog (and others on the Wix team) This mailing list's archives Wix docs -Original Message- From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] Sent: 10 January 2012 23:18 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching I am in the process of writing an installer for a company product (we were previously using Installshield). Once, released we will need the produce patches for bug fixes and enhancements. The expectation that these patches will consist of simply updating some of the released files and/or adding new files not part of the initial distribution. I think we will generally do a minor upgrade. In some cases the patches are dependent on a previous patch and in other cases not. Therefore I've been reading material about how we should structure our initial release of the product to best enable but still have some questions about things that aren't clear. Can someone help me here: 1. How can we generate the diff against the installed version for the patches that can be installed in any order. We are not sure what the users machine will have because they may have already applied one of the other patches. Surely we don't need to generate a patch for each possible order of installation of all the patches. 2. We can update the 3rd or 4th component of product version when doing an upgrade/patch for some. Can someone explain the consequences of each option. When we generate a diff for the patch, does the generated patch use the product version and only patch against it or does
[WiX-users] Patching
I am in the process of writing an installer for a company product (we were previously using Installshield). Once, released we will need the produce patches for bug fixes and enhancements. The expectation that these patches will consist of simply updating some of the released files and/or adding new files not part of the initial distribution. I think we will generally do a minor upgrade. In some cases the patches are dependent on a previous patch and in other cases not. Therefore I've been reading material about how we should structure our initial release of the product to best enable but still have some questions about things that aren't clear. Can someone help me here: 1. How can we generate the diff against the installed version for the patches that can be installed in any order. We are not sure what the users machine will have because they may have already applied one of the other patches. Surely we don't need to generate a patch for each possible order of installation of all the patches. 2. We can update the 3rd or 4th component of product version when doing an upgrade/patch for some. Can someone explain the consequences of each option. When we generate a diff for the patch, does the generated patch use the product version and only patch against it or does it only patch products with matching Product GUID and file versions. 3. When creating a patch, I want to explicitly specify the collection of files (DLLs etc.) to be upgraded. I don't want any other existing files to be touched. I have read that when you specify a patch components (i.e. via ComponentRef) inside a PatchFamily element, any components in the same fragment will also be updated. Can I avoid this without having to create different fragments for every component in my product which is a bit of a pain. 4. As far as I can tell, you can always apply a patch (msp) multiple times even if the product is already patched. Is there a way to flag that the patch is already installed without updating the product version. If there are any good sources of material which answer some of these questions, please point them out to me. Thanks in advance sanjay -- 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
[WiX-users] patching using burn
Hi: I'm currently writing a bundle using burn. Later on we will need to write and release patches. As I am using burn, can I use plain .msp/msu files or do I have to use a .exe file? Any help appreciated. Regards Sean. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] patching using burn
You can ship your patches as plain .msp files or you can wrap the .msp files in another Bundle (great if you need to apply multiple patches or want to show a custom UI). On Sat, Mar 26, 2011 at 5:28 AM, Sean Farrow sean.far...@seanfarrow.co.ukwrote: Hi: I'm currently writing a bundle using burn. Later on we will need to write and release patches. As I am using burn, can I use plain .msp/msu files or do I have to use a .exe file? Any help appreciated. Regards Sean. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching Merge module
Hi All, I am building WIX MSI that has integrated Merge Module. Now I am creating patches for this MSI. I know that I can specify ComponentRef's in my patch.wxs file but is there any way to provide patch for the integrated Merge Module? Thank You all in advance. Regards, AK. DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching Merge module
You patch the MSI, not the merge module, so you need to use the Component Ids as they appear in the MSI. Open your release MSI in something like Orca or InstEd and you can look up the component Ids as they appear after merging. Include those in your patch.wxs. -Original Message- From: Arun Kumar [mailto:arun_jku...@persistent.co.in] Sent: 10 March 2011 09:20 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Patching Merge module Hi All, I am building WIX MSI that has integrated Merge Module. Now I am creating patches for this MSI. I know that I can specify ComponentRef's in my patch.wxs file but is there any way to provide patch for the integrated Merge Module? Thank You all in advance. Regards, AK. DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. - - Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ 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. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching Using Purely Wix
Peter, Thanks you for your reply. This does seem very promising; I'll let you know how we get on with it. Cheers, Liam -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 17 February 2011 10:55 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching Using Purely Wix Would creating a pure Wix patch from administrative installations work for you ? It's what we do here. This gives you an idea of the process. http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something-you-did n t-build-with-wix-using-wix-.aspx -Original Message- From: Liam Flanagan [mailto:l...@dyalog.com] Sent: 16 February 2011 12:46 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching Using Purely Wix Hello All, I've been wondering if it's possible to create minor patches using the purely wix method, however only using the baseline and QFE MSI packages instead of requiring the original source files and structure that the MSIs were built from. I want have the benefits of purely wix patching (i.e. referencing wix components etc) however not the complexity of having build output snapshots that have a large quantities of files and file structures, instead simply the released MSIs. The table in this msdn blog ( http://blogs.msdn.com/b/heaths/archive/2010/08/24/comparison-of-patchwiz-and -wix-v3-patch-build.aspx ) implies that these should be possible; although I guess not all at the same time. (CF: ticks in the Ignore certain other resource types to be upgraded by the patch (ex: registry values, components, etc.) and Can automatically extract compressed files when creating transforms. Boxes) A little background into what I've tried so far: . Using the wixpdb files with torch to create the transform between the two versions appears to require the original msi build structure when creating the patch . Using torch on the msi files as standard appears to create a binary mst file, I presume this is for use with PatchWiz as Wix tools don't seem to like this at all . If whilst using torch on the msi files you specify you want an xml output (wixout) you appear to get a file very similar to that of the output when using torch on the wixpdb files, however you appear to lose all information about wix structures (wix components/component groups etc). Therefore if I try to specify them in the patch.wxs, pyro doesn't understand what differences you're actually trying to bring through in the patch. Furthermore on this, this fairly dated blog post ( http://blogs.msdn.com/b/pmarcu/archive/2007/04/27/building-a-patch-using-wix -v3-0.aspx ) implies that when creating the original msi files creating an interim wixmsi and using light to convert that into an MSI rather than just lighting the wixobj may change the game a bit; however I couldn't get this to work. The produced MSI files whilst having different md5sums appeared identical in Orca and furthermore produced identical wixout files via torch. Is what I'm hoping for achievable? Thanks, Liam - - The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ 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. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel
Re: [WiX-users] Patching Using Purely Wix
Would creating a pure Wix patch from administrative installations work for you ? It's what we do here. This gives you an idea of the process. http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something-you-didn t-build-with-wix-using-wix-.aspx -Original Message- From: Liam Flanagan [mailto:l...@dyalog.com] Sent: 16 February 2011 12:46 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching Using Purely Wix Hello All, I've been wondering if it's possible to create minor patches using the purely wix method, however only using the baseline and QFE MSI packages instead of requiring the original source files and structure that the MSIs were built from. I want have the benefits of purely wix patching (i.e. referencing wix components etc) however not the complexity of having build output snapshots that have a large quantities of files and file structures, instead simply the released MSIs. The table in this msdn blog ( http://blogs.msdn.com/b/heaths/archive/2010/08/24/comparison-of-patchwiz-and -wix-v3-patch-build.aspx ) implies that these should be possible; although I guess not all at the same time. (CF: ticks in the Ignore certain other resource types to be upgraded by the patch (ex: registry values, components, etc.) and Can automatically extract compressed files when creating transforms. Boxes) A little background into what I've tried so far: . Using the wixpdb files with torch to create the transform between the two versions appears to require the original msi build structure when creating the patch . Using torch on the msi files as standard appears to create a binary mst file, I presume this is for use with PatchWiz as Wix tools don't seem to like this at all . If whilst using torch on the msi files you specify you want an xml output (wixout) you appear to get a file very similar to that of the output when using torch on the wixpdb files, however you appear to lose all information about wix structures (wix components/component groups etc). Therefore if I try to specify them in the patch.wxs, pyro doesn't understand what differences you're actually trying to bring through in the patch. Furthermore on this, this fairly dated blog post ( http://blogs.msdn.com/b/pmarcu/archive/2007/04/27/building-a-patch-using-wix -v3-0.aspx ) implies that when creating the original msi files creating an interim wixmsi and using light to convert that into an MSI rather than just lighting the wixobj may change the game a bit; however I couldn't get this to work. The produced MSI files whilst having different md5sums appeared identical in Orca and furthermore produced identical wixout files via torch. Is what I'm hoping for achievable? Thanks, Liam - - The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ 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. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching Using Purely Wix
Hello All, I've been wondering if it's possible to create minor patches using the purely wix method, however only using the baseline and QFE MSI packages instead of requiring the original source files and structure that the MSIs were built from. I want have the benefits of purely wix patching (i.e. referencing wix components etc) however not the complexity of having build output snapshots that have a large quantities of files and file structures, instead simply the released MSIs. The table in this msdn blog ( http://blogs.msdn.com/b/heaths/archive/2010/08/24/comparison-of-patchwiz-and -wix-v3-patch-build.aspx ) implies that these should be possible; although I guess not all at the same time. (CF: ticks in the Ignore certain other resource types to be upgraded by the patch (ex: registry values, components, etc.) and Can automatically extract compressed files when creating transforms. Boxes) A little background into what I've tried so far: . Using the wixpdb files with torch to create the transform between the two versions appears to require the original msi build structure when creating the patch . Using torch on the msi files as standard appears to create a binary mst file, I presume this is for use with PatchWiz as Wix tools don't seem to like this at all . If whilst using torch on the msi files you specify you want an xml output (wixout) you appear to get a file very similar to that of the output when using torch on the wixpdb files, however you appear to lose all information about wix structures (wix components/component groups etc). Therefore if I try to specify them in the patch.wxs, pyro doesn't understand what differences you're actually trying to bring through in the patch. Furthermore on this, this fairly dated blog post ( http://blogs.msdn.com/b/pmarcu/archive/2007/04/27/building-a-patch-using-wix -v3-0.aspx ) implies that when creating the original msi files creating an interim wixmsi and using light to convert that into an MSI rather than just lighting the wixobj may change the game a bit; however I couldn't get this to work. The produced MSI files whilst having different md5sums appeared identical in Orca and furthermore produced identical wixout files via torch. Is what I'm hoping for achievable? Thanks, Liam -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching multiple major upgrade releases with different product codes
There is a 'hacky' way to do it but bear in mind that once you follow
the 'hacky' method, all future patches will be required to be built the
same way. Also because you've 4 Products, your patches are going to be
around 4 times as big as each Product will have it's own CAB (since it
has it's own transforms).
You need a Patch Family for each unique Product (in your case 4). To get
the new admin image for each one take a copy of the one you already
have, open it in an MSI editor like InstEd! or Orca, set the Product
Code to the same as one of the other versions regenerate the Package
code. Save your MSI you now have a version which will update another
Product. Do this another 2 times for the other 2 Products, set up your
Patch Family's accordingly add TargetProductCode elements for your 4
Products it should create an MSP containing the transforms for each
Product up to the new one (open the MSP in InstEd! or Orca you should
see a bunch of .mst files
It is a horrible horrible hack though as stated before, you'll need to
keep doing the same for each subsequent patch which is neither fun nor
quick to create test each time. Personally I'd release a Major Upgrade
in which you define your Product Code rather than using an
auto-generated one patch from that basis as it's more reliable way
less hassle.
Moral of the story: Using * for Product Id isn't always a good idea.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
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: Tom Crozier [mailto:tcroz...@rackwise.com]
Sent: 03 February 2011 20:13
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Patching multiple major upgrade releases with
different product codes
All -
I have multiple versions of a product released in the
field that I need to upgrade with a patch. The installer that all the
versions are all based on can perform a major upgrade from a previous
version. I believe they should have used the same product id but they
don't because the wxs file has '*' for the product id. All the versions
are basically the same except for a few additional files from the
original version to the latest one. The version numbers of the
installers only differ in the fourth place (e.g. 1.5.0.120, 1.5.0.147,
1.5.0.162 and 1.5.0.188)and they all use the same upgrade code.
My question is how do I go about creating a patch that can upgrade all
four versions and bring them up to the same version so they can be
updated in the future?
I seem to be able to create a patch against a single version but against
multiple versions I get the following error.
ERROR: Since MSI 3.0 will block installation of major upgrade patches
with sequencing information, creation of such patches is blocked.
The following is the start of my patch creation file which worked until
I put the second TargetImage line in.
?xml version='1.0' encoding='windows-1252'? Wix
xmlns=http://schemas.microsoft.com/wix/2006/wi;
?define var.Manufacturer = Acme, Inc.?
?define var.PRODUCTNAME = App ?
?define var.ReleaseNumber= 1.5.0 ?
PatchCreation Id='{01865DA7-1DE1-45ab-BB7C-7B89CA10CBCC}'
AllowMajorVersionMismatches='no'
AllowProductCodeMismatches='yes'
CleanWorkingFolder='yes'
WholeFilesOnly='yes'
PatchInformation
Description=App SP 1
Keywords='Installer,MSI,Database'
Comments='App SP 1'
Manufacturer='$(var.Manufacturer)'
Languages='1033'
Compressed='yes'
SummaryCodepage='1252'
ShortNames=no /
PatchMetadata
Description=1st service pack for App
DisplayName='App SP 1'
TargetProductName='$(var.PRODUCTNAME) v$(var.ReleaseNumber)'
ManufacturerName='$(var.Manufacturer)'
MoreInfoURL='www.acme.com'
Classification='Service Pack'
AllowRemoval='no' /
Family
Name='APP150'
DiskId='3'
MediaSrcProp='APP150Src'
SequenceStart='2000'
UpgradeImage
Id='PatchedImage'
SourceFile='C:\Official Releases\1.5.0.227\AdminVer\App.msi'
TargetImage
Id='OrigImage'
Order='2'
IgnoreMissingFiles='no'
SourceFile='C:\Official Releases\1.5.0.120\AdminVer\App.msi'/
TargetImage
Id='OrigImage2'
Order='3'
IgnoreMissingFiles='no'
SourceFile='C:\Official Releases\1.5.0.147\AdminVer\App.msi'/
/UpgradeImage
/Family
/PatchCreation
/Wix
Thanks for your help
Tom
--
The modern datacenter depends on network connectivity to access
resources and provide services. The best practices for maximizing
[WiX-users] Patching multiple major upgrade releases with different product codes
All -
I have multiple versions of a product released in the field
that I need to upgrade with a patch. The installer that all the versions are
all based on can perform a major upgrade from a previous version. I believe
they should have used the same product id but they don't because the wxs file
has '*' for the product id. All the versions are basically the same except for
a few additional files from the original version to the latest one. The version
numbers of the installers only differ in the fourth place (e.g. 1.5.0.120,
1.5.0.147, 1.5.0.162 and 1.5.0.188)and they all use the same upgrade code.
My question is how do I go about creating a patch that can upgrade all four
versions and bring them up to the same version so they can be updated in the
future?
I seem to be able to create a patch against a single version but against
multiple versions I get the following error.
ERROR: Since MSI 3.0 will block installation of major upgrade patches with
sequencing information, creation of such patches is blocked.
The following is the start of my patch creation file which worked until I put
the second TargetImage line in.
?xml version='1.0' encoding='windows-1252'?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
?define var.Manufacturer = Acme, Inc.?
?define var.PRODUCTNAME = App ?
?define var.ReleaseNumber= 1.5.0 ?
PatchCreation Id='{01865DA7-1DE1-45ab-BB7C-7B89CA10CBCC}'
AllowMajorVersionMismatches='no'
AllowProductCodeMismatches='yes'
CleanWorkingFolder='yes'
WholeFilesOnly='yes'
PatchInformation
Description=App SP 1
Keywords='Installer,MSI,Database'
Comments='App SP 1'
Manufacturer='$(var.Manufacturer)'
Languages='1033'
Compressed='yes'
SummaryCodepage='1252'
ShortNames=no /
PatchMetadata
Description=1st service pack for App
DisplayName='App SP 1'
TargetProductName='$(var.PRODUCTNAME) v$(var.ReleaseNumber)'
ManufacturerName='$(var.Manufacturer)'
MoreInfoURL='www.acme.com'
Classification='Service Pack'
AllowRemoval='no' /
Family
Name='APP150'
DiskId='3'
MediaSrcProp='APP150Src'
SequenceStart='2000'
UpgradeImage
Id='PatchedImage'
SourceFile='C:\Official Releases\1.5.0.227\AdminVer\App.msi'
TargetImage
Id='OrigImage'
Order='2'
IgnoreMissingFiles='no'
SourceFile='C:\Official Releases\1.5.0.120\AdminVer\App.msi'/
TargetImage
Id='OrigImage2'
Order='3'
IgnoreMissingFiles='no'
SourceFile='C:\Official Releases\1.5.0.147\AdminVer\App.msi'/
/UpgradeImage
/Family
/PatchCreation
/Wix
Thanks for your help
Tom
--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching and properties
Hi there, Is it possible to pass a property value somehow to a custom action when installing a new patch (in stead of passing it with the command line)? And also I want to know if it is possible to get the patch version being installed with a custom action. I did run the following command : misiexec /update patch.msp /l*v logfile.txt, but I didn't see the a patch version property somewhere, only the patch description etc Regards, Henk Roos DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching and properties
Patches don't have versions. The version would be the ProductVersion of the new version your patch is upgrading the old version to. I don't quite understand your question regarding passing properties to Custom Actions. Can you elaborate on what you're trying to do? Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** 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: Henk Roos [mailto:henk.r...@aricent.com] Sent: 16 November 2010 09:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching and properties Hi there, Is it possible to pass a property value somehow to a custom action when installing a new patch (in stead of passing it with the command line)? And also I want to know if it is possible to get the patch version being installed with a custom action. I did run the following command : misiexec /update patch.msp /l*v logfile.txt, but I didn't see the a patch version property somewhere, only the patch description etc Regards, Henk Roos DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching with WiX
This is the same situation as we have here. It's preferable, if you can to carry the build through to completion to produce a new, updated MSI as though you were going to do a major upgrade. Then perform an admin install of that and add Ref elements into the Family element to choose which parts of it to include in the patch. If you cant do that and have to duplicate the source admin install and drop files into it, then you will have more work to do. The relevant tables in the updated MSI have to be updated. I used a VBScript for this. The product version needs updating and a PropertyRef adding too. You wont need to create a new package code for making the patch. Updating a versioned file just requires changes to the File table. Updating a non-versioned file means generating and updating the MSI file hash too. Adding a new file means you have to create a File, Component, Then theres the possibility you might be registering the file for COM, GAC, etc We only had a few files when doing that so it was manageable but it can become a lot of work, hence my recommendation to do the build work, which is less error prone. Once the target has been prepared, you run torch and pyro to make the patch. If youve any more specific questions then feel free to ask. I could probably send you my wix, vbscript and msbuild scripts, which are simple enough. Most of my information comes from Peters blog, this list and trial and error. The comments section on the blog contains useful info too. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: 04 October 2010 18:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching with WiX I was wondering if anyone could provide me with any links or pointers for the following story. Foo.msi is a large ( 15,000 files ) installer that is currently build with InstallShield and services via Major Upgrades. Foo.msi's file comes from a couple dozen builds and the upstream build team doesn't do incremental builds. All DLL's will be rebuilt with newer version numbers. The goal is to check pick files from the latest build and generate a patch for the fielded build. I've read Peter Marcu's blog on patching installers you didn't build with WiX and the part about doing an admin install, make a copy of the extract and drop your files in seems to be close to what I'm looking for but it was pretty light on details. Has anyone ever done this? What I'm trying to do is somewhat like InstallShield QuickPatch projects only I want to do alot more automation then IS (seems to) allow. Thanks, Chris Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ 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. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching with WiX
I can certainly build through to completion and do an admin install. I require that to ensure that the new baseline the patch is being pulled from actually works in the first place. You lost me completely though about how to use the Family element. The second suggestion does seem like quite a bit of work but it seems doable. I'd use a NAnt task written in C#/DTF. I want to dig deeper until I understand your first option before deciding to play with the second. Thanks, Chris Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Peter Shirtcliffe pshirtcli...@sdl.com To: wix-users@lists.sourceforge.net Sent: Tue, October 5, 2010 4:11:31 AM Subject: Re: [WiX-users] Patching with WiX This is the same situation as we have here. It's preferable, if you can to carry the build through to completion to produce a new, updated MSI as though you were going to do a major upgrade. Then perform an admin install of that and add Ref elements into the Family element to choose which parts of it to include in the patch. If you cant do that and have to duplicate the source admin install and drop files into it, then you will have more work to do. The relevant tables in the updated MSI have to be updated. I used a VBScript for this. The product version needs updating and a PropertyRef adding too. You wont need to create a new package code for making the patch. Updating a versioned file just requires changes to the File table. Updating a non-versioned file means generating and updating the MSI file hash too. Adding a new file means you have to create a File, Component, Then theres the possibility you might be registering the file for COM, GAC, etc We only had a few files when doing that so it was manageable but it can become a lot of work, hence my recommendation to do the build work, which is less error prone. Once the target has been prepared, you run torch and pyro to make the patch. If youve any more specific questions then feel free to ask. I could probably send you my wix, vbscript and msbuild scripts, which are simple enough. Most of my information comes from Peters blog, this list and trial and error. The comments section on the blog contains useful info too. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: 04 October 2010 18:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching with WiX I was wondering if anyone could provide me with any links or pointers for the following story. Foo.msi is a large ( 15,000 files ) installer that is currently build with InstallShield and services via Major Upgrades. Foo.msi's file comes from a couple dozen builds and the upstream build team doesn't do incremental builds. All DLL's will be rebuilt with newer version numbers. The goal is to check pick files from the latest build and generate a patch for the fielded build. I've read Peter Marcu's blog on patching installers you didn't build with WiX and the part about doing an admin install, make a copy of the extract and drop your files in seems to be close to what I'm looking for but it was pretty light on details. Has anyone ever done this? What I'm trying to do is somewhat like InstallShield QuickPatch projects only I want to do alot more automation then IS (seems to) allow. Thanks, Chris Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ 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. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb
Re: [WiX-users] Patching with WiX
In the first option, the steps are: - build the updated msi with all the changes - perform admin installs of both the current release and the newly built msi - create your patch as a diff between the 2 MSIs (as usual) with torch, pyro and a wix file. The difference is that the wix file contains something like this: PatchFamily Id='StudioPatchFamily' Version='1.0.0.20' Supersede='yes' PropertyRef Id=ProductVersion/ !-- Bug 40378. -- ComponentRef Id=Sdl.Desktop.Platform.WinForms.Comp.E3C36A31_E19F_4D61_B5C3_A03E1671CB97 / !-- Bug 40277. -- ComponentRef Id=Sdl.TMServer.Client.Comp.69DA4EB2_DA47_41E5_870E_013063EB91D7 / !-- Bug 40251 Chinese localisation. -- ComponentRef Id=Sdl.Desktop.Platform.plugin.zh_CN.resources.E3C36A31_E19F_4D61_B5C3_A03E1671CB97 / ComponentRef Id=Sdl.LanguagePlatform.MTConnectors.Google.plugin.zh_CN.resources / /PatchFamily This ensures that only the items you want to include in the patch end up in the finished MSP. The above example pulls in the product version property and 4 components. No other changes will be included in the patch. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: 05 October 2010 13:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching with WiX I can certainly build through to completion and do an admin install. I require that to ensure that the new baseline the patch is being pulled from actually works in the first place. You lost me completely though about how to use the Family element. The second suggestion does seem like quite a bit of work but it seems doable. I'd use a NAnt task written in C#/DTF. I want to dig deeper until I understand your first option before deciding to play with the second. Thanks, Chris Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Peter Shirtcliffe pshirtcli...@sdl.com To: wix-users@lists.sourceforge.net Sent: Tue, October 5, 2010 4:11:31 AM Subject: Re: [WiX-users] Patching with WiX This is the same situation as we have here. It's preferable, if you can to carry the build through to completion to produce a new, updated MSI as though you were going to do a major upgrade. Then perform an admin install of that and add Ref elements into the Family element to choose which parts of it to include in the patch. If you cant do that and have to duplicate the source admin install and drop files into it, then you will have more work to do. The relevant tables in the updated MSI have to be updated. I used a VBScript for this. The product version needs updating and a PropertyRef adding too. You wont need to create a new package code for making the patch. Updating a versioned file just requires changes to the File table. Updating a non-versioned file means generating and updating the MSI file hash too. Adding a new file means you have to create a File, Component, Then theres the possibility you might be registering the file for COM, GAC, etc We only had a few files when doing that so it was manageable but it can become a lot of work, hence my recommendation to do the build work, which is less error prone. Once the target has been prepared, you run torch and pyro to make the patch. If youve any more specific questions then feel free to ask. I could probably send you my wix, vbscript and msbuild scripts, which are simple enough. Most of my information comes from Peters blog, this list and trial and error. The comments section on the blog contains useful info too. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: 04 October 2010 18:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching with WiX I was wondering if anyone could provide me with any links or pointers for the following story. Foo.msi is a large ( 15,000 files ) installer that is currently build with InstallShield and services via Major Upgrades. Foo.msi's file comes from a couple dozen builds and the upstream build team doesn't do incremental builds. All DLL's will be rebuilt with newer version numbers. The goal is to check pick files from the latest build and generate a patch for the fielded build. I've read Peter Marcu's blog on patching installers you didn't build with WiX and the part about doing an admin install, make a copy of the extract and drop your files in seems to be close to what I'm looking for but it was pretty light on details. Has anyone ever done this? What I'm trying to do is somewhat like InstallShield QuickPatch projects only I want to do alot more automation then IS (seems to) allow. Thanks, Chris Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread
[WiX-users] Patching with WiX
I was wondering if anyone could provide me with any links or pointers for the following story. Foo.msi is a large ( 15,000 files ) installer that is currently build with InstallShield and services via Major Upgrades. Foo.msi's file comes from a couple dozen builds and the upstream build team doesn't do incremental builds. All DLL's will be rebuilt with newer version numbers. The goal is to check pick files from the latest build and generate a patch for the fielded build. I've read Peter Marcu's blog on patching installers you didn't build with WiX and the part about doing an admin install, make a copy of the extract and drop your files in seems to be close to what I'm looking for but it was pretty light on details. Has anyone ever done this? What I'm trying to do is somewhat like InstallShield QuickPatch projects only I want to do alot more automation then IS (seems to) allow. Thanks, Chris Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] patching a single file
hi Sunkesula, Srivardhan, how your question is merged in to my query? is there any problem ? srinivas -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/setting-the-existing-apppool-to-my-virtual-directory-other-than-than-the-default-apppool-tp5234034p5276998.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] patching a single file
Hi, I would like to create a patch which can install a single file/component. I specified the component, say SampleComponent which I want to patch as shown below: Fragment PatchFamily Id='SamplePatchFamily' Version='1.0.0.0' Supersede='yes' ComponentRef Id=SampleComponent/ /PatchFamily /Fragment But this is patching all the components in the product. Can anyone help solve this issue? Thanks Regards, Srivardhan. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] patching a single file
Place the SampleComponent component in its own Fragment. -Original Message- From: Sunkesula, Srivardhan [mailto:srivardhan.sunkes...@netapp.com] Sent: Tuesday, June 29, 2010 2:57 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] patching a single file Hi, I would like to create a patch which can install a single file/component. I specified the component, say SampleComponent which I want to patch as shown below: Fragment PatchFamily Id='SamplePatchFamily' Version='1.0.0.0' Supersede='yes' ComponentRef Id=SampleComponent/ /PatchFamily /Fragment But this is patching all the components in the product. Can anyone help solve this issue? Thanks Regards, Srivardhan. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching multiple instances of product using new purely Wix process.
I am using the new Wix patching process to create my MSPs. I am having trouble with my patches working on multiple instances of my product. The patch complains that the product is not installed. Using the patchwiz process patching multiple instances worked. The patch runs against the default instance fine. Has anyone else used the new patching process for a product which allows multiple instances? Are there examples available for this scenario? Thank you. _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching Base Versions
I had a question about whether a feature is supported and haven't seen any WiX documentation that really answers my question. Basically I was curious as to how patches could be installed and supersede each other based on the base used to create the patch. For example if I have Product v1.0.3 directly. I can create a patch for Product v1.0.3 using it as a base and patching to Product v1.0.4. My question is, would I be able to install a patch created using the base Product v1.0.1 which patches to Product v1.0.4, and successfully install it on Product v1.0.3. Currently this is effort is failing with a message saying the program to be upgraded may be missing or the upgrade patch may update a different version of the program. I'm not sure if this is because I have a problem with the patch or if this just isn't supported by WiX. If this is supported by WiX, what would be the best way to go about doing it? Thanks in advance, Big Jim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-Base-Versions-tp5127849p5127849.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] Patching Base Versions
I had a question about whether a feature is supported in WiX or not. I haven't seen any WiX documentation that really answers my question. Basically I was curious as to how patches could be installed and supersede each other based on the base used to create the patch. For example if I have Product v1.0.3 directly. I can create a patch for Product v1.0.3 using it as a base and patching to Product v1.0.4. My question is would I be able to install a patch created using the base Product v1.0.1 which patches to Product v1.0.4 and successfully install it on Product v1.0.3? Currently this effort is failing with a message saying the program to be upgraded may be missing or the upgrade patch may update a different version of the program. I'm not sure if this is because I have a problem with the patch or if this just isn't supported by WiX. If this is supported by WiX, what would be the best way to go about doing it? Thanks in advance, Big Jim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-Base-Versions-tp5127869p5127869.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
Re: [WiX-users] Patching Base Versions
I always use just one base but multiple bases (i.e. targets) are possible from what I understand from the documentation. I avoid them because that increases the size of the patch (differences from both bases must be stored in a patch) but it should work if you declare two targets. -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Tuesday, June 01, 2010 4:22 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching Base Versions I had a question about whether a feature is supported and haven't seen any WiX documentation that really answers my question. Basically I was curious as to how patches could be installed and supersede each other based on the base used to create the patch. For example if I have Product v1.0.3 directly. I can create a patch for Product v1.0.3 using it as a base and patching to Product v1.0.4. My question is, would I be able to install a patch created using the base Product v1.0.1 which patches to Product v1.0.4, and successfully install it on Product v1.0.3. Currently this is effort is failing with a message saying the program to be upgraded may be missing or the upgrade patch may update a different version of the program. I'm not sure if this is because I have a problem with the patch or if this just isn't supported by WiX. If this is supported by WiX, what would be the best way to go about doing it? Thanks in advance, Big Jim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-Base-Versions-tp5127849p5127849.html Sent from the wix-users mailing list archive at Nabble.com. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching Base Versions
Here is one example where you can try insert additional targets (bases)
?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
?include VersionDefinitions.wxi ?
?include PatchCreationDefinitions.wxi ?
!-- patch id needs to be updated --
PatchCreation Id={codes}
AllowMajorVersionMismatches=no
AllowProductCodeMismatches=no
CleanWorkingFolder=yes
WholeFilesOnly=no
Codepage=1252
PatchInformation Description=Product $(var.MAJORMINORVERSION) Update
Keywords=Installer Update Hotfix Patch
Comments=Patches Product $(var.MAJORMINORVERSION)
Manufacturer=My Co
Languages=1033
Compressed=yes
SummaryCodepage=1252
AdminImage=yes/
PatchMetadata Description=Product $(var.MAJORMINORVERSION) (Update
$(var.THISBUILD))
DisplayName=Product $(var.MAJORMINORVERSION) (Update
$(var.THISBUILD))
TargetProductName=Product $(var.MAJORMINORVERSION)
ManufacturerName=My Co
MoreInfoURL=http://www.myco.com;
Classification=$(var.CLASSIFICATION)
AllowRemoval=yes
OptimizedInstallMode=yes /
Family Name=$(var.FAMILYID) DiskId=2
MediaSrcProp=PATCH$(var.THISBUILD) SequenceStart=$(var.SEQSTART)
UpgradeImage Id=Patch$(var.CURQFEID)
SourceFile=$(var.CURQFEPATH)\myupgrade.msi
TargetImage Id=PatchRTM Order=1 IgnoreMissingFiles=no
SourceFile=$(var.RTMPATH)\mytarget.msi /
!-- add new targets here --
/UpgradeImage
/Family
TargetProductCode Id=$(var.PRODUCTCODE) /
PatchSequence PatchFamily=$(var.FAMILYNAME)
Sequence=$(var.SEQUENCE) /
/PatchCreation
/Wix
-Original Message-
From: XorPtr [mailto:reaper4...@gmail.com]
Sent: Tuesday, June 01, 2010 4:22 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Patching Base Versions
I had a question about whether a feature is supported and haven't seen any
WiX documentation that really answers my question. Basically I was curious
as to how patches could be installed and supersede each other based on the
base used to create the patch.
For example if I have Product v1.0.3 directly.
I can create a patch for Product v1.0.3 using it as a base and patching to
Product v1.0.4.
My question is, would I be able to install a patch created using the base
Product v1.0.1 which patches to Product v1.0.4, and successfully install it
on Product v1.0.3. Currently this is effort is failing with a message
saying the program to be upgraded may be missing or the upgrade patch may
update a different version of the program.
I'm not sure if this is because I have a problem with the patch or if this
just isn't supported by WiX. If this is supported by WiX, what would be the
best way to go about doing it?
Thanks in advance,
Big Jim.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-Base-Versions-tp5127849p5127849.html
Sent from the wix-users mailing list archive at Nabble.com.
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD)
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE,
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and
subscription company, and TradeStation Europe Limited, a United Kingdom,
FSA-authorized introducing brokerage firm. None of these companies provides
trading or investment advice, recommendations or endorsements of any kind. The
information transmitted is intended only for the person or entity to which it
is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please contact
the sender and delete the material from any computer.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching Base Versions
If you are using Torch and Pyro (with the Patch element) instead of the
PatchCreation element, you run torch additional times to create the
transforms from each target to the Updated build and pass each of the wixmst
files separately to pyro.
The concept is the same: the patch contains multiple transforms, one set for
each target. The size of the MSP file, of course, increases nearly
linearly with each additional base you target.
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com]
Sent: Tuesday, June 01, 2010 1:45 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching Base Versions
Here is one example where you can try insert additional targets (bases)
?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
?include VersionDefinitions.wxi ?
?include PatchCreationDefinitions.wxi ?
!-- patch id needs to be updated --
PatchCreation Id={codes}
AllowMajorVersionMismatches=no
AllowProductCodeMismatches=no
CleanWorkingFolder=yes
WholeFilesOnly=no
Codepage=1252
PatchInformation Description=Product $(var.MAJORMINORVERSION) Update
Keywords=Installer Update Hotfix Patch
Comments=Patches Product $(var.MAJORMINORVERSION)
Manufacturer=My Co
Languages=1033
Compressed=yes
SummaryCodepage=1252
AdminImage=yes/
PatchMetadata Description=Product $(var.MAJORMINORVERSION) (Update
$(var.THISBUILD))
DisplayName=Product $(var.MAJORMINORVERSION) (Update
$(var.THISBUILD))
TargetProductName=Product $(var.MAJORMINORVERSION)
ManufacturerName=My Co
MoreInfoURL=http://www.myco.com;
Classification=$(var.CLASSIFICATION)
AllowRemoval=yes
OptimizedInstallMode=yes /
Family Name=$(var.FAMILYID) DiskId=2
MediaSrcProp=PATCH$(var.THISBUILD) SequenceStart=$(var.SEQSTART)
UpgradeImage Id=Patch$(var.CURQFEID)
SourceFile=$(var.CURQFEPATH)\myupgrade.msi
TargetImage Id=PatchRTM Order=1 IgnoreMissingFiles=no
SourceFile=$(var.RTMPATH)\mytarget.msi /
!-- add new targets here --
/UpgradeImage
/Family
TargetProductCode Id=$(var.PRODUCTCODE) /
PatchSequence PatchFamily=$(var.FAMILYNAME)
Sequence=$(var.SEQUENCE) /
/PatchCreation
/Wix
-Original Message-
From: XorPtr [mailto:reaper4...@gmail.com]
Sent: Tuesday, June 01, 2010 4:22 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Patching Base Versions
I had a question about whether a feature is supported and haven't seen any
WiX documentation that really answers my question. Basically I was curious
as to how patches could be installed and supersede each other based on the
base used to create the patch.
For example if I have Product v1.0.3 directly.
I can create a patch for Product v1.0.3 using it as a base and patching to
Product v1.0.4.
My question is, would I be able to install a patch created using the base
Product v1.0.1 which patches to Product v1.0.4, and successfully install it
on Product v1.0.3. Currently this is effort is failing with a message
saying the program to be upgraded may be missing or the upgrade patch may
update a different version of the program.
I'm not sure if this is because I have a problem with the patch or if this
just isn't supported by WiX. If this is supported by WiX, what would be the
best way to go about doing it?
Thanks in advance,
Big Jim.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patching-Base-
Versions-tp5127849p5127849.html
Sent from the wix-users mailing list archive at Nabble.com.
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS:
TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member
NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading
software and subscription company, and TradeStation Europe Limited, a United
Kingdom, FSA-authorized introducing brokerage firm. None of these companies
provides trading or investment advice, recommendations or endorsements of
any kind. The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https
[WiX-users] Patching, WIX 3.0 (build 5419.0)
Hi,
Was wondering if somebody could help. I'm trying to create a patch (MSP)
for my installation and have being following the tutorial on
http://www.tramontana.co.hu/wix/lesson4.php
Which has been very helpful.
I had the original wixpdb for my original installation, which was handy :)
So following the instructions from the above page, I thought that I would
start with the a simple project first..
So created the following wix project:
!--- Original install.wxs - Start ---!
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
ProductId=48C49ACE-90CF-4161-9C6E-9162115A54DD
Name=WiX Patch Example Product
Language=1033
Version=1.0.0
Manufacturer=Dynamo Corporation
UpgradeCode=48C49ACE-90CF-4161-9C6E-9162115A54DD
PackageCompressed=yes
Description=Installs a file that will be patched.
Comments=This Product does not install any
executables
InstallerVersion=200
InstallScope=perMachine
/
Media Id=1 Cabinet=product.cab EmbedCab=yes /
FeatureRef Id=SampleProductFeature/
/Product
Fragment
Feature Id=SampleProductFeature Title=Sample Product Feature
Level=1
ComponentRef Id=SampleComponent /
ComponentRef Id=Sample2/
/Feature
/Fragment
Fragment
DirectoryRef Id=SampleProductFolder
Component Id=SampleComponent
Guid={C28843DA-EF08-41CC-BA75-D2B99D8A1983} DiskId=1
File Id=SampleFile Name=Sample.txt
Source=$(var.ProjectDir)..\Files\org\Readme.txt/
/Component
/DirectoryRef
/Fragment
Fragment
DirectoryRef Id=SampleProductFolder
Component Id=Sample2
Guid={923248E0-B4B5-4c8c-B343-420EE64CEF88} DiskId=1
File Id=SampleFile2 Name=Sample2.txt
Source=$(var.ProjectDir)..\Files\org\Readme2.txt/
/Component
/DirectoryRef
/Fragment
Fragment
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder Name=PFiles
Directory Id=SampleProductFolder Name=Patch Sample
Directory
/Directory
/Directory
/Directory
/Fragment
/Wix
!--- Original install.wxs - End ---!
Build the install.wxs project in the normal way to get the install.wixpdb
Then duplicated the original install.wxs to fixed.wxs and then duplicated
the 2 original txt files, altered the content of both.
Then altered fixed.wxs as follows:
!--- Fixed.wxs - Start ---!
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
ProductId=48C49ACE-90CF-4161-9C6E-9162115A54DD
Name=WiX Patch Example Product
Language=1033
Version=1.0.1
Manufacturer=Dynamo Corporation
UpgradeCode=48C49ACE-90CF-4161-9C6E-9162115A54DD
PackageCompressed=yes
Description=Installs a file that will be patched.
Comments=This Product does not install any executables
InstallerVersion=200
InstallScope=perMachine
/
Media Id=1 Cabinet=product.cab EmbedCab=yes /
FeatureRef Id=SampleProductFeature/
/Product
Fragment
Feature Id=SampleProductFeature Title=Sample Product Feature
Level=1
ComponentRef Id=SampleComponent /
ComponentRef Id=Sample2 /
/Feature
/Fragment
Fragment
DirectoryRef Id=SampleProductFolder
Component Id=SampleComponent
Guid={C28843DA-EF08-41CC-BA75-D2B99D8A1983} DiskId=1
File Id=SampleFile Name=Sample.txt
Source=$(var.ProjectDir)..\Files\Patch1\Readme.txt/
/Component
/DirectoryRef
/Fragment
Fragment
DirectoryRef Id=SampleProductFolder
Component Id=Sample2
Guid={923248E0-B4B5-4c8c-B343-420EE64CEF88} DiskId=1
File Id=SampleFile2 Name=Sample2.txt
Source=$(var.ProjectDir)..\Files\Patch1\Readme2.txt /
/Component
/DirectoryRef
/Fragment
Fragment
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder Name=PFiles
Directory Id=SampleProductFolder Name=Patch Sample
Directory
/Directory
/Directory
/Directory
/Fragment
/Wix
!--- Fixed.wxs - End ---!
Build the fixed.wxs project in the normal way to get the fixed.wixpdb
I then created a patch.wxs to create the MSP:
!--- Patch.wxs - Start ---!
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Patch
AllowRemoval=yes
Manufacturer=Dynamo Corp
Re: [WiX-users] Patching a single component
I figured it out. Deep down in the comments on one of Peter Marcu's Blog posts about patching: The PatchFamily filters on components and the fragments they are contained within. E.g. if you reference a component that [is] contained within a fragment with 10 other components. The patch will contain all 11 components. - John Hopefully someone else will find this information helpful. -And -Original Message- From: Andy Glass [mailto:agl...@laserfiche.com] Sent: Wednesday, March 10, 2010 3:30 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching a single component It looks like that would work for patching using .pcp files, since when you do the required administrative install, you have control over which files are actually present. I was hoping for a solution in which I could still use the .wixpdb files to generate a .wixmst. -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Wednesday, March 10, 2010 3:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching a single component I'm not sure where this is specified in WiX patching, but the PCP file has a TargetImages table with an IgnoreMissingSrcFiles option that sounds like what you want: http://msdn.microsoft.com/en-us/library/aa372066(VS.85).aspx Phil Wilson -Original Message- From: Andy Glass [mailto:agl...@laserfiche.com] Sent: Wednesday, March 10, 2010 1:46 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Patching a single component As part of my first foray into the world of patching, I have been tasked with creating hotfix patches for our product. As part of the daily build, the version numbers for all files in the product are incremented, but I only want to patch the specific files that were fixed as part of the hotfix. After reading through the tutorial, various blogs, and the mailing list archives, I got the implication that adding a ComponentRef as a child of my PatchFamily would do what I want, so I went ahead and created a patch for Component A. After installing the patch, not only was the file in Component A updated to the new version, so were all other files that had changed between the builds. Is there some way to create a patch that only includes a single file, despite the two .wixpdb files used to create it having many other differences, or would I need to generate the patch using a .wixpdb file that only contained the change for the file I wish to patch? -Andy -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively
[WiX-users] Patching a single component
As part of my first foray into the world of patching, I have been tasked with creating hotfix patches for our product. As part of the daily build, the version numbers for all files in the product are incremented, but I only want to patch the specific files that were fixed as part of the hotfix. After reading through the tutorial, various blogs, and the mailing list archives, I got the implication that adding a ComponentRef as a child of my PatchFamily would do what I want, so I went ahead and created a patch for Component A. After installing the patch, not only was the file in Component A updated to the new version, so were all other files that had changed between the builds. Is there some way to create a patch that only includes a single file, despite the two .wixpdb files used to create it having many other differences, or would I need to generate the patch using a .wixpdb file that only contained the change for the file I wish to patch? -Andy -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching a single component
I'm not sure where this is specified in WiX patching, but the PCP file has a TargetImages table with an IgnoreMissingSrcFiles option that sounds like what you want: http://msdn.microsoft.com/en-us/library/aa372066(VS.85).aspx Phil Wilson -Original Message- From: Andy Glass [mailto:agl...@laserfiche.com] Sent: Wednesday, March 10, 2010 1:46 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Patching a single component As part of my first foray into the world of patching, I have been tasked with creating hotfix patches for our product. As part of the daily build, the version numbers for all files in the product are incremented, but I only want to patch the specific files that were fixed as part of the hotfix. After reading through the tutorial, various blogs, and the mailing list archives, I got the implication that adding a ComponentRef as a child of my PatchFamily would do what I want, so I went ahead and created a patch for Component A. After installing the patch, not only was the file in Component A updated to the new version, so were all other files that had changed between the builds. Is there some way to create a patch that only includes a single file, despite the two .wixpdb files used to create it having many other differences, or would I need to generate the patch using a .wixpdb file that only contained the change for the file I wish to patch? -Andy -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching a single component
It looks like that would work for patching using .pcp files, since when you do the required administrative install, you have control over which files are actually present. I was hoping for a solution in which I could still use the .wixpdb files to generate a .wixmst. -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Wednesday, March 10, 2010 3:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching a single component I'm not sure where this is specified in WiX patching, but the PCP file has a TargetImages table with an IgnoreMissingSrcFiles option that sounds like what you want: http://msdn.microsoft.com/en-us/library/aa372066(VS.85).aspx Phil Wilson -Original Message- From: Andy Glass [mailto:agl...@laserfiche.com] Sent: Wednesday, March 10, 2010 1:46 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Patching a single component As part of my first foray into the world of patching, I have been tasked with creating hotfix patches for our product. As part of the daily build, the version numbers for all files in the product are incremented, but I only want to patch the specific files that were fixed as part of the hotfix. After reading through the tutorial, various blogs, and the mailing list archives, I got the implication that adding a ComponentRef as a child of my PatchFamily would do what I want, so I went ahead and created a patch for Component A. After installing the patch, not only was the file in Component A updated to the new version, so were all other files that had changed between the builds. Is there some way to create a patch that only includes a single file, despite the two .wixpdb files used to create it having many other differences, or would I need to generate the patch using a .wixpdb file that only contained the change for the file I wish to patch? -Andy -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching custom actions
At which point in the patching process are custom actions that are executing the updated ones? I have custom actions that execute before and after PatchFiles action. Custom action executing before PatchFiles finds MSI DB already transformed. Based on that I would expect that table containing custom action dll binaries is also already updated and that custom action that is currently executing is the updated one. Since testing it is a bit too laborious in my case, I hope some expert can answer this question. Thanks in advance. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching custom actions
In article 89030b4a18eccd45978a3a6b639d1f24030ac82...@fl01exmb01.trad.tradestation.com, Tony Juricic tjuri...@tradestation.com writes: At which point in the patching process are custom actions that are executing the updated ones? If they are custom actions that execute out of installed files, the updated actions are not available until after the filed are patched. If they are custom actions that execute out of the Binary table, they are available as soon as the patch transform is applied. This happens before any of the sequences execute. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching problems with alternate directories
Hey Tom, I wanted to thank you for all of your help. I actually was able to figure out the problem and get it fixed. As it turns out it was being caused by a RegistryKey entry for non advertised shortcuts. When I removed the registry key entry and set the shortcuts as advertised everything worked perfectly for repairs, uninstalls, patches, and presumably for future upgrades. The solution surprised me as it doesn't seem to be related. I was wondering if you might know what goes on behind the scenes of the mysterious Windows Installer that could explain why the shortcuts turned out to be causing my problem. Thanks in advance! Big Jim. Thomas Svare wrote: Hello, Sorry about that just meant any install operation after the initial install. It sounds like WIX_INSTALLDIR is not being updated to the user select install directory during patches/repair/uninstall. If the install directory is being saved in the registry or .ini file you can use the RegistrySearch or IniFileSearch element to set a property. Then you could use that property to set WIX_INSTALLDIR based on whether or not your product is installed. There's also a ComponentSearch element that may be helpful as well. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Monday, December 14, 2009 11:59 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Sorry, I'm not familiar with the term maintenance mode and all that it encompasses. I can tell you that the WIX_INSTALLDIR is being defined in the actual code. When running the installer it has a default location which is preset and shows up in the dialog. When the user changes it they do it while running the installer by modifying the text which should reset the WIX_INSTALLDIR property during the installation. If this could be defined as being set/defined in maintenance mode, than yes it is for user-chosen directories. Thomas Svare wrote: Hello, Is WIXUI_INSTALLDIR being set/defined in maintenance mode? Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Monday, December 14, 2009 10:28 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Tom, I have the option for users to choose the installation directory from a custom InstallDirDlg.wxs file, basically just copied with a different name, call it MyInstallDirDlg.wxs. The user can either click a button and browse or type the location manually into an edit field. The value gets set to a property defined in my main installer .wxs file as WIXUI_INSTALLDIR. Then in a custom MyWixUI_InstallDir.wxs, I have it publish the SetTargetPath event to value [WIXUI_INSTALLDIR]. By default the directory structure is put in as follows: Directory Id=ProgramFilesFolder Directory Id='ProductFolder' Name='Product' Directory Id=PRODUCTVERSIONFOLDER Name=Version RegistryKey Root=HKCU Key=Software\IWARS\ResearchAndDevelopment\Uninstall RegistryValue Value=0 Type=string KeyPath=yes / /RegistryKey ... components below ... /Directory /Directory /Directory Thomas Svare wrote: Hello, How does the directory for the binaries and docs get set when the user chooses a non-default install directory? It sounds like this isn't happening in any maintenance operations. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Friday, December 11, 2009 8:07 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Tom, I managed to get a verbose log of a good and bad uninstall (seemed the easiest place to start.) INSTALLDIR was set properly in both logs. The issue with the uninstall prevents itself with only the data files used by our application being removed. This holds true for the other issues as well, the data files don't seem to be causing a problem. The binary files and documentation for our product remain behind. In both logs their directory data is also the same, which naturally means it works fine when installed to the default directory. There isn't really any key difference between the binary files being installed and the data files. One difference being that all the binary files are being installed under a single component (which I know is a rule violation but the ruling to do it this way is happening above me). I also don't see how it could be contributing to this particular problem. Thomas Svare wrote: Hello, Try looking at the property dump section of a verbose log and compare the directory table entry values between a good default install and a bad patch/repair/uninstall. INSTALLDIR is has been an issue for me in the past. Thanks, Tom -Original Message- From
Re: [WiX-users] Patching problems with alternate directories
That's an interesting idea, I assumed that the windows installer more or less kept track of an original install for repairs, uninstalls, patches, and upgrades which may have been the error in my approach. My installer does not contain a registry key for an installation path. Although I can easily add a registry key to do this I'm not sure how I would make use of it for uninstalls, repairs, and patches though, chiefly how to make them look for that registry key and update their working directory based on it. Do you have any idea how this might be done or perhaps a link to some online resources. I've been searching google to see about how to do this and haven't had much luck so far. Thomas Svare wrote: Hello, Sorry about that just meant any install operation after the initial install. It sounds like WIX_INSTALLDIR is not being updated to the user select install directory during patches/repair/uninstall. If the install directory is being saved in the registry or .ini file you can use the RegistrySearch or IniFileSearch element to set a property. Then you could use that property to set WIX_INSTALLDIR based on whether or not your product is installed. There's also a ComponentSearch element that may be helpful as well. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Monday, December 14, 2009 11:59 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Sorry, I'm not familiar with the term maintenance mode and all that it encompasses. I can tell you that the WIX_INSTALLDIR is being defined in the actual code. When running the installer it has a default location which is preset and shows up in the dialog. When the user changes it they do it while running the installer by modifying the text which should reset the WIX_INSTALLDIR property during the installation. If this could be defined as being set/defined in maintenance mode, than yes it is for user-chosen directories. Thomas Svare wrote: Hello, Is WIXUI_INSTALLDIR being set/defined in maintenance mode? Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Monday, December 14, 2009 10:28 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Tom, I have the option for users to choose the installation directory from a custom InstallDirDlg.wxs file, basically just copied with a different name, call it MyInstallDirDlg.wxs. The user can either click a button and browse or type the location manually into an edit field. The value gets set to a property defined in my main installer .wxs file as WIXUI_INSTALLDIR. Then in a custom MyWixUI_InstallDir.wxs, I have it publish the SetTargetPath event to value [WIXUI_INSTALLDIR]. By default the directory structure is put in as follows: Directory Id=ProgramFilesFolder Directory Id='ProductFolder' Name='Product' Directory Id=PRODUCTVERSIONFOLDER Name=Version RegistryKey Root=HKCU Key=Software\IWARS\ResearchAndDevelopment\Uninstall RegistryValue Value=0 Type=string KeyPath=yes / /RegistryKey ... components below ... /Directory /Directory /Directory Thomas Svare wrote: Hello, How does the directory for the binaries and docs get set when the user chooses a non-default install directory? It sounds like this isn't happening in any maintenance operations. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Friday, December 11, 2009 8:07 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Tom, I managed to get a verbose log of a good and bad uninstall (seemed the easiest place to start.) INSTALLDIR was set properly in both logs. The issue with the uninstall prevents itself with only the data files used by our application being removed. This holds true for the other issues as well, the data files don't seem to be causing a problem. The binary files and documentation for our product remain behind. In both logs their directory data is also the same, which naturally means it works fine when installed to the default directory. There isn't really any key difference between the binary files being installed and the data files. One difference being that all the binary files are being installed under a single component (which I know is a rule violation but the ruling to do it this way is happening above me). I also don't see how it could be contributing to this particular problem. Thomas Svare wrote: Hello, Try looking at the property dump section of a verbose log and compare the directory table entry values between a good default install and a bad patch/repair/uninstall. INSTALLDIR is has been an issue for me in the past. Thanks
Re: [WiX-users] Patching problems with alternate directories
Hey Tom, I have the option for users to choose the installation directory from a custom InstallDirDlg.wxs file, basically just copied with a different name, call it MyInstallDirDlg.wxs. The user can either click a button and browse or type the location manually into an edit field. The value gets set to a property defined in my main installer .wxs file as WIXUI_INSTALLDIR. Then in a custom MyWixUI_InstallDir.wxs, I have it publish the SetTargetPath event to value [WIXUI_INSTALLDIR]. By default the directory structure is put in as follows: Directory Id=ProgramFilesFolder Directory Id='ProductFolder' Name='Product' Directory Id=PRODUCTVERSIONFOLDER Name=Version RegistryKey Root=HKCU Key=Software\IWARS\ResearchAndDevelopment\Uninstall RegistryValue Value=0 Type=string KeyPath=yes / /RegistryKey ... components below ... /Directory /Directory /Directory Thomas Svare wrote: Hello, How does the directory for the binaries and docs get set when the user chooses a non-default install directory? It sounds like this isn't happening in any maintenance operations. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Friday, December 11, 2009 8:07 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Tom, I managed to get a verbose log of a good and bad uninstall (seemed the easiest place to start.) INSTALLDIR was set properly in both logs. The issue with the uninstall prevents itself with only the data files used by our application being removed. This holds true for the other issues as well, the data files don't seem to be causing a problem. The binary files and documentation for our product remain behind. In both logs their directory data is also the same, which naturally means it works fine when installed to the default directory. There isn't really any key difference between the binary files being installed and the data files. One difference being that all the binary files are being installed under a single component (which I know is a rule violation but the ruling to do it this way is happening above me). I also don't see how it could be contributing to this particular problem. Thomas Svare wrote: Hello, Try looking at the property dump section of a verbose log and compare the directory table entry values between a good default install and a bad patch/repair/uninstall. INSTALLDIR is has been an issue for me in the past. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 3:50 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Thanks for the tip Tom, I'm looking into at least one discrepency that I saw come up after the Orca/patch transform. I'm not sure if it's causing this error or not but chances are it would have caused problems down the road. The second issue you mentioned I was curious about as well. Do you know of anything that could cause a property to be set by the UI and not by repair and uninstall? I could see this happening with registry key entries which shouldn't be the case in my installer, but could you help me to understand what to look for with troublesome UI properties as well? Thomas Svare wrote: Hello, You just open the msi with Orca then choose Transform-View Patch and navigate to the msp and select OK and you'll see the changes in Orca. Since repairs and uninstalls are showing the problem it sounds like some property is getting set by the UI that isn't being re-set during patch/repair/uninstall. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 12:59 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories I definitely reviewed the tables for both my installer msi as well as my patch msp while trying to figure out this problem. I've never heard of applying a patch using orca before though, I took at look but didn't see an obvious way of doing this. Could you let me know how to use orca to apply the patch? Also the issue extends beyond patching to include repairs and uninstalls so I think the problem runs deeper than just how the patch is applied. Thomas Svare wrote: Hello, You may have already tried this but sometimes opening the msi and applying the patch with Orca can point out things that are buried in a verbose log like removing a component from a feature during a patch etc. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 12:00 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories All of the components
Re: [WiX-users] Patching problems with alternate directories
Hello, Is WIXUI_INSTALLDIR being set/defined in maintenance mode? Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Monday, December 14, 2009 10:28 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Tom, I have the option for users to choose the installation directory from a custom InstallDirDlg.wxs file, basically just copied with a different name, call it MyInstallDirDlg.wxs. The user can either click a button and browse or type the location manually into an edit field. The value gets set to a property defined in my main installer .wxs file as WIXUI_INSTALLDIR. Then in a custom MyWixUI_InstallDir.wxs, I have it publish the SetTargetPath event to value [WIXUI_INSTALLDIR]. By default the directory structure is put in as follows: Directory Id=ProgramFilesFolder Directory Id='ProductFolder' Name='Product' Directory Id=PRODUCTVERSIONFOLDER Name=Version RegistryKey Root=HKCU Key=Software\IWARS\ResearchAndDevelopment\Uninstall RegistryValue Value=0 Type=string KeyPath=yes / /RegistryKey ... components below ... /Directory /Directory /Directory Thomas Svare wrote: Hello, How does the directory for the binaries and docs get set when the user chooses a non-default install directory? It sounds like this isn't happening in any maintenance operations. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Friday, December 11, 2009 8:07 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Tom, I managed to get a verbose log of a good and bad uninstall (seemed the easiest place to start.) INSTALLDIR was set properly in both logs. The issue with the uninstall prevents itself with only the data files used by our application being removed. This holds true for the other issues as well, the data files don't seem to be causing a problem. The binary files and documentation for our product remain behind. In both logs their directory data is also the same, which naturally means it works fine when installed to the default directory. There isn't really any key difference between the binary files being installed and the data files. One difference being that all the binary files are being installed under a single component (which I know is a rule violation but the ruling to do it this way is happening above me). I also don't see how it could be contributing to this particular problem. Thomas Svare wrote: Hello, Try looking at the property dump section of a verbose log and compare the directory table entry values between a good default install and a bad patch/repair/uninstall. INSTALLDIR is has been an issue for me in the past. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 3:50 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Thanks for the tip Tom, I'm looking into at least one discrepency that I saw come up after the Orca/patch transform. I'm not sure if it's causing this error or not but chances are it would have caused problems down the road. The second issue you mentioned I was curious about as well. Do you know of anything that could cause a property to be set by the UI and not by repair and uninstall? I could see this happening with registry key entries which shouldn't be the case in my installer, but could you help me to understand what to look for with troublesome UI properties as well? Thomas Svare wrote: Hello, You just open the msi with Orca then choose Transform-View Patch and navigate to the msp and select OK and you'll see the changes in Orca. Since repairs and uninstalls are showing the problem it sounds like some property is getting set by the UI that isn't being re-set during patch/repair/uninstall. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 12:59 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories I definitely reviewed the tables for both my installer msi as well as my patch msp while trying to figure out this problem. I've never heard of applying a patch using orca before though, I took at look but didn't see an obvious way of doing this. Could you let me know how to use orca to apply the patch? Also the issue extends beyond patching to include repairs and uninstalls so I think the problem runs deeper than just how the patch is applied. Thomas Svare wrote: Hello, You may have already tried this but sometimes opening the msi and applying the patch with Orca can point out things that are buried in a verbose log like removing a component from
Re: [WiX-users] Patching problems with alternate directories
Sorry, I'm not familiar with the term maintenance mode and all that it encompasses. I can tell you that the WIX_INSTALLDIR is being defined in the actual code. When running the installer it has a default location which is preset and shows up in the dialog. When the user changes it they do it while running the installer by modifying the text which should reset the WIX_INSTALLDIR property during the installation. If this could be defined as being set/defined in maintenance mode, than yes it is for user-chosen directories. Thomas Svare wrote: Hello, Is WIXUI_INSTALLDIR being set/defined in maintenance mode? Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Monday, December 14, 2009 10:28 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Tom, I have the option for users to choose the installation directory from a custom InstallDirDlg.wxs file, basically just copied with a different name, call it MyInstallDirDlg.wxs. The user can either click a button and browse or type the location manually into an edit field. The value gets set to a property defined in my main installer .wxs file as WIXUI_INSTALLDIR. Then in a custom MyWixUI_InstallDir.wxs, I have it publish the SetTargetPath event to value [WIXUI_INSTALLDIR]. By default the directory structure is put in as follows: Directory Id=ProgramFilesFolder Directory Id='ProductFolder' Name='Product' Directory Id=PRODUCTVERSIONFOLDER Name=Version RegistryKey Root=HKCU Key=Software\IWARS\ResearchAndDevelopment\Uninstall RegistryValue Value=0 Type=string KeyPath=yes / /RegistryKey ... components below ... /Directory /Directory /Directory Thomas Svare wrote: Hello, How does the directory for the binaries and docs get set when the user chooses a non-default install directory? It sounds like this isn't happening in any maintenance operations. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Friday, December 11, 2009 8:07 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Tom, I managed to get a verbose log of a good and bad uninstall (seemed the easiest place to start.) INSTALLDIR was set properly in both logs. The issue with the uninstall prevents itself with only the data files used by our application being removed. This holds true for the other issues as well, the data files don't seem to be causing a problem. The binary files and documentation for our product remain behind. In both logs their directory data is also the same, which naturally means it works fine when installed to the default directory. There isn't really any key difference between the binary files being installed and the data files. One difference being that all the binary files are being installed under a single component (which I know is a rule violation but the ruling to do it this way is happening above me). I also don't see how it could be contributing to this particular problem. Thomas Svare wrote: Hello, Try looking at the property dump section of a verbose log and compare the directory table entry values between a good default install and a bad patch/repair/uninstall. INSTALLDIR is has been an issue for me in the past. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 3:50 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Thanks for the tip Tom, I'm looking into at least one discrepency that I saw come up after the Orca/patch transform. I'm not sure if it's causing this error or not but chances are it would have caused problems down the road. The second issue you mentioned I was curious about as well. Do you know of anything that could cause a property to be set by the UI and not by repair and uninstall? I could see this happening with registry key entries which shouldn't be the case in my installer, but could you help me to understand what to look for with troublesome UI properties as well? Thomas Svare wrote: Hello, You just open the msi with Orca then choose Transform-View Patch and navigate to the msp and select OK and you'll see the changes in Orca. Since repairs and uninstalls are showing the problem it sounds like some property is getting set by the UI that isn't being re-set during patch/repair/uninstall. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 12:59 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories I definitely reviewed the tables for both my installer msi as well as my patch msp
Re: [WiX-users] Patching problems with alternate directories
Hello, Sorry about that just meant any install operation after the initial install. It sounds like WIX_INSTALLDIR is not being updated to the user select install directory during patches/repair/uninstall. If the install directory is being saved in the registry or .ini file you can use the RegistrySearch or IniFileSearch element to set a property. Then you could use that property to set WIX_INSTALLDIR based on whether or not your product is installed. There's also a ComponentSearch element that may be helpful as well. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Monday, December 14, 2009 11:59 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Sorry, I'm not familiar with the term maintenance mode and all that it encompasses. I can tell you that the WIX_INSTALLDIR is being defined in the actual code. When running the installer it has a default location which is preset and shows up in the dialog. When the user changes it they do it while running the installer by modifying the text which should reset the WIX_INSTALLDIR property during the installation. If this could be defined as being set/defined in maintenance mode, than yes it is for user-chosen directories. Thomas Svare wrote: Hello, Is WIXUI_INSTALLDIR being set/defined in maintenance mode? Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Monday, December 14, 2009 10:28 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Tom, I have the option for users to choose the installation directory from a custom InstallDirDlg.wxs file, basically just copied with a different name, call it MyInstallDirDlg.wxs. The user can either click a button and browse or type the location manually into an edit field. The value gets set to a property defined in my main installer .wxs file as WIXUI_INSTALLDIR. Then in a custom MyWixUI_InstallDir.wxs, I have it publish the SetTargetPath event to value [WIXUI_INSTALLDIR]. By default the directory structure is put in as follows: Directory Id=ProgramFilesFolder Directory Id='ProductFolder' Name='Product' Directory Id=PRODUCTVERSIONFOLDER Name=Version RegistryKey Root=HKCU Key=Software\IWARS\ResearchAndDevelopment\Uninstall RegistryValue Value=0 Type=string KeyPath=yes / /RegistryKey ... components below ... /Directory /Directory /Directory Thomas Svare wrote: Hello, How does the directory for the binaries and docs get set when the user chooses a non-default install directory? It sounds like this isn't happening in any maintenance operations. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Friday, December 11, 2009 8:07 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Tom, I managed to get a verbose log of a good and bad uninstall (seemed the easiest place to start.) INSTALLDIR was set properly in both logs. The issue with the uninstall prevents itself with only the data files used by our application being removed. This holds true for the other issues as well, the data files don't seem to be causing a problem. The binary files and documentation for our product remain behind. In both logs their directory data is also the same, which naturally means it works fine when installed to the default directory. There isn't really any key difference between the binary files being installed and the data files. One difference being that all the binary files are being installed under a single component (which I know is a rule violation but the ruling to do it this way is happening above me). I also don't see how it could be contributing to this particular problem. Thomas Svare wrote: Hello, Try looking at the property dump section of a verbose log and compare the directory table entry values between a good default install and a bad patch/repair/uninstall. INSTALLDIR is has been an issue for me in the past. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 3:50 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Thanks for the tip Tom, I'm looking into at least one discrepency that I saw come up after the Orca/patch transform. I'm not sure if it's causing this error or not but chances are it would have caused problems down the road. The second issue you mentioned I was curious about as well. Do you know of anything that could cause a property to be set by the UI and not by repair and uninstall? I could see this happening with registry key entries which shouldn't be the case in my installer, but could you
