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
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 Pr
nuing
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] Pat
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
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 | E
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 wi
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/
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.
--
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-t
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
m: 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
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
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 pat
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
di
ailto: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 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
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
acc
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 pa
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).
Som
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
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
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 Wilso
uesday, 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
, 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
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
There are ways but Major Version Patches are officially discouraged (see MSDN).
> Date: Sun, 23 Jun 2013 21:41:45 -0700
> From: nickra...@hotmail.com
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching multiple versions
>
> Actually, trying my idea didn
Actually, trying my idea didn't work for me. It may not be possible to have a
single patch file that updates multiple versions. However, you may be able
to create a patch for each version that you want to update. For each one,
keep the PatchFamily's Id the same (that way they'll maintain their corr
I haven't tried it, but could you add a PatchFamily for each version that you
want patch? Each PatchFamily would have a Version to identify the product
version to update. You would not use the PatchFamily's ProductCode attribute
at all. Instead, the parent Patch element's TargetProductName would ma
Thanks for the explanation.
-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: Monday, June 17, 2013 1:52 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching error
George,
On initial installations Windows Installer seems to
ously 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
>
&g
; -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
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
p/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.
Sub
rom: 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 th
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
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] Pat
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-
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
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 eac
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
RemoveExistingProd
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 Componen
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?
--
V
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://bo
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"];
fea
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
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)
cliffe [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
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-us
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 p
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
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
wrote:
> Hi:
> I'm currently writing a bundle using burn. Later on we will need to
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: Aru
olset.
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
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 Flanaga
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 tr
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 Dep
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
ead a really good thread that deserves
attention? E-Mail Me
- Original Message
From: Peter Shirtcliffe
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
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
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-tp5234
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,
Does this thread help:
http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg27915.htm
l
?
-- Yan
-Original Message-
From: d8x...@hotmail.com [mailto:d8x...@hotmail.com]
Sent: Tuesday, 08 June, 2010 21:49
To: Wix-Users
Subject: [WiX-users] Patching multiple instances of product
or Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching Base Versions
Here is one example where you can try insert additional targets (bases)
http://schemas.microsoft.com/wix/2006/wi";>
http://www.myco.com";
Classificatio
Here is one example where you can try insert additional targets (bases)
http://schemas.microsoft.com/wix/2006/wi";>
http://www.myco.com";
Classification="$(var.CLASSIFICATION)"
AllowRemoval="yes"
OptimizedInstallMode="yes"
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
erate 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 W
-
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
TargetI
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:a
In article
<89030b4a18eccd45978a3a6b639d1f24030ac82...@fl01exmb01.trad.tradestation.com>,
Tony Juricic 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 act
t; 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: [W
d 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
orPtr [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
; 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] Patchi
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
; 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 ge
er 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 wit
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 directorie
...@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 n
me
> 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.sou
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 al
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 table
M
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching problems with alternate directories
>
>
> All of the components are listed as:
>
> Installed: Local; Request: Local; Action: Local.
>
>
> Blair-2 wrote:
>>
>> What does
...@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 are listed as:
Installed: Local; Request: Local; Action: Local.
Blair-2 wrote:
>
> What does the log say abo
6:27 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching problems with alternate directories
>
>
> Hey Blair-2, I'd be happy to share a log of the installation but
> unfortunately I'm doing this for a company and I'm not allowed to post the
>
What does the log say about the component statuses?
-Original Message-
From: XorPtr [mailto:reaper4...@gmail.com]
Sent: Thursday, December 10, 2009 6:27 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching problems with alternate directories
Hey Blair-2, I'
; Could you share a log that shows it not working in that circumstance?
>
> -Original Message-
> From: XorPtr [mailto:reaper4...@gmail.com]
> Sent: Wednesday, December 09, 2009 1:55 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching proble
Subject: Re: [WiX-users] Patching problems with alternate directories
When you refer to the "currently installed location", are you referring to
the location that my product installs to by default or the location selected
by the user. If the latter, then the patch should be installi
When you refer to the "currently installed location", are you referring to
the location that my product installs to by default or the location selected
by the user. If the latter, then the patch should be installing to that
location.
Blair-2 wrote:
>
> Are your patches MSP files performing eit
My MSP files are performing small hotfix updates to correct a couple of bugs.
Thanks for informing me about that restriction. Is there a workaround you
can think of because I'm pretty much stumped on this one.
Blair-2 wrote:
>
> Are your patches MSP files performing either small updates or mi
Are your patches MSP files performing either small updates or minor
upgrades? If so, the patch application won't let you patch anywhere other
than the currently installed location since the keypath of the components
can't be changed without a major upgrade.
-Original Message-
From: XorPtr
Thanks for the explanation, Blair!
-- Yan
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Tuesday, November 24, 2009 07:59
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Patching: weird numbers forMedia.DiskId
andFile.Sequ
net]
Sent: Monday, November 23, 2009 1:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patching: weird numbers for Media.DiskId
andFile.Sequence
Any ideas? Anyone?
-- Yan
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Friday
Any ideas? Anyone?
-- Yan
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Friday, November 20, 2009 11:59
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Patching: weird numbers for Media.DiskId
andFile.Sequence
Hello WiX Community,
I have been analyzi
:57 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching after disabling "Repair"
OK. In that case using a custom action that sets the ARPNOREPAIR value to
"0"
before the would do the trick??
Blair-2 wrote:
>
> The thought that followed right after
d) condition will be
> evaluated AFTER you transform it.
>
> -Original Message-
> From: Blair [mailto:os...@live.com]
> Sent: Wednesday, October 21, 2009 12:10 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: RE: [WiX-users] Patchin
2:10 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Patching after disabling "Repair"
If you can bootstrap your patch, you might be able to set REINSTALL to the
list of installed features instead of "ALL". Otherwise you may be force
If you can bootstrap your patch, you might be able to set REINSTALL to the
list of installed features instead of "ALL". Otherwise you may be forced to
use a Major Upgrade.
-Original Message-
From: Andy2k8 [mailto:appr...@gmail.com]
Sent: Tuesday, October 20, 2009 11:50 PM
To: wix-users@li
rom: wix-users-boun...@lists.sourceforge.net
> [mailto:wix-users-boun...@lists.sourceforge.net] On Behalf Of Vitaly
> Dolya
> Sent: Sunday, June 18, 2006 7:46 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching Problem
>
>
>
> Brower, Jason wrot
hursday, July 30, 2009 12:25 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Patching & MergeModules
I call torch like this:
torch.exe -p -xi Baseline\App.wixpdb Hotfix\App.wixpdb -out Diff.wixmst
then I candlelight the Hotfix.wxs:
candle.exe Hotfix.wxs -out Hotfix.wixobj
light.exe
I call torch like this:
torch.exe -p -xi Baseline\App.wixpdb Hotfix\App.wixpdb -out Diff.wixmst
then I candlelight the Hotfix.wxs:
candle.exe Hotfix.wxs -out Hotfix.wixobj
light.exe Hotfix.wixobj -out Hotfix.wixmsp
then I execute pyro:
pyro.exe Hotfix.wixmsp -out Hotfix01.msp -t RTM Diff.wixmst
1 - 100 of 167 matches
Mail list logo
