The product out there (and it has had many releases) did not set
upgrade code but used a registry key in the past. So, do I not have a
situation where UpgradeVersion tags would fail if I suddenly introduce
them, and where I need to keep the old scheme
in parallel?

Specific about this product is that it is not installed individually
but deployed on a broad front automatically. In production, there are
at maximum two releases (rc and current stable) in use at any given
time.

I would like to use what everybody uses if I just can handle the fact
that the installer did not provide Upgrade code in the past.

Also, what are best practices around generating the upgrade code and
when to change it?

Yesterday I wrote something like this (improvements are welcome, and
not yet tested):

        <Property Id="CUR_VER">
                <RegistrySearch Id='CurrentVersion' Root='HKLM'
Key='Software\Foo\Client' Name='CurrentVersion' Type='raw'/>
        </Property>

<CustomAction Id="VersionCheck"
                VBScriptCall="Main"
              Property="VersionCheck" />

<Property Id="VersionCheck">
                <![CDATA[
                    Function CompareVersion(ver1,ver2)
...
                    End Function

                    Function Main()
                          
if(CompareVersion(Session.Property("CUR_VER"),Session.Property("ProductVersion"))
= "older") then
                            Main = 3
                          else
                            Main = 1
                          end if
                    End Function
                ]]>
        </Property>

        <InstallExecuteSequence>
                <Custom Action="VersionCheck" After="CostFinalize"/>
...



On Wed, Mar 3, 2010 at 4:50 AM, Sascha Beaumont
<sascha.beaum...@gmail.com> wrote:
> MSI sees 1.2.3.10 and 1.2.3.9 as 1.2.3 - so they appear as the same
> version. In order to prevent a downgrade on a 4th field change, you
> can rely on the (documented) fact that MSI ignores the 4th field to
> prevent installs where the version numbers are identical to Windows
> Installer.
>
> I use the following code to prevent installing one "build" over
> another as we do regular internal builds and increment one of the
> first three version fields after each and every public release. This
> prevents internal users or beta testers moving along an unsupported
> upgrade path... be warned however, this will probably break minor
> upgrades and patches so test throughly before shipping ;)
>
>
>                <UpgradeVersion Property="ANOTHERBUILDINSTALLED"
>                                 Maximum="$(var.version)" 
> Minimum="$(var.version)"
>                                 IncludeMinimum="yes" IncludeMaximum="yes" 
> OnlyDetect="yes" />
>
> ...
>
> <CustomAction Id="CA_BlockAnotherBuildInstall"
> Error="!(loc.LaunchCondition_AnotherBuild)" />
>
> <InstallExecuteSequence>
>    <Custom Action="CA_BlockAnotherBuildInstall" After="FindRelatedProducts">
>        <![CDATA[ANOTHERBUILDINSTALLED]]>
>    </Custom>
> </InstallExecuteSequence>
> <InstallUISequence>
>    <Custom Action="CA_BlockAnotherBuildInstall" After="FindRelatedProducts">
>        <![CDATA[ANOTHERBUILDINSTALLED]]>
>    </Custom>
> </InstallUISequence>
>
> On Wed, Mar 3, 2010 at 4:28 AM, Wilson, Phil <phil.wil...@invensys.com> wrote:
>> The solution in the tutorial is fine. It's the way that "everybody" detects 
>> versions based on UpgradeCode, old and new to prevent downgrades and perform 
>> upgrades.
>>
>> You have a problem in that the 4th digit of the ProductVersion isn't used 
>> anyway in major upgrades, so your upgrades will require you to make an 
>> increment somewhere in the first three fields.
>>
>> Phil Wilson
>>
>>
>> -----Original Message-----
>> From: Ragnar Rova [mailto:r...@mima.x.se]
>> Sent: Tuesday, March 02, 2010 7:56 AM
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] Preventing downgrades as a launch condition
>>
>> Hi.
>>
>> I need a simple way to prevent downgrades a product in a wix based msi
>> installer.
>>
>> The old defective way which I found was something along:
>>
>> <Property Id="CUR_VER">
>>         <RegistrySearch Id='CurrentVersion' Root='HKLM'
>> Key='Software\Foo\Client' Name='CurrentVersion' Type='raw'/>
>> </Property>
>> <Condition Message="Cannot install this version [ProductVersion] over
>> an existing installation [CUR_VER] that has a higher version number.
>> You may need to uninstall it first.">
>> NOT CUR_VER or ProductVersion&gt;=CUR_VER</Condition>
>>
>> I want something which allows 1.2.3.10 to upgrade from 1.2.3.9. The
>> version above just does a string compare which fails.
>>
>> Don't know if the solution at
>> http://www.tramontana.co.hu/wix/lesson4.php works. I would prefer
>> something which uses my registry key from the example above.
>>
>>
>> According to
>>
>> http://msdn.microsoft.com/en-us/library/aa368012%28VS.85%29.aspx you
>> cannot compare versions at all in conditions but they suggest
>> searching for versions of installed files using Appsearch.
>>
>> I'm fine with calling some external vbscript code or something which
>> does the registry searching and comparison
>>
>> I don't understand how the answer at:
>>
>> http://stackoverflow.com/questions/2109408/sequencing-custom-action-in-wix-before-launchconditions
>>
>> relates to my question but they mention preventing downgrades in wix.
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>> *** Confidentiality Notice: This e-mail, including any associated or 
>> attached files, is intended solely for the individual or entity to which it 
>> is addressed. This e-mail is confidential and may well also be legally 
>> privileged. If you have received it in error, you are on notice of its 
>> status. Please notify the sender immediately by reply e-mail and then delete 
>> this message from your system. Please do not copy it or use it for any 
>> purposes, or disclose its contents to any other person. This email comes 
>> from a division of the Invensys Group, owned by Invensys plc, which is a 
>> company registered in England and Wales with its registered office at 
>> Portland House, Bressenden Place, London, SW1E 5BF (Registered number 
>> 166023). For a list of European legal entities within the Invensys Group, 
>> please go to 
>> http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77.
>>  You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail 
>> inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be 
>> subject to the terms of any agreements between Invensys (and/or its 
>> subsidiaries and affiliates) and the recipient (and/or its subsidiaries and 
>> affiliates).
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to