I have Product_B which is superset of Product_A. Product_B branched it's code base from Product_A's during V1.002.xxxx of it's release. Product_A also had a minor upgrade release to bring it's code set to V1.003.xxxx. (Product_A and Product_B share upgrade codes but differ in product version and codes)
The situation we are encountering is this:
Product_B's install must be able to detect all versions of Product_A and uninstall it and then install Product_B. This works perfectly as a major upgrade of Product_B over Product_A version 1.002.xxxx, but fails for major upgrade of Product_B over Product_A version 1.003.xxxx
We have turned on verbose logging and determined that the problem is due to the fact that Product_B shares a bunch of assemblies with Product_A in v1.002.xxxx, however, Product_A has a lot of newer assemblies in Product_A v1.003.xxxx and the install decides that an upgrade of those assemblies is not needed, but still uninstalls the previous version. It then only installs those files that are newer.
Is this expected behavior? Why would it evaluate files before uninstalling the previous product?
This is great... however, we are not using the GAC. Our assemblies are installed to [ProgramFiles]... this however, still sounds like we can either re-arrange our sequencing, or rev our assemblies.
For Private Assemblies and other files, the concepts remain similar. You can't major upgrade to a lower version of a file. It sounds like that's similar to what you're intending to do.
Typically, when this situation occurs it's as a result of GAC related issues. If you're doing a "Major Downgrade" as it were, you might try setting the "Always Overwrite" option for these files or change their versioning to above the existing Version_A's.
