CODEWITHSUNDEEP
windows-installer
Kaare Lund
Kaare Lund

Reputation: 31

Install (MSI) won't install properly over old version

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!

Upvotes: 2

Views: 3011

Answers (5)

coding Bott
coding Bott

Reputation: 4357

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.

Upvotes: 0

Saurabh
Saurabh

Reputation: 1

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

Upvotes: 0

Bogdan Mitrache
Bogdan Mitrache

Reputation: 11003

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.

Upvotes: 0

Bogdan Mitrache
Bogdan Mitrache

Reputation: 11003

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

Upvotes: 0

Bogdan Mitrache
Bogdan Mitrache

Reputation: 11003

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?

Upvotes: 1

Related Questions