mike_morrison

Hello:

I would like to know if and why it is a requirement that we author a row in the upgrade table to satisfy test case 18.

For "major upgrades" of our installer (as they would be categorized), we allow side-by-side installation. This way someone can have version 1.0, 2.0, 3.0, etc all installed at the same time.

A major upgrade is defined as "A comprehensive update of the product warranting a change in the product code. Essentially, it is a new installation; optionally, it is an application removal."

The keyword in that definition is "optionally". We do not want to remove version 1.0 if the user installs version 2.0, and we also don't want to prevent installation of version 1.0 if the user already has version 2.0 installed.

So why is it a requirement that we author a row in the upgrade table if we do not require the functionality provided by the table (FindRelatedProducts, RemoveExistingProducts, MigrateFeatureStates)

What should I do to pass this test case What can I put in the upgrade table that essentially does nothing Would I author a row that sets the Attributes to 2 (msidbUpgradeAttributesOnlyDetect) and sets Remove to "" (empty string)

BTW, I originally posted this message as a reply in the following thread but that thread was already "answered" so I am reposting as a new question.

http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=1060549&SiteID=1

Thank You,

Mike Morrison


Re: Application Compatibility for Windows Vista Vista Certification Test Cases Test Case 18

Oliver Lundt - MSFT

Good question. I was going to say you could remove the RemoveExistingProducts Action from ExecutionSequence. Doing so would make the upgradecode mean nothing. However orca doesn't really like that. There are other ways to probably drop that row, but I fear a ICE error may occur I will check and see what answer I can find.




Re: Application Compatibility for Windows Vista Vista Certification Test Cases Test Case 18

Oliver Lundt - MSFT

Ok this is what I found out. In general to install a new version side by side you would want a new product code. For example Studio 03 and Studio 05 can be installed side by side because they have different product codes although one is version 7 and the other is version 8. The reason this is done is because no upgrade path exists for 7 to 8. At the same time if an upgrade existed for 7 to 7.1 we don't want that to be applied to version 8.  If this is what you are going for then use poduct code modifications.

However your idea to "author a row that sets the Attributes to 2 (msidbUpgradeAttributesOnlyDetect) and sets Remove to "" (empty string)" should work in not removing the product. Test Case 18 says nothing about the requirement of the Attribute value and should be Ok with this.






Re: Application Compatibility for Windows Vista Vista Certification Test Cases Test Case 18

mike_morrison

Hi Oliver:

Thank you for looking into this for me. Yes, we always change the product code when we are creating new major versions of our product (if we didn't, we would be unable to have version 1.0 and 2.0 installed at the same time). This detail, however, is not really related to my original question.

I will just follow your suggestion and author something to the upgrade table that essentially does nothing so the installer passes the test case. I don't feel good about doing this though. It feels like I'm implementing a hack for a broken test case.

Mike Morrison







Re: Application Compatibility for Windows Vista Vista Certification Test Cases Test Case 18

Oliver Lundt - MSFT

If you change the product code for Major versions then you will most likely want the product code the same for minor versions and use the upgrade table for patches within that major version. This way patches for your minor version can correctly be applied to the same product code (ie your major version)

If you want your patch to be installed side by side, for example 1.0 and 1.1 to be installed side by side then either use a seperate product code for those versions too, or go with the other solution/work around mentioned.




Re: Application Compatibility for Windows Vista Vista Certification Test Cases Test Case 18

mike_morrison

The upgrade table is only for "major upgrades" as far as I understand it. For minor upgrades and patches it is not necessary to author anything in the upgrade table.

I know what you mean though. If, say, we make a 1.5 version and it requires reorganization of the feature-compoment tree then we would need to change the product code. It would become a "major upgrade" of 1.0 if we did not want to allow side-by-side 1.0 and 1.5. At that time we would need to add an entry to the upgrade table to remove 1.0.

Our current installer is not a "major upgrade" to any other version though so this is not necessary.




Re: Application Compatibility for Windows Vista Vista Certification Test Cases Test Case 18

Oliver Lundt - MSFT

It's not just removing that you want to protect against. Although it's not a major upgrade you would want to prevent version 1.0 installing over version 1.5 if version 1.5 was a patch upgrade to the version 1.0. For this reason you would want version 1.0 to be using the MinVersion and MaxVersion so it can install over version 1.5. This will allow you to safely distribute patches for product version 1.0 until you decide to use a new product code.

Completely different story if version 1.5 was intended to be side by side product. This is becasuse you have no problem with version 1.0 being installed side by side to product version 1.5 Therefore you don't want to stop your users from installing 1.0 over version 1.5 and they won't be stopped if version 1.5 has a different product code.

In summary I don't think you lose anything by following the requirement. For example lets say you start off with version 1.0 and product code GUID {ABC}.  You have the Min and Max version to only allow for an patch upgrade to version 1.1 with upgrade code Guid {ABCD}. You ave the freedom to upgrade your product to version 1.1 and protect your users from accidently installing version 1.0 over 1.1

Now lets say you all of a sudden decide that version 1.1 should be allowed to be install side by side. Simply change the product code to GUID {ABCDE} and it will now install side by side version 1.0 no problem because it's completly a different product code. Meanwhile you had the freedom to decide that your users should apply an upgrade patch forcing them to follow an upgrade path safely.

 






Re: Application Compatibility for Windows Vista Vista Certification Test Cases Test Case 18

mike_morrison

I know the upgrade table is not just for removing previous versions of software. It is also for preventing older packages from installing over new ones. The way I understand it, this is mechanism is only really necessary if the product code differs between the two installs. If the product codes match then it is not a "major upgrade" and windows installer has another mechanism for this case.

Example: If I install 1.1 and then try to install 1.0 (both sharing the same product code), I get a message "A later version of 'Product Name' is already installed on this machine. The setup cannot continue." This is without any entries in the upgrade table.

I actually think adding an entry to the upgrade table to prevent installing an older version over top of a new version could be detrimental in some cases.

Say you add an entry to the upgrade table for your product (version 1.0). VersionMin is 1.0, VersionMax is NULL. Now you can't install version 1.0 if version 2.0 is already installed. So maybe 1.0 should have had a VersionMax set to1.99.9999 or something. This would allow version 1.0 and 2.0 to install side-by-side. But then what happens if you later decide you want to create a 1.5 that is also installable side-by-side If you install 1.5 first, 1.0 will not be able to install because it will find the related product within the range. So the only option would be to create a new build of the 1.0 installer that has a modified upgrade table (VersionMax set to 1.4.999 or something).

I think the only way around this is to know well in advance exactly what the product plan/roadmap is (and that is not always an option).







Re: Application Compatibility for Windows Vista Vista Certification Test Cases Test Case 18

Oliver Lundt - MSFT

You are absolutly correct in you understanding.

When I was saying to use VersionMin and VersionMax, VersionMin Should be for NewerProductFound and VersionMax should be used for PreviousVersionInstalled

Using them incorrectly together on the same ActionProperty would not be good.