Haha, yeah this sucks bad. We ended up having to do different upgrade codes for every instance transform.
Now that sounds simple, and if you have a simple way of doing it I would love to hear it, but we made a dummy upgrade code, so that the Upgrade table would be populated with something at build time. Since it is bogus it should never find anything to upgrade. Then we made a c# custom action to determine, based on the instance transform being used, which upgrade code to use. The custom action then inserted the two rows that we needed (one for upgrading and one to prevent downgrading) into the upgrade table. On Fri, Sep 2, 2011 at 1:18 PM, Daniel Pratt <colorblind...@gmail.com>wrote: > I've authored an installation package (with WIX) that uses instance > transforms to allow multiple installations of the package. Although setting > up the initial package was pretty easy, I found out too late that there > seems to be very little guidance on how to *upgrade* existing instances > when > a new version comes along. > > Previous to dealing with multiple instances, I would've configured the > installation package to perform a 'major upgrade' and not worried about it > further. Alas, it seems that major upgrades do not play nice with multiple > instances. Because all instances share the same upgrade code (so WIX seems > to enforce), installing a new version of the package results in *all* of > the > installed instances get uninstalled (rather than just the one I'm trying to > upgrade). > > What scant advice I could find on the matter led me to doing the following: > For new instances, I use a command line like this: > > msiexec.exe /i "Setup.msi" TRANSFORMS=:INSTANCE.10 MSINEWINSTANCE=1 *...* > > When upgrading an instance to a new version, I use a command line like > this: > > msiexec.exe /i "Setup.msi" /n {58cabe0e-f0f7-494c-a9e9-2fe101419b10} > REINSTALL=ALL REINSTALLMODE=vamus ... > > The above seems to work perfectly *most of the time*. Occasionally, > however, > certain files do not get updated as expected. > > I suspect the cause might be that I am breaking some upgrade rules when > updating the installation package (that I wouldn't have had to worry about > when doing a major upgrade). One possible broken rule might be how I'm > managing the product code. As I have done with other installation packages, > I set Product Id = "*" so the base product code changes for every new > version. Of course, each instance transform specifies it's own product > code, > which is static (if it's possible to make it dynamic, the WIX docs don't > say > as much). Should I be manually changing the product code of each instance > every time? Or should the base product code be static also? Or ought it not > matter? > > In summary, my question is how should I author the installation package and > how should I run it in order to upgrade only a single installation instance > (when there are multiple installed instances)? > > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Tyler Walters ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users