Test Case 18, ProductVersion constraint

Test Case 18, ProductVersion constraint

• Lawrence 007

  So you are fine with the way you have it! Take a look at this msdn example to confirm:
  http://msdn.microsoft.com/library/default.asp url=/library/en-us/msi/setup/preventing_an_old_package_from_installing_over_a_newer_version.asp

  If you set some very large number like 255.255.255, then your next version release will need to be higher. So it's a good thing you confirmed this! I understand the confusion on the wording!
  
  

  
  
  

• xBitx

  In my case, out product (www.creativedocs.net) passed the test with the following table :

  xxx 2.0.8 - - 258 - NEWERPRODUCTFOUND
  xxx 1.0.0.0 2.0.8 - 256 - PREVIOUSVERSIONINSTALLED

  I hope this helps.

  Pierre

  
  

• Tryin2Bgood

  For everyone's benefit, starting my new application version at 1.0.1 and not 1.0.0 resolved the issue.

  
  

• John.Doe

  Oliver,

  Test cases v1.2 already released. No changes. What to do We cannot change application just to pass test. Also, let's look comment at 19 Feb 2007, 5:05 PM UTC - test was passed correctly with this value not NULL.

  
  

• Steve98796

  I have a similar problem. My application is a NEW application - version 1.0.0. There is no previous version! The table looks like this:

  xxx 1.0.0 - - 258 - NEWERPRODUCTFOUND

  xxx 1.0.0.0 1.0.0 - 256 - PREVIOUSVERSIONINSTALLED

  I get ICE61 error, specifically:

  Upgrade.VersionMax cannot be less than Upgrade.VersionMin. (OLDAPPFOUND)

  I can manually edit the table in ORCA to something like:

  xxx 0.9.0 0.9.9 - 256 - PREVIOUSVERSIONINSTALLED

  and pass ICE61.

  Two questions:

  1. Where does the 1.0.0.0 come from And why isn't it 1.0.0 (i.e., Major.Minor.Build) We are told to use the three-part format, not four....

  2. How do I get around this in Visual Studio Do I have to start my application at 1.0.1 I really don't want to have to manually edit the table with ORCA since Visual Studio digitally signs my MSI automatically.

  Thanks,

  John.

  
  

• Nyasha

  BEWARE!

  I had this test case failed in the first try, because VersionMax of PreviousVersionInstalled was the same value as VersionMin of NewerProductFound. I learned this "new rule" from Veritest. It was written nowhere.

  I can't help thinking this Test Case was really badly written, when attribute msidbUpgradeAttributesOnlyDetect(=2) is set (like you did for NewerProductFound => 256 + 2), there is no reason for the certification authority to check values in this row. Only detects, means that is used for private purpose by the MSI author, and the MSI engine won't use it for removing related products.

  I passed this test case on second try with the following table

  xxx 3.3.586 - - 258 - NEWERVERSION
  xxx - 3.3.585 - 256 - OLDERVERSION

  
  

• Stephen_Sbh

  Your current values in your orginal post are correct for minversion and maxversion.
  
  The MSDN links we provided confirm this. I also know of an application submitted with similar values and it passed logo testing just fine. The testers at Verritest are familar with testing msi packages. I also double checked with logo testing authorities and recieved the following "By definition either one or the other has to have a value ,they both cannot be null for the same component"
  
  The verbage in the test cases matches the MSDN articles. Although the text maybe confusing and subject to interputation the intent is to keep verbage the same and consistant with MSDN. That said there is a new version of the test cases v1.2 that will be released soon it will contain more information to make this less confusing... Although not finalized and released yet it should say something to the effect:
  
  "VersionMax may be Null causing the installer to detect all products greater than or equal to VersionMin. VersionMin and VersionMax both must not be null per UpgradeCode"
  
  
  
  

• AvalonNewbie

  Does this mean that my application will pass Test Case 18 with the current values
  

• Jerry Hung

  Just use 255.255.65535.65535 as upper boundary, in this way you will be sure to pass this test case.

  If you leave it to null, as Verisign testers are probably not experts in Windows Installer, you may fail.

  
  

• Ermac

  Hello Petrus,

  According to the Test Case Spec:

  VersionMax in the upgrade table is the upper boundary of the range of product versions detected by the FindRelatedProducts action. VersionMax and VersionMin both must not be null.

  And the MSDN Documentation found here: https://msdn.microsoft.com/library/default.asp url=/library/en-us/msi/setup/upgrade_table.asp

  Upper boundary of the range of product versions detected by the FindRelatedProducts action. Enter msidbUpgradeAttributesVersionMaxInclusive in Attributes to include VersionMax in the range. If VersionMax is an empty string (""), it is evaluated the same as 0. If VersionMax is null, FindRelatedProducts ignores msidbUpgradeAttributesVersionMaxInclusive and detects all product versions greater than (or greater than or equal to) the lower boundary specified by VersionMin and msidbUpgradeAttributesVersionMinInclusive. VersionMin and VersionMax must not both be null.

  Which states that you must have atleast one boundry on either min or max. So this is an XOR situation where one or the other can be null but never both.

  Thanks!

  Matthew Braun

  
  
  
• Test Case 18, ProductVersion constraint