0

I've been trying to do this seemingly simple task for over a day now. So I would appreciate if someone can shed some light on what am I missing here?

I wrote an Outlook 2007 add-in (in Visual Studio 2008, C# project) and now I'm trying to write an MSI installer for it (using WiX). The installation process also requires VS Tools For Office Runtime to be installed, which I do separately.

Then, the following are registry keys, that I've been testing it with for the current user. Using WiX mark-up:

  <Component Id="RegistryRegAddin" Guid="{GUID}">
    <RegistryKey Id="RegKey_AddIn" Root="HKCU" Key="Software\Microsoft\Office\Outlook\Addins\$(var.ProductThis)" ForceCreateOnInstall="yes" ForceDeleteOnUninstall="yes">

      <RegistryValue Type="string" Name="Description" Value="$(var.AppDescr)" />
      <RegistryValue Type="string" Name="FriendlyName" Value="$(var.ProductThis)" />
      <RegistryValue Type="integer" Name="LoadBehavior" Value="3" />
      <RegistryValue Type="string" Name="Manifest" Value="[INSTALLFOLDER]AddInName.vsto|vstolocal" />

    </RegistryKey>
  </Component>

So this works just fine for the current user.

But now I'm trying to change it so that the add-in is installed for all users. I modified HKCU to HKLM in the WiX registry markup above. But in that case, the MSI installs fine (on a 32-bit Windows 7 Pro), but my add-in doesn't load into Outlook.

Why!????

Then if I go in Outlook to Tools -> Trust Center -> Add-ins -> my add-in is in the "Inactive Application Add-ins" but when I try to check it to enable it, Outlook shows this message:

The connected state of Office Add-Ins registered in HKEY_LOCAL_MACHINE cannot be changed.

enter image description here

Argh!!!!

c00000fd
  • 20,994
  • 29
  • 177
  • 400
  • I haven't dealt with addins for years, so there might be more wrong here. However, regular users will not have write access to HKLM. You could try to add access for regular users to the key. [How-to video](https://www.youtube.com/watch?v=M1l5ifYKefg) (hope that video is clear, quick search - I would just add "users"). – Stein Åsmul Jun 28 '20 at 10:54
  • I'll just add [this link to the larger topic of how to get applications to run that require admin access](https://stackoverflow.com/a/50588465/129130) (erroneously so by design). Not 100% related, but maybe that is a useful thing to skim. – Stein Åsmul Jun 28 '20 at 10:59

2 Answers2

0

I think this is specific to Office 2007. Try adding the following code fragment to your code:

<Component Id="EnableLocalMachineVSTO" Permanent="yes">
  <Condition>ALLUSERS=1</Condition>
  <RegistryKey Root="HKLM" Key="Software\Microsoft\Office\12.0\Common\General">
    <RegistryValue Name="EnableLocalMachineVSTO" Value="1" Type="integer" KeyPath="yes" />
  </RegistryKey>
</Component>

The EnableLocalMachineVSTO is the keyword you can put in the search box to learn more. This is one of the common issues with "my add-in works when installed as current user but doesn't when installed as local machine", AFAIK.

Nikolay
  • 10,752
  • 2
  • 23
  • 51
  • Yes, except that this needs KB976811 that is no longer available. – c00000fd Jun 28 '20 at 21:55
  • @c00000fd As of my understanding, this KB just puts that key to the registry for you. If you do it with the installer, isn't it the same thing? – Nikolay Jun 28 '20 at 22:32
  • Hmm. I said it because I tried and it didn't work with just the registry key alone. – c00000fd Jun 29 '20 at 01:27
  • @c00000fd did you verify that the key was actually added by the installer? Maybe it's added to x64 section and you need to add x86 (or vice versa?) I would try adding it manually, and then installing. – Nikolay Jun 29 '20 at 11:16
  • I did it manually through regedit. And as I said in my OP, I'm testing it on a 32-bit Windows 7 Pro. – c00000fd Jun 29 '20 at 19:26
0

But in that case, the MSI installs fine (on a 32-bit Windows 7 Pro), but my add-in doesn't load into Outlook.

There are multiple reasons why your add-in may not be loaded. Among them you can find the following points and possible diagnostic ways:

  1. Make sure all the prerequisites were installed correctly.
  2. No exceptions are thrown at startup. Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in, the application might have hard disabled or soft disabled your VSTO Add-in. Hard disabling can occur when a VSTO Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO Add-in is executing. Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing. When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again.
  3. Use the Fuslogvw.exe utility for checking whether the right assemblies are loaded. See Assembly Binding Log Viewer for more information.
  4. The MSI engine failure. Try to take a look at the MSI log files.

You may also find a similar case described on the VSTO AllUser addIn fails to load on several clients page.

Eugene Astafiev
  • 47,483
  • 3
  • 24
  • 45