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 WiX-users@lists.sourceforge.net 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 WiX-users@lists.sourceforge.net 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 WiX-users@lists.sourceforge.net 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 WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
