Blair, Mike, thanks.
Mike, I can easily take that approach, it was more of a question out of
curiosity. FWIW, I had two instances of the element specified with different
attributes, WiX 3.0 did not error. I'll dig into the MSI with Orca and see
what it is doing.
Thanks again.
On Wed, Oct 6, 2010
Andy,
If you have a RemoveExistingProducts action scheduled in one location in
your common element and another scheduled elsewhere in your Product
consuming the common WiX I'm pretty sure you would get a compilation error.
You could set something up in your common WiX fragments/include to
condit
[WiX-users] Best Practices - Using "*" for GUID automation
Mike,
Thanks again for the reply.
I have added and it
works as you stated. Actually, WiX disallows both "After" and "Before" in
the same element.
I understand the rollback scenario now as well. Thanks fo
Mike,
Thanks again for the reply.
I have added and it
works as you stated. Actually, WiX disallows both "After" and "Before" in
the same element.
I understand the rollback scenario now as well. Thanks for the
clarification.
Going forward... since we have an infrastructure in place, we have "co
Hi Andy,
Either setting After="InstallValidate" or Before="InstallInitialize" will
work, you don't need to specify both. I was just giving you the
restrictions on sequencing for the upgrade to work.
With this setup a rollback to v1.0.0 would not occur if your v1.0.1 MSI
fails after RemoveExisti
Hi Mike,
Thanks for the info. What you stated is what I am seeing in the verbose
logs. I see where the files are being copied, and then I see where they are
being removed. Doing a diff between the "good" v1.0.0 case and the "bad"
v1.0.0 case makes it obvious.
So if I understand you on the sequenc
This is the expected behavior for that configuration. The problem is that
since your component GUIDs don't line up from v1.0.0 to v1.0.1 the upgrade
installs the new components and then after InstallFinalize removes the old
components because it is not able to properly reference count them using
ents (at least as far as the closest "well-known" directory), for
>> > those
>> > > components who's keypaths are files.
>> > >
>> > > Have you shipped your product before using guids that were not "*"?
>> > >
>> >
ectories
> > > parents (at least as far as the closest "well-known" directory), for
> > those
> > > components who's keypaths are files.
> > >
> > > Have you shipped your product before using guids that were not "*"?
> > >
>
that were not "*"?
> >
> > -----Original Message-
> > From: James Poole [mailto:w...@slowcommotion.com]
> > Sent: Tuesday, June 29, 2010 11:06 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Best Practices
ory), for those
> components who's keypaths are files.
>
> Have you shipped your product before using guids that were not "*"?
>
> -Original Message-
> From: James Poole [mailto:w...@slowcommotion.com]
> Sent: Tuesday, June 29, 2010 11:06 AM
> To:
10 11:06 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Best Practices - Using "*" for GUID automation
Could someone chime in with a time when you wouldn't want to use "*" on
component Guids? Would this cause issues with generating
Could someone chime in with a time when you wouldn't want to use "*" on
component Guids? Would this cause issues with generating patches?
-James
On Tue, Jun 29, 2010 at 1:19 PM, Andy Clugston wrote:
> Okay, it seemed like this approach would work, just wanted to verify.
> Thanks!
>
> On Tue, J
Okay, it seemed like this approach would work, just wanted to verify.
Thanks!
On Tue, Jun 29, 2010 at 10:10 AM, Cherney John-CJC030 <
john.cher...@motorola.com> wrote:
> I haven't had any problems with component ids set to "*". We keep the
> Upgrade id constant but vary everything else, including
I haven't had any problems with component ids set to "*". We keep the
Upgrade id constant but vary everything else, including the version and
the MSI name (which contains the version). Because of the changing
version and the constant upgrade id (and the PREVIOUSFOUND property
getting set in the Upg
15 matches
Mail list logo