3 replies to this topic

[BourqueJ]

Hi,

I've been debugging this issue for 2 days now and I still don't get why this simple procedure don't work.

The situation is:

1. I create a small msi which installs only 1 file. (1 component and the file is the keypath) The package version is 1.0.0.0.

2. I install the package on the target machine

3. I create a new version of the package. (I changed the package code and the version to 1.0.1.0. The product code remain the same. By definition, this is a minor upgrade)

4. I install the new package on the target machine by using "msiexec /i MySetup.msi REINSTALLMODE=vomus REINSTALL=ALL". At that point, the files are updated and the version shown in Add/Remove Programs is 1.0.1.0.

5. If I do a repair of the 1.0.1.0 installation (via Add/Remove Programs), the installation is reverted back to 1.0.0.0.

I've enabled msi logging to see what happened when the repair was executed and I found this :

...
MSI (s) (18:74) [14:47:10:597]: Machine policy value 'DisableUserInstalls' is 0
MSI (s) (18:74) [14:47:10:597]: Attempting to recache package via ProductCode. Beginning source resolution.
MSI (s) (18:74) [14:47:10:597]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (18:74) [14:47:10:597]: User policy value 'DisableMedia' is 0
MSI (s) (18:74) [14:47:10:597]: Machine policy value 'AllowLockdownMedia' is 0
MSI (s) (18:74) [14:47:10:597]: SOURCEMGMT: Media enabled only if package is safe.
MSI (s) (18:74) [14:47:10:597]: SOURCEMGMT: Looking for sourcelist for product {865B50F5-00F1-4EBC-A7AE-BA849D8A41BD}
MSI (s) (18:74) [14:47:10:597]: SOURCEMGMT: Adding {865B50F5-00F1-4EBC-A7AE-BA849D8A41BD}; to potential sourcelist list (pcode;disk;relpath).
MSI (s) (18:74) [14:47:10:597]: SOURCEMGMT: Ignoring last used source.
MSI (s) (18:74) [14:47:10:597]: SOURCEMGMT: Now checking product {865B50F5-00F1-4EBC-A7AE-BA849D8A41BD}
MSI (s) (18:74) [14:47:10:597]: SOURCEMGMT: Media is enabled for product.
MSI (s) (18:74) [14:47:10:597]: SOURCEMGMT: Processing net source list.
MSI (s) (18:74) [14:47:10:597]: SOURCEMGMT: Trying source C:\WINDOWS\Downloaded Installations\{AB3D337A-2D67-43F2-ADFB-22347E9D8F54}\.
...

As you can see (line in bold), the windows installer service ignores the last used source from the registry and redo the search for the source package. Since the two package were launched from 2 different sources, 2 different source location can be found in the registry. The windows installer tries to find the source by browsing each of these source starting by the first one (the previous version) and repair the installation using the previous version.

I can redo this procedure over and over and the same behavior happens. If a mojor upgrade is done (by changing my product code), the repair works fine. If I use the same source location to install the new version, the repair works fine.

I tried with InstallShield 10.5 and Wise Installer 6.0 and the same behavior occurs. I have to believe then that the problem lies in the Windows Installer service.

Anyone have any suggestion? If you try the same procedure as I did, do you get the same behavior?

Any help would be appreciated!

Thanks in advance!

Jacques Bourque.

[Stefan Krueger]

From which location do you install the update? From local hard disk or from removeable media (CD) or from network? Is the install media (new source location) availabnle at the time of repair?

[BourqueJ]

Hi Stefan,

first of all, thanks for the reply!

The packages run from the local computer. In this case, I used the bootstrapper from Installer which I configured to decompress the msi file in "C:\Windows\Downloaded Installations\[PackageCode]". So as you can see, I will have a folder for each package I release. After the package is decompress, the windows installer run it from there.

I've been doing some testing this weekend and I found that if I run the MSI from the exact same location (install the first one, overwritte the msi with the new one.. run the update and do a repair via ARP), the same line appears in the log but this time, there is only 1 SourceDirectory in the registry. I can also delete the first MSI and run repair and it will be ok. Again, the line appear but it cannot find the first SourceDirectory so it goes to the second one.

The problem occur only if the repair of the updated setup run from ARP. In my official project, I have a shortcut in the StartMenu to add or remove some features. (I basically call "msiexec /i [ProductCode]") The repair from that shortcut runs fine. (no revert to previous version)

Here is a line from the log of a repair from the shortcut in the StartMenu.

...
MSI © (78:1C) [09:43:19:601]: Package we're running from ==> C:\WINDOWS\Installer\3571be.msi
...

There is no SOURCEMGT lines in the log.

Do you know how windows call the repair from ARP? I can reproduce the problem by calling "msiexec /fvomus [ProductCode]".

Thanks again,

Jacques Bourque.

[saurabh2688]

Hi Jacques Bourque,

 

Did you find the solution for this problem?

I am facing the same issue with my application.