views:

3110

answers:

6

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?

A: 

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.

Orion Edwards
This is no longer applicable. They added ClickOnce deployment of Office Add-Ins in .NET 3.5 and it's much, much easier to install them. No COM registration required on your part.
RobinDotNet
A: 

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.

Jake Ginnivan
Well, I'm using Vista Business 32bit. And indeed, the keys don't appear in HKCU\Software\Microsoft\Office\ when I start office. Although the article says they should.Any other suggestions?
Ward Werbrouck
How are you adding the keys to the registry?If you have user account control and you are installing from a non elevated process it may be virtualising the key.Check if the key is in:HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software\Microsoft\Office\12.0\User Settings
Jake Ginnivan
You can't write to HKLM in a CLickOnce deployment. IT doesn't have the privileges.
RobinDotNet
A: 

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.

Mike Regan
Since we want to create an installer we can give our customers, the vbs solution doesn't look like the right thing to do
Ward Werbrouck
Sorry, that's completely backwards. ClickOnce applications are only installed on a per-user basis.
RobinDotNet
RobinDotNet - The first paragraph is my attempt to paraphrase the question and its intent (and not part of my answer). Yes, thank you, I understand ClickOnce and per-user installs.
Mike Regan
Ok, just checking. Lots of people don't get that for some reason.
RobinDotNet
A: 

I didn't work for me ( I 'm using windows server 2008 64-bit) I tried Jake Ginnivan solution but it didn't work again :(

Any solution ?

farzad
Please don't add comments as answers
MPritch
A: 

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.

Bolu
A: 

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. :-)

RobinDotNet