Setup does not install VSTO runtime before installing VSTO runtime SP1

Question

Hi there,

I'm deploying an Office 2007 AddIn for Outlook. Therefor I created a MSI project as described at http://msdn.microsoft.com/en-us/library/cc563937.aspx and it almost works fine. The AddIn requires .NET Framework 3.5, Windows Installer 3.1, Office 2007 PIA and VSTO runtime 3.0 with language pack.

In the properties of the MSI project I marked the prerequisites as recommended in the article mentioned above.

The folder being created through the build process of the MSI contains the following folders.

DotNetFX35
Office2007PIARedist
VSTOR30
WindowsInstaller3_1

The folder VSTOR30 contains the following files.

vstor30.exe
vstor30sp1-KB949258-LP-x86-DEU.exe
vstor30sp1-KB949258-x86.exe
vstor_lp_de_30.exe

In the properties dialog of the MSI setup project and there in the required components dialog I can only mark "Visual Studio Tools for the Office System 3.0 Runtime Service Pack 1" as required component. But there is no item for "Visual Studio Tools for the Office System 3.0 Runtime" without the Service Pack.

Because the fact when installing my AddIn is that the installation of the prerequisites fails while installing the Service Pack 1 for VSTO because VSTO is not installed yet. Manually installing VSTO runteim before the setup is called will succeed installing my AddIn.

So how do I add "Visual Studio Tools for the Office System 3.0" the required components dialog box?

And by the way: how do I define the order of the required components to be installed on the target system within the MSI setup project?

I also checked out the files in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages on my XP developing machine whether some files are missing but that looks good to me. That means I did not miss files.

What do I have to do for my MSI setup to install VSTO runtime before installing VSTO runtime SP1?

Thanks in advance

Mõbius

Answer 1

Hi Mõbius,

On the machine where you are attempting the bootstrapper install can you tell me if you have this key and what subkeys and values are under it: 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\vsto runtime Setup

This sounds like a problem I am familiar with.

Cheers,
Aaron

Answer 2

Hi Aaron,

thanks for your reply.

Below you will find an export of the desired registry key. Don't wonder because of the Wow6432Node. Just to explain, it is the key for 32bit applications on 64bit operating Vista.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\vsto runtime Setup]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\vsto runtime Setup\v9.0.21022]
"Install"=dword:00000001
"SP"=dword:00000000
"MSI"=dword:00000001

Remembering the custom actions of the MSI setup project from the article mentioned in my first post I now understand why this setup is not called.

But I have a new information concerning my first post. A few more tests on virgin Vista machines did not result in errors as described above. But after uninstallation of VSTO runtime the keys shown above seem to remain in registry. I additionally modified the setup project not to search for the registry keys shown above but to search for VSTO runtime component id (AF68A0DE-C0CD-43E1-96DD-CBD9726079FD). So this is the same procedure as searching for Office PIA and so on. But this setup also fails. That seems to me that many registry keys will remain on the target system when uninstalling the VSTO runtime.

Well, these are are the information I can provide.

Any ideas?

Mõbius

Answer 3

Hey Mõbius,

I wanted to make sure, by you confirming the presence of our setup registry keys, but this is a bug we discovered recently with our uninstallation of VSTO runtime SP1.

I believe there is a help article in progress or already available and I will chase it up and post back here if I can find it.

If you uninstall VSTO runtime SP1 from the Add/Remove Programs (ARP) dialog then the original RTM registry keys are not correctly removed. This then interferes with the bootstrapper which relies purely on these registry keys to identify if VSTO runtime is installed. As you discovered the bootstrapper identifies that the RTM version of the VSTO runtime is installed and proceeds to install SP1. When SP1 attempts to install it fails due to RTM not being on the machine.

There are a few workarounds at various stages:

1. Install VSTO runtime manually before running the bootstrapper - the redist install does not rely on this registry key
2. Delete the entire key HKEY_LOCAL_MACHINE\SOFWARE\Microsoft\vsto runtime Setup before running the bootstrapper
3. To avoid the registry keys hanging around after uninstall of VSTO runtime SP1 do not uninstall from ARP directly. Instead go to ARP and click the "View Installed Updates" link. Locate VSTO runtime SP1 and uninstall the update. This will uninstall VSTO runtime SP1, remove the SP1 setup keys and leave the RTM version standing. Then go back to the regular program list in ARP and uninstall VSTO runtime. This will then uninstall RTM and its associated setup keys in the registry.

Cheers,
Aaron

Answer 4

hi Aaron,

that Help article is here: Troubleshooting Office Solution Deployment (2007 System).

Visual Studio Tools for Office 3.0 Service Pack 1 Runtime Does Not Re-Install

When you use the Setup.exe to re-install the Visual Studio Tools for Office 3.0 Service Pack 1 (SP1) runtime on a computer that previously had the Visual Studio Tools for Office 3.0 SP1 runtime installed, the installation may fail. To fix this error, delete the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\vsto runtime Setup\] registry key and run the VSTO 3.0 SP1 installer again.

Answer 5

Thanks Mary, was about to send you an email about it :D

Answer 6

Hi,

and thank you for your replies.

I just tested your workarround #3 and uninstalled the updates before uninstalling VSTO runtime. After this I successfully installed my AddIn.

Well, I did not know that I have to explicitely uninstall the updates before but I never stop learning.

Thanks a lot

Mõbius

Answer 7

I have just posted an article on the VSTO blog outlining a more elegant remedy for this problem. You can find it here.