Hi,

I have an application that I developed in 1.1; the application was delopyed to a large number of workstations via GPO (have used this process multiple times to upgrade the application); I have recently updraded the application to 2.0 and when installing the application on my test workstation (not using GPO at this stage) it fails to upgrade the previous version that was written in 1.1, I end up with the old version and new version sitting in the "Add and Remove programs" list.

I can confirm that both applications have different product codes and the same upgrade code, I have also selected in the 2.0 installer to "RemovePreviousVersions". I have used Orca to check that the upgrade ID are the same even after the setup msi has been built; but still can not figure out why it is failing.

I have not been able to find any documentation on where I might be going wrong on MSDN either; is anyone able to point me in the right direction?

If you have any ideas on how I can find out why it is failing to upgrade (msi checking log's etc.) or any tips I would be very happy to hear from you.


Thanks in advance
Glenn.

One possibility is that the old version was installed per user / Just Me, and the new version is being installed per machine / Everyone. Or, vice versa. Windows Installer does not "find" products installed in the other per user/machine state than how the setup is currently being installed.

Fortunately, in VS 2005 we added a two properties that can help. In the project properties is a property for the default install state... InstallAllUsers... and then on the Installation Folder dialog, a property where you can hide the UI to let the user change the mode.

Hope this helps.

David,

I followed the process of making the 1.1 installer for everyone using orca, and this worked fine accross multiple upgrades within 1.1; are you saying that although I changed the MSI to install for everyone in 1.1 it is still treated as a per user installation by the 2.0 installer? If so is there any modifications to the registry that can be done to make the 2.0 installer think that the 1.1 install was for everyone. The 1.1 install is installed into local_machine key in the registry so I assume it is should be read as for everyone.

http://support.microsoft.com/Default.aspx?scid=kb;en-us;835460

Also, before hearing back from you I created my own custom action for installed using msiexe.exe by reading from the registry; using the following line works fine from command line utility; but when I call the Process.Start() method with the below string it does not uninstall the application. Do you have any ideas why that would be?

C:\WINDOWS\system32\MsiExec.exe /quiet /uninstall {B8E65BB1-05FC-4E21-8B16-401F49DAD54B}

Thanks
Glenn

I think David's pointing out that if the older version was an Everyone install, make sure that your new one is also an Everyone. If your references to 1.1 and 2.0 mean VS 2003 and VS 2005, then make sure your VS 2005 setup project has InstallAllUsers set true to make it default to Everyone.This covers the issues:

http://simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/

That custom action of yours will fail because you can't have two simultaneous MSI actions running at the same time. In this case your MSI is running and you're trying to do an uninstall of another one.

I have been able to get the custom action to work so that it will uninstall all previous versions before installing the latest version; this works great when executing on my local machine. The only problem is now that when I try to deploy the application via Group Policy the installation fails; is anyone aware of how I would be able to find logs of what is failing during the group policy roleout? Is there any logging that can be enabled for group policy and msi?

Thanks
Glenn

When you say it fails, do you mean you get two versions installed at the end, or is it some other error?

Here's the logging policy setting for MSI:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/logging.asp