2

I have already looked at Why doesn't my new Windows Installer file (MSI) install properly over an older version of the MSI? But that diden't help me.

I have a program (plugin to Office) which is installed by a setup package (MSI)

Originally the plugin and setup projects was made in Visual Studio 2005. The solution is now moved to Visual Studio 2010. When I make a new MSI and try to install it over an older version the new version won't work before I make a repair using Add Remove Programs->Modify Installation->Repair The new version installs perfectly if I remove the old version first.

It's important for us that the new MSI is able to remove the old version and install the new version smoothly because it is used by several users with no computer experience

The RemovePreviousVersion is set to True. I have upgraded the version from 3.1.1 to 4.0.0 and in that proces accepted a new ProductCode. In Orca I have set the Reinstallmode to amus, but nothing seems to help.

Thanks!

Community
  • 1
  • 1
Kaare Lund
  • 31
  • 5

5 Answers5

1

If I understood correctly you said the upgrade works if run a repair for the new version? This situation could appear when both packages have shared components, i.e. duplicate GUIDs for your package components. To best method to track this down is to create a verbose log of the installation so we can analyze it.

During the repair there is no conflict with the older version, as it has already been removed and the components from the package are installed correct, this is why after that the plugin works.

Can you create a verbose log so we can have a look over it?

Bogdan Mitrache
  • 9,532
  • 15
  • 30
  • Hi. Thank you for the reply. It is correct that the upgrade works fine if I run a repair for the new version. I have made verbose logs of both of the installations. It can be downloaded here http://download.ditmer.dk/klu/Installlogs.zip – Kaare Lund Apr 04 '12 at 11:27
  • The log shows a component with the following GUID is shared by both versions of your application: {1BB1F0AD-8476-42BE-A165-9116EEDCB560} . I recommend you generate a new GUID for this component in the package for the new version and test the upgrade again. – Bogdan Mitrache Apr 04 '12 at 13:18
  • What happened was this, the component being shared by both of the, the new version skipped its installation, but then the uninstall of the older version was removing the shared component due to a bug in Windows Installer, so you were ending up with the missing resources. This is why after a repair everything was working correctly. Generating a new GUID should fix the problem. – Bogdan Mitrache Apr 04 '12 at 13:21
  • Sorry for the late answer, I have been away for the Easter. I have made a new GUID as recommended but unfortunately it dosent seem to help. – Kaare Lund Apr 10 '12 at 05:36
  • Can you post another log, created for the new installation package? Also is the problem present on other machines where an upgrade takes place? It is very important that the machine is clean, i.e. no repeated tests. – Bogdan Mitrache Apr 10 '12 at 06:42
  • There's a new log here: download.ditmer.dk/klu/Installlog_new.zip. The problem is tested on numerous machines - on Windows 7 and on Windows XP. Most of the test takes place on an virtual XP machine which is reset before every test. – Kaare Lund Apr 10 '12 at 09:29
0

Strange, the second log presents no visible issues, so the upgrade should be installed correctly. To get more details we need the verbose log created when the OS triggers the automatic repair. To create this log you need to activate global logging, as explained here: http://support.microsoft.com/kb/2545723

Bogdan Mitrache
  • 9,532
  • 15
  • 30
0

I tried to get more details from the log, but could find much info. However, I found another method to detect the reason of the repair. To get more information about the cause of the on demand install, open the Event Viewer ("Start -> Run", "eventvwr.msc") and look under the Application node for "MsiInstaller" log messages of the form:

Event Type: Warning Event Source: MsiInstaller Event ID: 1001 Description: Detection of product '{000C1109-0000-0000-C000-000000000046}', feature 'Example' failed during request for component '{00030829-0000-0000-C000-000000000046}'

The message and the GUIDs will of course be different on your machine. You can then check the GUIDs in your project to see which component triggers the repair.

Bogdan Mitrache
  • 9,532
  • 15
  • 30
0

By editing msi with Orca Tool, it may be solved your problem.

First I removes the existing products, by setting the sequence number of RemoveExistingProducts after InstallValidate and before InstallInitialize under the InstallExcecuteSequence tab.

Thanks, Saurabh

Saurabh
  • 1
  • 3
0

you should tell us more. Are you exchanging version-number, product-, component-, upgrade- and Package-codes? Which software are you using?

Normally you are keeping upgrade codes the same within a product. You need to specify the version numbers in the upgrade-table including the old/current upgrade codes.

depending where are you schedule the RemoveExistingProducts and if you keeping the component codes, i could be that some old components are not replaced.

i schedule the event always after InstallInitialize.

Check if the action FindRelatedProducts is called.

In this Post you can find a sample using WIX.

Community
  • 1
  • 1
Bernd Ott
  • 4,075
  • 1
  • 23
  • 42