LEMIRE, JOHN wrote:
The scenario is an automated deployment environment that attempts to
run a scheduled upgrade of minor revisions of a product.
Therefore the numbers of the currently installed and to be installed
versions only differ in the revision position.
The major/minor/build positions are identical. This leads msi to not
perform the install as it only looks as far as build to determine
difference.
The first best practice: For product versions, the build number should
increment with every build. A common scheme is to encode a date of some
kind in the build number and to use the revision only in the case of
multiple builds on the same day.
Being a good wix citizen I have set my <Product Id="*" .../> which
means new ProductCode for every build and makes it hard to script
uninstall by ProductCode.
Is there a way to achieve the unistall that I'm overlooking? Getting
the build portion of the version number changed is beyond my control
and even new minor revisions do need to be deployed for testing.
It's easy if you need to track only the products that have been shipped
to customers: Open 'em up in Orca and write down the ProductCode
property value.<g> Otherwise, you need to write a bit of MSI SQL to get
it so it can be recorded somewhere. Something like:
SELECT `Value` FROM `Property` where `Property`.`Property` = 'ProductCode'
--
sig://boB
http://joyofsetup.com/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
