10 replies to this topic

[peter.a.stephens]

Symptoms
I have newly created setup package (MSI) that installs a new version of my application.

I have a new ProductCode for my installation but I have left the UpgradeCode the same.

So when I execute the new MSI it first uninstalls the old version correctly. Even the Program Files\MyProduct directory is removed.

But after uninstalling the old version the installer then only partially installs the new version. If I repair the damaged new installation (Using Add Remove Programs->Modify Installation->Repair), everything is fixed.

If I first uninstall the old version using Add Remove Programs and then install the new version everything works great. The problem only occurs when I install the new version over top of the old version.

Possible Cause
The version numbers for various dlls and exes in the old version were messed up. The old exe version is 4.11.1234. The version for the new exe is 4.5.1234. According to the "File Versioning Rules" the new file will not overwrite the old file. The reason why I am scratching my head is that by the time the InstallFiles action executes the destination file no longer resides on the disk.

Other Information
I'm targeting Windows Installer 3.1.

My installation execution sequence is roughly:

[peter.a.stephens]

It's almost as if Windows Installer is deciding which files to copy from the source media before it uninstalls the old version. Hmmm.

[VBScab]

What does a verbose log tell you?

[peter.a.stephens]

See attached text file for a verbose msi log.

The InstallFile list only includes the files that actually get reinstalled. One file that is absent is qvinci.exe. It shows up in the RemoveFiles action but not the InstallFiles action.

One possible problem is that the old version is 4.11.0 whereas the new version is 4.5.0.

I'm currently uinstalling the old version before I'm installing the new (major) version.

As an aside, if I were to uninstall the old version at the end, I would expect to have qvinci.exe copied, but that it would be the wrong version (4.11.0)

Thanks!

Attached Files

•  log45.zip   54.88KB   182 downloads

[VBScab]

Unfortunately, that isn't a verbose log. A verbose log shows you things like the command line, what features have been selected for install and so on. None of that is present here.

Get a verbose log with the argument '/l*v [path_to_and_name_of_log_file]'

For the purposes of logging, can you also ditch the pre-req and run the MSI directly, i.e. not inside a set-up stub EXE?

[peter.a.stephens]

Thanks VBScab!

I didn't realize that /l* didn't include verbose information. Now I know...

Anyway I've included two new log files:
1. The first log shows the installation process for the old msi installer. There are obviously problems with this MSI, but it has already been shipped to customers, so I'm stuck with it.

2. The second log shows installing the new installer over the old installer.

I started with a clean slate before my test run by using a virtual machine and rolling back to a clean snapshot (XP SP2 w/Dotnet 2.0 SP1)

A side question: are there tools to make sense of the verbose log? I'm suffering from a bit of information overload from all this data :-)

Thanks!

Attached Files

•  logs.zip   240.02KB   260 downloads

[luke_s]

One thing I have noticed is that the component with guid "D49E7512-DD69-41A8-B167-9106C04A24EB" that is used for the qvinci.exe file is not even listed under the InstallValidate action.

I think that would be why your file is not being installed.

And I think the reason for it not being listed in the InstallValidate action is because its being set to remove. See the line below in your log.

MSI (s) (C0:DC) [13:50:34:331]: Executing op: ComponentUnregister(ComponentId={D49E7512-DD69-41A8-B167-9106C04A24EB},,BinaryType=0,)

Depending on your sequencing of RemoveExistingProducts, you might have to change the GUID for this component.

i.e if RemoveExistingProducts is before InstallFiles, then you can use a new GUID.

But if you place RemoveExistingProducts AFTER InstallFiles, then you can't change the GUID (if qvinci.exe is installed in the same path) becuase the RemoveExistingProducts action will remove the newly installed files.

Sorry for the long winded explanation, hope that makes sense.

So to sum up, try changing the GUID for your component and see if that fixes it.

[peter.a.stephens]

Thanks, Luke!

I'm not sure that changing the component guid for qvinci.exe component (of which qvinci.exe is the key file) will solve the problem.

The setup project I am using (InstallShield 2009 Pro) is completely fresh and built from scratch. So I don't think the component ids match between the old and new installers. That is also why (among other reasons) I am doing a major upgrade.

I will try your suggestion though. You never know, it might work.

Plan B will be to carefully read the large log file and glean any hints I can find. I'll focus on the areas around InstallValidate, InstallInitialize, RemoveExistingProducts, and InstallFiles.

Some questions:
1. Which action builds up the list of files to copy from source media? Or is this an internal msi mechanism?
2. I've run rarice.cup and currently only get warnings. Is there any other sort of validation I can perform on the MSI?
3. Would /l*vx be more useful than /l*v for diagnostics purposes?

I'm a bit of a newb when it comes to Windows Installer. So please be patient with me!

[luke_s]

No worries Peter. Windows installer can get quite daunting sometimes!

1. Im pretty sure InstallValidate goes through and works out which components[U] to install, thus determining which files to install. Thats why I think that since the component for the qvinci.exe file is not being installed, that is the cause.

After re-reading the log, I could be wrong about the component guids, but I think it must have something to do with the component state somewhere after InstallValidate.

If you install your NEW packaging with verbose logging, you should be able to see that the component that has the qvinci.exe should have an action as "local". Check to see what this is set to for the upgrade.

2. If you use ORCA, it also has a validation engine you can use. ORCA is a microsoft tool supplied in the Windows Platform SDK that lets you edit MSI packages at the database level.

3. /L*V should give you everything. From what I've seen, adding the x doesnt really give you any extra details.

[Stefan Krueger]

[peter.a.stephens]

Thanks Stefan, Luke, and vbscab for your help.

I tried various placements for the RemoveExistingProducts action. I also tried to move around the InstallExecute (and InstallExecuteAgain). But nothing seemed to help. Indeed the Windows Installer seems to determine what should be reinstalled long before it removes the existing product.

So bumping up the version numbers solved most of my problems.

I also had an unrelated problem with a broken merge module. A new install would work fine over an older install, but a single COM interop assembly in the gac (no change in version #) would be removed but not reinstalled.

So, the first time I ran the application, the Windows Installer healing mode would take over silently (it did not display a UI) and reboot the machine without asking. I could only determine what was happening after the fact through the installer and event logs.

Also, strangely, the COM component MSM had a dependency on the COM interop MSM. That seems reversed to me...

It turns out I only had a dependency on the COM components (a separate MSM), not the interop, so I just edited the COM component MSM and removed the dependency to the introp MSM.

Now I have a separate problem with an update patch but I will ask that on a new thread :-)


Again, thanks everybody for your help.