PDA

View Full Version : BASIC MSI - running repair after minor upgrade restores wrong version



DLee65
03-12-2008, 01:38 PM
QA is running tests for a product that has had a minor upgrade applied.
Original Install Location: \\network\App\Original\my.msi
New Minor Upgrade: \\network\App\Upgrade\my.msi

After the upgrade completes, they verify that the product is upgraded from 1.00.0000 to 1.01.0000 and that the upgraded files are installed.

For this repair test they go in and delete all the files included with 1.01.0000. They go to Add/Remove Programs, click on Change, and then run repair for the install. After the install is complete the user now has the original 1.00.0000 installed instead of the 1.01.0000 that we expected.

How do I ensure that repair restores the correct files after a minor upgrade?

Looking at the MSI file, repair is looking for the setup in:\\network\App\Original\my.msi.

Note that the test OS is Vista and of course it is using windows installer 4.0.

DLee65
03-12-2008, 03:31 PM
Hmmm, could the reason be that I did not author a minor upgrade in the upgrade table ... :o

HennoKeers
03-12-2008, 03:50 PM
Hmmm, could the reason be that I did not author a minor upgrade in the upgrade table ... :o

A save way in handling minor updates is to use patches; .msp's.
You can use quickpatch if you have only some files to replace.
It's quiet easy.

reg, Henno.

bryanwolf
03-13-2008, 09:18 AM
Minor Upgrades are not authored in to the Upgrade table. The Minor Upgrade item in the IDE actually only runs validation during installation, hehe :)

At any rate, the behavior you're describing sounds like the minor upgrade didn't actually minor upgrade your product. Have you verified the ugprade in a log?

Also, the REINSTALLMODE property needs to have a 'v' in it or you're guaranteed to have issues.

DLee65
03-14-2008, 08:24 AM
Thanks for the reply Bryan. I have verified that the REINSTALLMODE does include the 'v' switch, so that is not the issue.

What seems to be happening is that when I run repair from Add/Remove Programs is that the cached MSI database is running from the original source instead of the repaired source.

I ran a couple of tests this morning. This ONLY occurs when running repair from Add/Remove programs and only if I have updated the original setup from another full setup. If I delete the new files and launch the application then resiliency kicks in and the files of the correct version are restored.

If I create a downloadable patch and install it, then repair from Add/Remove Programs works correctly.

So based on these findings I can determine the following:
1. REINSTALLMODE is configured correctly.
2. The minor update did detect the original program otherwise all scenarios for repair would fail.

Now to determine why this particular implementation fails. Any ideas out there from the community ... or from the Macrovision team? Thanks. I have attached an MSI log from the ARP repair process.

JPBRAAK
04-23-2008, 04:14 AM
Any news on this problem, I have found similar posts on several sites... none of them have an answer that solves this...

I know that a patch can do the trick, but this is something I would really like to know...

Jeroen ( PDS)

DLee65
04-23-2008, 07:31 AM
No, I never found a solution. If repair from ARP is executed then the original files are restored not the files in the .msp. Resiliency Health Check works correctly. In the end I had to chalk it up to a limitation of the MSI engine. In these scenarios the user will be required to run the patch setup again.

bryanwolf
04-23-2008, 12:05 PM
Sorry to not get back to you DLee65.

I meant to reply back that your log file indicates that you're suffering from the Windows Installer Repair bug, you can see it's setting REINSTALLMODE to the following value during reinstall:
REINSTALLMODE=ocmusv

Because it contains the 'v' parameter during the repair, it's going to recache the MSI package. That's obviously not even close to what you want to do.

Tim Mayert
02-23-2009, 01:47 PM
Did you get any where with this issue?

I ran into the same issue and I talked to Acresso Support about this and This is want they replied with:



The repair problem you are facing is linked to the value that Add Remove programs gives to REINSTALLMODE, the log files shows this:

REINSTALLMODE=ocmusv

The v in REINSTALLMODE for a repair causes very unwanted behavior, it causes Windows Installer to use the old source (original MSI) and also to re-cache that source so it becomes the default. This only happens if repair is launched from the repair button from ARP (though you can reproduce from the command line to see the behavior). There is no way to modify this behavior as it is part of the OS.

There are two things that you can do to prevent this:

1) Disable the Remove button in ARP

2) Delete the old cached MSI as part of the upgrade process. Then when MSI resolves source as it cant find the old one it uses LastSource which gives the expected behavior.

So to use the 2nd option we have to delete the old cached msi, but where would we find this?

If you have any other suggestions that are the the same as these then can you let me know?

Thanks,

Richard Winks
04-21-2011, 09:48 AM
After rereading the previous post it occured to me that there would be no further attempt to correct this behavior. The "REINSTALL=ocmusv" explanation suddenly made sense.

(I had originally posted)
Was this ever resolved?
I am currently using IS 2010

I'm experiencing the exact same issue with my Basic MSI installation.
Install 1.1
Minor Upgrade 1.2
Minor Upgrade 1.3
Repair from Add or Remove Programs Panel and it restores 1.1

Richard

tasifa
05-11-2011, 01:38 AM
Just like the heart and the lungs and the stomach, the skin is by definition an organ. Of all of the organs in mammals, the skin is by far the largest. This is why people with deep, massive burns are often not expected to live. A bodily organ is a collection of tissues that are structurally joined for a purpose. The skin is a marvelous model of indispensable function.