Creating a (ClickOnce) setup for VSTO Outlook Add-in

Question

So I created an Outlook Add-in and used the click-once setup to deploy it.

The setup runs fine when the user is administrator, but otherwise: no go.

Running the setup with "run as..." and logging in as admin works, but than the add-in is installed under the admin, not the current user. The addin doesn't show up in outlook.

I tried following this guide: http://blogs.msdn.com/mshneer/archive/2008/04/24/deploying-your-vsto-add-in-to-all-users-part-iii.aspx

But I get stuck at part I: http://blogs.msdn.com/mshneer/archive/2007/09/04/deploying-your-vsto-add-in-to-all-users-part-i.aspx

I follow the examples and start excel as described:

Now start Excel application. Examine the registry keys in HKCU hive e.g. you will find two interesting registry keys that appear under your HKCU hive:

• HKCU\Software\Microsoft\Office\TestKey registry key containing registry value TestValue
• You now also have HKCU\Software\Microsoft\Office\12.0\User Settings\TestPropagation registry key with Count value set to 1

But on my machine, the keys are not created... What can I try next?

Answer 1

I haven't done this in a few years, but from memory office addins get "registered" like this:

1. put files in the right place
2. register .NET COM object which represents your addin
3. put registry entries under Microsoft\Office\Addins to tell office to load your COM object.

If my thinking is correct, the problem will be that you need to register the COM object. Registering COM objects is a per-machine action and hence requires admin privileges.

You'll be able to see if this is indeed what's happening. Your registry key under the office addins one will be called something like MyAddin.Connect. You can then search under HKEY_CLASSES_ROOT for MyAddin.Connect and it should be present when you run the install as admin, and not present when running as per-user.

If it is this, you can get around it by doing a per-user registration of the COM object, but this is a bit painful.

Things may be easier these days, but when I had to do it, you used a utility called RegCap.exe to capture the registry entries associated with the COM object into a .reg file, then modify the .reg file with a text editor to replace HKLM with HKCU, then instead of registering the COM object, you load this .reg file.

Answer 2

Just to be clear, you are adding the registry keys to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings"

And they are still not appearing in HKCU\Software\Microsoft\Office\ ?

I assume you must be running a 64bit os?

If so the fix is simple, try this instead

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wow6432Node\Microsoft\Office\12.0\User Settings\TestPropagation] "Count"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wow6432Node\Microsoft\Office\12.0\User Settings\TestPropagation\Create\Software\Microsoft\Office\TestKey] "TestValue"="Test"

Notice the path to the key is under the Wow6432Node key. It must be under there or it will not work on a 64 bit OS.

Answer 3

You need to use shared add-in instead of VSTO add-in if you want to install your Outlook Add-in to all-users. VSTO add-in is per-user basis rather than per-machine, so for standard users you have to temporally give user the local-administrator authorization to install it.

Answer 4

What version of Office are you targeting with the add-in, and what version of the .NET Framework are you targeting? Also, what version of Visual Studio are you using?

This should work; I have two Office add-ins in production now that are deployed with ClickOnce.

The article you listed is about installing for all users. That does not use ClickOnce, and is irrelevant to your case.

I can give you some steps for deployment after I find out what versions you're using/targeting. :-)

Answer 5

If I understand the question correctly, let me describe your scenario: the clickonce app will be installed for all users and therefore must initially be run through a deployment mechanism that has admin privileges in order to write keys to HKLM. After that point, the standard user logs on, Microsoft Office copies HKLM keys to HKCU on startup and the add-in is run under the context of the standard user for any user on that machine thereafter.

If all attempts are exhausted on getting Office to use HKLM keys to copy over to HKCU when a user starts Office, I would throw together a vbs script and reg file, place the vbs script in the all users startup file (using some admin level deployment tools) and manage the creation of the special keys in HKCU myself without Office's help. The vbs script file would silently run regedit to place the appropriate keys in HKCU when a user logs in.

This is similar to how we manage WordPerfect in my office.

Update: Use hotfix KB976477 to address the issue.

Answer 6

1. Create a local admin account say TESTAccount.
2. Install the addin using click once for that user.
3. Re-login as administrator and copy TESTAccount into default user.

Now so when anybody logs into the machine a new profile would be created for them from default profile and so will have the addin installed.