Leaving the version number unchanged at 0.0.0.0 forces you into the "small
update" category which requires you to specify a command line to run the update.
Changing the ProductCode means you are in the "major upgrade" category and that
won't require the special command line. However, if you use this method, you
also must change the ProductVersion, too. Leaving it at 0.0.0.0 won't work.
The way I did this was to have the ProductVersion passed in (it is basically
the build system's build number) and use the wildcard to automatically generate
the ProductCode each build. That way, both values change each time as is needed
for major upgrade.
Here are some relevant snippets:
<?ifndef Version?>
<?define Version=$(var.PRODUCT_VERSION)?>
<?endif ?>
<Product Id="*"
Name="Product Name"
Language="1033"
Version="$(var.Version)"
Manufacturer="Company Name"
UpgradeCode="{33B6AF43-5F2F-4e69-B9A1-FEF3FA1F13C4}">
<!-- _________________________ Upgrades
___________________________________________ -->
<Upgrade Id="{33B6AF43-5F2F-4e69-B9A1-FEF3FA1F13C4}">
<UpgradeVersion Property="OLDAPPFOUND" Minimum="0.0.0.0"
Maximum="$(var.Version)" IncludeMinimum="yes" IncludeMaximum="no" />
<UpgradeVersion Property="NEWAPPFOUND" Minimum="$(var.Version)"
IncludeMinimum="no" OnlyDetect="yes" />
</Upgrade>
I see your company is located in Glasgow. My great grandfather was from
Glasgow. Parents are from N. Ireland.
-----Original Message-----
From: Adam Connelly [mailto:[EMAIL PROTECTED]
Sent: Friday, October 10, 2008 3:54 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How Update / Upgrade strategy (small, minor, major)
affect file overriding?
Thanks for the advice. I didn't actually mean to say commercial, I was more
meaning that I've downloaded msi's from various sources - some commercial, some
open source, ... and the vast majority of them haven't required me to either
use msiexec or uninstall the previous version.
I'm just trying to keep things as simple as possible.
In the case of this installer, it's relatively unlikely that any individual
developers will create a private build of the installer and install it, and the
way I've got it set up at the moment it would end up with a version number
0.0.0.0.
I'll have a think about it at the moment, but I think we should be ok using a
wildcard. The only other thing that I can think of at the moment is having the
build process generate the guid, but I'm avoiding that for the moment.
Thanks for the advice.
Adam
-----Original Message-----
From: Ian Elliott (Excell Data Corporation) [mailto:[EMAIL PROTECTED]
Sent: 09 October 2008 19:24
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How Update / Upgrade strategy (small, minor, major)
affect file overriding?
There is one side effect that I can think of (and have experienced) during
daily development. Say your build version number changes once per day.
Everything will work fine if you only attempt to install today's version over
yesterday's version.
Now, if you are developing and build multiple private builds during the day,
there can be a problem. If you use the wix wildcard to auto generate
productID's you will have those id's changing and the version number doesn't
change. When people blindly try to install one private build over another you
get weird things happening. It's been awhile and I can't remember exactly what
the deal was but I do remember going to many machines to fix things.
>From earlier in the thread,
"Otherwise it forces the user to uninstall the previous version before
installing the new version - something that I've never had to do with any
serious commercial package."
Most serious commercial packages that I can think of actually use some kind of
setup.exe bootstrapper. I have never purchased any boxed software, for example,
and launched an msi directly. The setup.exe can detect if a minor upgrade needs
to be launched and adjust the command line accordingly.
-----Original Message-----
From: Adam Connelly [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 09, 2008 5:46 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How Update / Upgrade strategy (small, minor, major)
affect file overriding?
I'm keen to avoid doing that since it means creating the bootstrapper. It just
doesn't seem quite right to me to have to do that.
Thanks for the suggestion, but I think for now I'll stick to changing the
product Id. Do you know if there's any undesirable side effects to doing this?
Cheers,
Adam
-----Original Message-----
From: John Hall [mailto:[EMAIL PROTECTED]
Sent: 08 October 2008 18:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How Update / Upgrade strategy (small, minor, major)
affect file overriding?
> The only way I've got this to work at the moment is by
> manually changing the Product Id and checking it in before
> doing a publish to avoid the annoying "another version of
> this product is already installed..." message. Otherwise it
> forces the user to uninstall the previous version before
> installing the new version - something that I've never had to
> do with any serious commercial package.
>
> Is what I'm doing wrong, and if so what alternatives do I have?
You could do minor upgrades for your nightly builds - this requires passing
REINSTALLMODE=vomus on the msiexec commandline, so would probably require being
wrapped in a bootstrapper.
Regards,
John
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
WiX-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
WiX-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
WiX-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
WiX-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
WiX-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
