Have you actually created a true upgrade?  For example, are the upgrade codes identical? Is is a minor or major upgrade? Have you changed the Product Code or kept it the same? Have you incremented the Product Version?
Have you correctly populated the upgrade table with the range of product versions that your upgrade is intended to target?

Having created an upgrade, there is no display of an upgrade option, as the action of upgrading is implicit in the fact that you have created an upgrade. If you are getting the Modify/Repair/Remove dialog then that tells me that you have not created a valid upgrade.

UpgradeSync is just one action in the process of creating an upgrade, but to some extent, the importance of upgradesync is lessened if you choose to reposition the RemoveExistingProducts action between InstallValidate and InstallInitialize.

Ed,

Thanks for the reply. That's what I thought.

I found this table which I tried to implement:

                            Upgrade Code     Product Code      Package Code     Product Version
Minor Upgrade Do not change     Do not change     Change                 Increment
Major Upgrade Do not change     Change                 Change                 Increment

• The upgrade codes are identical.
• I'm specifying a major upgrade for each compile when using the upgradesync tool.
• I'm am not changing the product code but I am incrementing the product version with the updgrade tool. My understanding was that the product code was changed by the tool when specifying major upgrade?
• I specified a range of 1.0.0 to 1.0.999 in the upgrade tool. We are at 1.0.468.

I would implement the last suggestion if I can't determine the problem.

Any other suggestions?

Marc 

Check the contents of your Upgrade table against the specifications in the help file MSI.CHM and make sure that the content of the table makes sense. You should not be getting the maintenance dialogs if the upgrade is working correctly.
Also, have you generated a verbose log of the upgrade process and had a look through it?

Ed,

So I have now implement all of your suggestions, including repositioning RemoveExistingProducts and changing the Product Code ( I have reload the compiled msi's and have validated the Product Code change, Package Code and Version Code differences).

Is there something in the attached setup log that might help you advise me?

Marc

Re-reading the original question, it looks like Marc is expecting to see an 'Upgrade' button or similar when running the new MSI.

Advise you on what? Problem unchanged? Different problem now?
Assuming the situation is that the upgrade process still does not work, the logfile is unlikely to have the necessary information, as the issues are going to be somewhere in either the original MSI or the upgrade MSI. As things stand, we don't even know what your MSI is trying to do.

Actually, I am not sure what I am suppose to see except I don't expect to see modify, repair or unistall, none of which performs an upgrade. I guess I expect to see a variation on the regular install pattern of dialogs. Now I am reading the scripts to see if my predecessor remarked something out with regards to the upgrade process.

Correct - the modify/repair/remove dialog should not be presented in an upgrade situation.
Did you check the upgrade table as I mentioned before?
I think we have reached a point where we need to see the original and upgrade WSI or MSI files

One further question - does the "upgrade" install and run OK if the previous version is not present?

Ed,

Currently I am having everyone do a manual unistall from the Control Panel and the an install, so intalling works just fine. The first two attached screen shots show the values for the different codes. Left is the current and right the last build. The third attachment is a screenshot of the upgrade table.

Regretbly, I don't beleive I am at liberty to distribute the actual MSI without going through channers. I could probably save copies of the WSI of sequential builds and distribute them.

Marc

Ed,

Currently I am having everyone do a manual unistall from the Control Panel and the an install, so intalling works just fine. The first two attached screen shots show the values for the different codes. Left is the current and right the last build. The third and forth attachment are screenshots of the upgrade table.

Regretbly, I don't beleive I am at liberty to distribute the actual MSI without going through channers. I could probably save copies of the WSI of sequential builds and distribute them.

Marc

The setup log you attached earlier is incomplete - it appears that the install was cancelled part way through. I was trying to determine whether the UPGRADE_1 property from the Upgrade table is getting correctly populated with data, but that is not possible with the log sample attached.
The images you have attached look OK with one exception. You have specified an upper version limit of 9.9.999 for the upgrade check which of course is incorrect as you are only trying to upgrade versions to 1.0.467 inclusive. On the basis that one should always try to be accurate in these matters, you should edit this field to 1.0.467, with "Include Maximum version in range" checked (as now).
Also, delete any existing MSI before recompiling, and ensure that the compiler has "Quick Compile" turned off (it is turned on by default).
This avoids some weird errors that can creep in during multiple edits and partial "quick" recompiles.

OK, I made the changes suggestions. Still no upgrade. So I am thinking, what is necessary for this to occur. So I go to the registry and search for the upgrade code. Not found. In fact, there is no entry for the product under HKEY_LOCAL_MACHINE\SOFTWARE. I am assuming that is were I would have found it. I can find the Product Codes under the Installer (I would think it might have been here also with each release) and elsewhere with the various assemblies. Suggestions?

Check the property table and verify that ARPSYSTEMCOMPONENT is not set to 1.
Also check if ARPNOMODIFY ARPNOREPAIR and/or ARPNOREMOVE are in there and set to 1.
Finally, if ALLUSERS is not set to 1 in the original install, then the original install has taken place as a "Per User" install and hence it's installation details would be recorded in the profile of the user who performed the installation.
What is ALLUSERS set to in your upgrade? 
It is important that the setting of ALLUSERS is consistent for the original install and for any upgrades. and should ideally be set to 1, to ensure a per-machine installation.

Ed,

Investigated your suggestions and found:
 

    ARPSYSTEMCOMPONENT, ARPNOREPAIR and ARPNOREMOVE are not present. Do then need to be?
    ARPNOMODIFY is set to 1.
    ALLUSER  is not present. It sounds like from your comments it should be present and needs to be part of a fresh.

Marc

The various ARP- properties are predefined properties and will default to a setting of 0 if not defined.
ARPSYSTEMCOMPONENT defines the MSI as a system component which cannot be uninstalled. Since this is NOT set to 1 in your original MSI, there should be no problems arising when you try an upgrade.
If ARPNOREPAIR and ARPNOREMOVE are not present in your original MSI, it means that there is nothing stopping either REPAIR or REMOVE operations on this MSI.

As far as ALLUSERS is concerned, this has to be the same for the original MSI -AND- the Upgrade. If it is not set in either, then both installs are per-user and there should be no issues as a consequence of a mismatch here.

ARPNOMODIFY set to 1 in any MSI means that during a maintenance operation, the Modify button is greyed out. This means that only repairs or removals are permitted, and again, this should not prevent the upgrade from functioning.

Hope this clarifies. There is more information in the help file MSI.CHM, installed by Wise, which I would recommend as a reference tool.

If I set ALLUSER to 1 and do two builds is that sufficient to establish the original build criteria?

I don't understand the question. What are the original build criteria. Why do two builds?

Also, the property is ALLUSERS and -NOT-  ALLUSER
If you get this wrong you are wasting your time.

You said "As far as ALLUSERS is concerned, this has to be the same for the original MSI -AND- the Upgrade"

Since I am long past the original, with the next (first) build, establish ALLUSERS, e.g. make the "original". With the subsequent, make the upgrade.

Oh, OK, I understand now.

The second sentence has me baffled! Or is the [sarcasm] tag not working?

It has to be [SARCASM] to make it past the UI sequence !!!

Ed,

Although, I implemented every suggestion, I am still posed with the modify/repair/remove dialog instead of the system performing a upgrade. Is there a decision or event, or something else, recorded in the install log that I should look for? The only thing I see that makes sense is that the product code wasn't found in the database which I would hope would be the case since the upgrade table indicates it should change.

Marc

There is something clearly wrong with your upgrade if you are getting a maintenance dialog displayed - basically it is not being seen as an upgrade.
At this point, there is nothing else I can suggest regarding your current project as I have exhausted all ideas I can think of without seeing the actual MSI files, which I appreciate is not possible.
So now is the time for you to start out with a test project with just a few files, then create a test upgrade with updated versions of some or all of the files, and get that working properly. Then see how the two MSIs compare, and reverse engineer that into your current project.

Just had a further thought - do you have either REINSTALL or REINSTALLMODE defined in your original MSI's property table, and if so, which ones and with what settings?

Neither REINSTALL or REINSTALLMODE are defined, but there is a ReinstallRepair set to "r".

Sorry, but there is nothing else I can think of.
Time to start experimenting with a simple test install and test upgrade as I mentioned earlier.

Do you know what are the parameters for ReinstallRepair?

Post your work address and we'll come round en masse and finish your job for you. For free. How does that sound?

Actually the answer is not there, part of the reason for me asking: the other part being that I couldn't find an answer elsewhere, e.g. Google.

Moving on... Looking at my installation script, I can see that the maintenance welcome dialog is set to be called, but I don't see anything refers to a upgrade dialog. Also there isn't a referrence to UPGRADE_1 which is set as an Action Property. Is there an example of a script that considers upgrades?

An upgrade is just that - an upgrade. It has just one function and that is to upgrade a previous install, so it only has standard installation dialogs, as it will be replacing a previous install with a new install. It is not a maintenance operation.
UPGRADE_1, is, if I recall correctly, a property that is set dynamically by windows installer when it detects that the MSI is required to upgrade an existing install. It is not something that you author yourself.

On Error Goto Post6
[/code]

Looking at the installation log, I not sure why since the Product Code was not found that the installer entered maintenance mode. Subsequently, during the install, because it is in maintenance mode, the install doesn't find related products (which I think sets the Upgrade mode) or uninstall the current version as desired.

MSI (c) (24:94) [08:10:52:033]: APPCOMPAT: looking for appcompat database entry with ProductCode '{E41C3D38-0A4C-4917-8B2A-3C205830F90A}'.
MSI (c) (24:94) [08:10:52:033]: APPCOMPAT: no matching ProductCode found in database.
MSI (c) (24:94) [08:10:52:033]: Transforms are not secure.
MSI (c) (24:94) [08:10:52:033]: PROPERTY CHANGE: Adding MsiLogFileLocation property. Its value is 'C:\DOCUME~1\mgeorge\LOCALS~1\Temp\MSI4c76.LOG'.
MSI (c) (24:94) [08:10:52:033]: Command Line: CURRENTDIRECTORY=C:\Temp CLIENTUILEVEL=0 CLIENTPROCESSID=3620
MSI (c) (24:94) [08:10:52:033]: PROPERTY CHANGE: Adding PackageCode property. Its value is '{6276C698-414C-4B0A-BF15-992A8475D678}'.
MSI (c) (24:94) [08:10:52:033]: Product Code passed to Engine.Initialize:           '{E41C3D38-0A4C-4917-8B2A-3C205830F90A}'
MSI (c) (24:94) [08:10:52:033]: Product Code from property table before transforms: '{E41C3D38-0A4C-4917-8B2A-3C205830F90A}'
MSI (c) (24:94) [08:10:52:033]: Product Code from property table after transforms:  '{E41C3D38-0A4C-4917-8B2A-3C205830F90A}'
MSI (c) (24:94) [08:10:52:033]: Product registered: entering maintenance mode
 

Action start 8:10:53: FindRelatedProducts.
MSI (c) (24:94) [08:10:53:658]: Skipping FindRelatedProducts action: not run in maintenance mode
Action ended 8:10:53: FindRelatedProducts. Return value 0.

MSI (s) (F0:08) [08:11:51:672]: Doing action: RemoveExistingProducts
Action start 8:11:51: RemoveExistingProducts.
MSI (s) (F0:08) [08:11:51:672]: Skipping RemoveExistingProducts action: current configuration is maintenance mode or an uninstall
Action ended 8:11:51: RemoveExistingProducts. Return value 0.