Did you set conditions on the MsiPackage? Do the differences in version between
the two MSIs show up in the first three numbers?
> Date: Fri, 15 Nov 2013 02:58:32 -0800
> From: ulr...@holeschak.de
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] MSI packages in different burn bundles
Wouldn't have to be a major update, it could be a minor update as well.
I assume when you say "user to remove" you mean burn scheduling the removal of
it. I wouldn't' consider it a good user experience to force the user to
physically remove the previous application.
That seems different than
RTM+1 you mean next major release of my product?
this will required the user to remove previous major release (RTM+and all
HFs)
RTM+1 include all fixes of all HF inside the RTM+1 msi.
I guess I can build HF2 where the target are RTM and H1(which build for RTM)
isnt this enable me to apply HF2
I don't have a need to provide a hotfix that isn't in the next normal release.
So my v1.1 hotfix is in reality a v1.1 install. It has all the same things as
v1.0, with the addition of the MspPackage to the existing MsiPackage's Package
group. The download should be minimal as the engine will j
I forgot to say that my HFs should be removable so i guess slipstream not
relevent
(i assume i will not get update entry in ARP for each msp in the bundle only
for the bundle itself)
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Why-do-i-need-t
Thanks ,
About slipstreami need to provide HF2 to customer who dont need or want
HF1
But assuming HF2 contain HF1 ,using slipstreamhow can i prevent same
bundle installed again?
Can i just use WixBundleInstalled?
btw where is the documentation for RelatedBundle??
"the update v1.1 is t
I haven't done this myself so I was just thinking out loud to try to give you
ideas and an alternative perspective.
If it's a hotfix only bundle, then to me it feels like a different payload.
Also looking at the documentation and seeing the RelatedBundle/@Action='Patch'
to me seems like that i
A few comments off the top of my head:
Last time I looked, the SQL Server install was already a bundle of separate
MSI files, and I can't tell if you are integrating that into your own
install, but that could be tricky. SQL lets you create an ini file that you
pass to the install, so that may be us
Thanks
Yes purely hotfix...only msp
Ok... sharing same upgrade code in both HF and different upgrade code in
RTM. this we didnot try yet :)
Also you say
"it back to RTM. To me it makes the most sense to have HF1 and HF2 both
share a unique upgrade code that is different than the RTM upgrade
I'd start by asking what your HF1 and HF2 bundles look like. Are they purely
hotfix bundles, or are they meant to replace the original bundle?
To me it wouldn't make sense for the RTM bundle to have to know what the future
hotfix bundles look like, so I would expect the HF1 bundle to have a
Re
Hi
I am trying to support 'sequencing' of a bundle such that the user will not
be able to install HF1 on top of HF2
When I use same UpgradeCode for all the bundles and remove 'main' bundle it
does not remove other bundles
When I use different UpgdraeCode then when installing HF1 on top of HF2 I
do
11 matches
Mail list logo