Welcome to MSDN Blogs Sign in | Join | Help

Misha Shneerson

VSTO internals and the little things about CLR, COM, Visual Studio and more ...
Deploying your VSTO Add-In to All Users (Part I)

VSTO Add-Ins aka Managed Office Add-Ins have a major deficiency on the deployment side. Putting it simple, Microsoft has only provided guidance how to deploy these Add-Ins on per-user basis. Machine wide deployment has been our Achilles heel. In this post I will try to explain how this limitation can be worked around.

First, let's start with some background information.

Office 2007 has added built-in support for managed Add-Ins. Office applications use a Manifest registry value to differentiate between traditional COM Add-Ins and managed Add-Ins. This value can be found under HKCU\Software\Microsoft\Office\<App>\AddIns\<AddInName>.

Unlike traditional COM Add-Ins which can be deployed to all users on a machine by registering those under HKLM\Software\Microsoft\Office\<App>\AddIns, managed Add-Ins can only be registered in HKCU registry hive (those registered under HKLM will be ignored).

It is pretty easy to create a setup package that writes registry keys into HKCU for the user invoking the setup. But setup program duplicating same sets of registry keys for every user on this particular machine requires quite advanced skills in Win32 API. Slightly more advanced skill is required to create a setup that will write those registry entries into HKCU hives of future users of the machine (this is because "template hive" is stored in C:\Documents and Settings\Default User\ntuser.dat file and is not a part of live registry, see more details at Raymond Chen's post on the topic).

There is a solution though and it is reasonably easy one. The trick is to use an internal Office mechanism for propagating registry keys from HKLM to HKCU that is performed during startup of every Office application.

For Office 2007 the magic is in the keys located under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings. If you have an existing installation of Office 2007 you can examine the content of this registry key you will soon find out that it contains a seemingly random collection of sub-keys which all in turn have either Create or Delete sub-keys. The Create/Delete keys (which are essentially Copy/Delete instructions), in turn, have sub-keys that look like complete registry keys on their own!

What we are looking at is the HKLM-to-HKCU propagation mechanism that can be completely controlled from within the registry itself. Let's examine more closely how this mechanism is working. To start I would suggest the following exercise – copy and paste the below lines into a Notepad application, save the file as testpropagation_create.reg file and run this file to put the corresponding registry keys and values into your registry. Notice that you are adding registry keys to HKLM hive.

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

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

Now, let's see how we can delete a registry key using similar mechanism. Below is the new registry script for you to run (copy&paste these lines into testpropagation_delete.reg)

Windows Registry Editor Version 5.00
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\TestPropagation\Create] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\TestPropagation]
"Count"=dword:00000002
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\TestPropagation\Delete\Software\Microsoft\Office\TestKey]

I highlighted the changes I made from the testpropagation_create.reg file. In this script we first remove the TestPropagation\Create registry key that we added earlier – notice the hyphen at the beginning of the line which indicate that this is a "delete" instruction. We also changed the Count value to 2 – in order for the instruction to execute we need to make sure that HKLM's Count value is different from HKCU's Count value. Next, Software\Microsoft\Office\TestKey is now placed under TestPropagation\Delete key – this to instructs Office to delete the registry key rather than create it.

After executing testpropagation_delete.reg file and starting Excel you will notice that:

  • HKCU\Software\Microsoft\Office\TestKey registry key is now gone
  • HKCU\Software\Microsoft\Office\12.0\User Settings\TestPropagation registry key has a Count value set to 2

Now, we have seen how Office's registry propagation mechanism works. It now becomes pretty clear how it is possible to take advantage of this behavior in your Add-In's setup. In my next post I will explain how we would go about building a custom action for VSTO 2005 SE Add-In setup package that will use this technique for machine-wide Add-In deployment.

Posted: Tuesday, September 04, 2007 6:08 PM by Misha Shneerson

Comments

Samuel Jack said:

Is it possible to do this same trick with Office 2003?

If not, is there any other way of achieving machine wide deployment?

# September 5, 2007 11:04 AM

Misha Shneerson said:

Office 2003 does not have a native notion of managed add-ins. So all COM add-ins (even VSTO add-ins for Office 2003) can be registered under HKLM hive (e.g. HKLM\Software\Microsoft\Office\Excel\AddIns\MyAdd) which will work for machine-wide deployment - and this is how machine wide deployment of add-ins has been done in the past.

I do not have an installation of Office 2003 readily available right now but you can try and see whether it will work - just modify the registry scripts by substitugin "12.0" to "11.0" and see whether the rest of the steps will work.

# September 5, 2007 12:23 PM

Misha Shneerson said:

In this post I am going to discuss how the observations made in the previous post can be incorporated

# September 6, 2007 2:57 AM

Ken McCormack said:

Hi Misha

Nice post... I've just posted on the MSDN forum looking for assistance on this topic.  

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2128477&SiteID=1&mode=1

I think the walkthroughs need to incorporate this!

Ken

# September 12, 2007 2:46 AM

Jie Wang said:

For Chinese readers, there is a translated version (Simplified Chinese) of this article at: http://blog.joycode.com/vsto/archive/2007/09/15/108493.aspx

# September 14, 2007 12:36 PM

Jie Wang said:

As for x64 OS, the registry keys mentioned in this article should be moved to Software\Wow6432Node, otherwise it will not work.

# September 14, 2007 12:40 PM

Misha Shneerson said:

Jie,

To address 64-bit OS you can just mark the Custom Action assembly as 32-bit platform code.

# September 14, 2007 6:33 PM

Jie said:

I mean in order to do the reg file test on x64 Windows, we'll have to modify the reg file (Wow6432Node) mentioned above. :)

# September 15, 2007 11:52 AM

Ben Lait said:

Hi Misha,

I have an outlook 2003 add-in developed using VSTO 2005 SE under Visual Studio 2005. I managed to deploy version 1.0 of this application using GPO. I confronted the issue that GPO installs as an admin account, so normal users could not run. I resolved this by moving all of the registry keys from the HKCU hive to the HKLM hive. I also removed the manifest key under Software\Microsoft\Outlook\Addins\<add-in ID>, as directed in various forums I read.

This all worked well and version 1.0 is now live. I have subsequently developed v1.1 and would like to deploy this in the same way if possible. Unfortunately, I canot create a setup that will generate a working MSI. The MSI's can be installed by GPO, but normal users see no add-in in the COM add-ins list or on screen. I believe that I have followed all of the same steps as before, but cannot create an "all user" build any more.

So when at the end of "Deploying your VSTO Add-In to All Users (Part I)" you mention "In my next post I will explain how we would go about building a custom action for VSTO 2005 SE Add-In setup package that will use this technique for machine-wide Add-In deployment" I was very interested. But the part II post seemed to be orientated towards Office 2007. Or was it more generic that I thought?

Could you please give a detailed method for machine-wide add-in deployment for outlook 2003 applications (ideally with any code in VB). That would be really appreciated.

# October 3, 2007 1:13 PM

Misha Shneerson said:

Ben,

The article applies to Office 2007. As you have already noticed, you just need to make sure your add-in can be installed to "all users". To achieve this just make sure that "InstallAllusers" setting for your setup project is set to True - you can find this setting in the "Properties" window once you select the setup project node in the Solution Explorer.

# October 5, 2007 12:12 AM

BobC said:

I have verified an Office 2003 All Users install based on moving the registry to the HKLM hive.

From Misha's post on Sept 5's post...Quote

Misha Shneerson said:

Office 2003 does not have a native notion of managed add-ins. So all COM add-ins (even VSTO add-ins for Office 2003) can be registered under HKLM hive (e.g. HKLM\Software\Microsoft\Office\Excel\AddIns\MyAdd) which will work for machine-wide deployment - and this is how machine wide deployment of add-ins has been done in the past.

I do not have an installation of Office 2003 readily available right now but you can try and see whether it will work - just modify the registry scripts by substitugin "12.0" to "11.0" and see whether the rest of the steps will work.

September 5, 2007 12:23 PM

# October 6, 2007 4:27 PM

Namita said:

I am unable to see any KHCU entries after starting excel application, but the HKLM entries are present if i run the testpropagation_create.reg file. I have add-in installed in all of the Office application. Any reason why i might not be seeing the entries?

Please help as this is something i am really stuck on for sometime now!

Thanks

# October 26, 2007 3:45 AM

John said:

Like Namita I am finding that the HKCU entries are not being created after opening Excel or any Office application for that matter.

Any suggestions would be greatly appreciated.

# November 7, 2007 1:14 PM

Misha Shneerson said:

John, Namita,

You are running Office 2007, right?

# November 7, 2007 1:22 PM

pedramr said:

For thoes of you who have difficulty in getting this to work, try the following text (copy and paste it inot a .reg file and run it):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\TestPropagation]

"Count"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\TestPropagation\Create\Software\Microsoft\Office\TestKey]

"TestValue"="Test"

This will work

# November 8, 2007 4:01 PM

pedramr said:

(Removed the unnecessary line breaks)

For thoes of you who have difficulty in getting this to work, try the following text (copy and paste it inot a .reg file and run it):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\TestPropagation]

"Count"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\TestPropagation\Create\Software\Microsoft\Office\TestKey]

"TestValue"="Test"

This will work

# November 8, 2007 4:02 PM

We did start the fire (sorry Billy)

said:

Eine wesentliche Limitierung von managed Office 2007 Add-Ins ist die Beschränkung auf eine per-User -

# November 27, 2007 5:43 AM

Noticias externas said:

Eine wesentliche Limitierung von managed Office 2007 Add-Ins ist die Beschränkung auf eine per-User

# November 27, 2007 6:44 AM

Christopher Painter said:

This type of per-user registry installation is actually possible with windows installer by taking advantage of the resilency capabilites.

Unfortuantly it's not an easy thing to uninstall this data for all users on the machine.  It used to be possible to fire up a custom action that enumerated the user profiles, load each hive and delete the reg key.  But now in Vista the MSIServer service lacks the SeBackup permission so it can't be done.

Does anyone have any ideas on how to complete this pattern to support uninstall?

# January 19, 2008 11:04 PM

Christopher Painter said:

Does the number really have to be incremented?  I'm trying to figure out a way to do this in Windows Installer without any custom actions at all.

I think the requirement is really just a count (revision) that is different then the most recent published count or any other previously published count that a users profile may be stuck at.

Is this documented anywhere?

# January 23, 2008 8:38 PM

Misha Shneerson said:

Christopher,

For an internal Office registry propagation solution this is documented pretty well - right here, on this blog :) But again this documentation has very big disclaimer "USE ON YOUR OWN RISK". This is just something we stumbled upon and decided to let other people know of it (more like as a service to the community).

You are right, the counters just need to be different. Incrementing the counter is just an easy way to make sure the value is different from the one stored in any of the HKCU hives. Then there is also a repair scenario ... in this case the counter should probably be assigned some random value.

It would be nice to have this working w/o any custom action at all but my knowledge of Windows Installer is not enough to make this happen. If you come up with a solution and do not mind sharing - everyone would benefit.

# January 24, 2008 3:29 AM

Joe said:

Hey Misha,

I have a VSTO addin for OL2007 implemented with VS2005 SP1 and add-in seems to be working like a charm exept for a vista machine with OL2007, when I debugged the problem, it was failing to read and write to the registry with very straight forward commands like:

Registry.SetValue("HKEY_LOCAL_MACHINE\\SOFTWARE\\ConverTec\\olCRMSetup", "InstallPath", path,RegistryValueKind.String);

The above code was in install class, so I tried to do CAS settings before executing that like to give full trust to the assembly, but I was disappointed and again could not write or read from registry.

Event when it reaches to loading the addin to OL2007, it always fails on reading registry values.

So I created a windows application that have only one line of code that reads from registry and tried it on the vista machine and the application could read from registry with no troubles at all!!!!!!!!

Does that makes any sense to you? do you know something that you may share?

Thank you very much in advance.

Joe

# January 29, 2008 10:07 AM

Christopher Painter said:

Joe-

Am I correct in assuming that you packaged your installer class CA using a Visual Studio Deployment Project?   If so, that's your problem right there.    VDPROJ ( which sucks ) sets deferred all CA's to run deferred ( rollback, install, commit, uninstall ) with impersonation turned on instead of off.  This means that the CA runs as the logged on user, not the system context.       On XP this went unnoticed when installing as an administrator.  On Vista if your client side isn't elevated ( as it shouldn't be ) then you get the standard user UAC token and it'll all fail.

Checkout:

http://blogs.msdn.com/mwade/archive/2007/06/01/moving-into-del-boca-vista-with-the-costanza-s.aspx

and follow the link to http://blogs.msdn.com/astebner/archive/2007/05/28/2958062.aspx

And feel free to visit my blog aswell.

# January 29, 2008 11:55 AM

geetha said:

I placed the exactly what u said above  for vista but its not installing for office 2007 ,getting an error of runtime error occured during loading of the com addini.e addinloader.dll

# February 20, 2008 4:11 AM

Visual Studio 2008: Microsoft Visual Studio Tools for Office said:

There are many resources to learn about Visual Studio Tools for Office, and they are scattered through

# February 22, 2008 11:19 AM

Noticias externas said:

There are many resources to learn about Visual Studio Tools for Office, and they are scattered through

# February 22, 2008 12:07 PM

DarinHIggins said:

Could somebody explain to me +why+ the whole concept of simply defining the addin in either HKLM or HKCU was dropped in favor of having each office app check for these reg entries each time it loads and then copying them down to the HKCU hive?

How on earth is that +better+ or even slightly improved? I'm just not seeing it. It can't be a security thing. So what then?

This just flat doesn't make sense.

Just my 2c

# April 4, 2008 3:31 PM

Misha Shneerson said:

Darin,

One mechanism was not replaced with another, The registry propagation is an old internal feature of Office.  

So what did happen here? For some reason someone in Office decided that allowing add-ins in HKLM is just too much pain for Office in terms of manageability. The problem is they did not realize they should have a different mechanism in place (the truth to be told they believed there is a different and better mechanism - just did not bother to check). And until they do realize the replacment - you can use this workaround.

# April 4, 2008 9:11 PM

Jayadev said:

Misha,

I am having a problem with Add Ins. I have a one click set up file to install an add ins names 'TestXL'.

It is developed in VS2008 and Developer system has Excel 2007.I'm able to install this in Developer system.

Now I'm tring to install that into another system which has Excel2003. The Name of the Add Ins comes in the list i can able to select it. But the issue is it is not appearing in the menu.

What would be the reason ..

Can you please gimme a solution

Thanks

# April 19, 2008 6:22 AM

Misha Shneerson said:

Jayadev,

Office 2003 does not support VSTO 3.0 - which is the VSTO runtime with ClickOnce support. For Office 2003 you need to use an Office 2003 add-in and explore MSI-based deployment options - see this post for more details on what is involved - http://blogs.msdn.com/mshneer/archive/2006/01/05/deployment-articles.aspx

# April 20, 2008 11:48 PM

Jayadev said:

Misha,

What about VSTO 2.0?

# April 21, 2008 2:10 AM

Misha Shneerson said:

Jayadev, Office 2003 does support VSTO 2.0  based solutions. When you use "Office 2003" flavors of projects in VS 2008 - you will essentially create a VSTO 2.0 solution. The post I referred to points to the articles about deployment of such solutions.

Hope this helps,

Misha

# April 21, 2008 2:17 PM

Jayadev said:

Misha,

Thank you for your post.

# April 22, 2008 1:08 AM

Misha Shneerson said:

This post is both the continuation of part I and part II installments but it also addresses new product

# April 24, 2008 7:17 PM

Jayadev said:

While i try to give full trust to the assembly i'm getting an error like this. Can you tell me what is the reason for the same.

************* Exception Text **************

System.Security.SecurityException: Hash for the assembly cannot be generated.

  at System.Security.Policy.Hash.get_RawData()

  at System.Security.Policy.Hash.get_SHA1()

  at Microsoft.CLRAdmin.CFullTrustWizard.CreateCodegroup(PermissionSet pSet, Boolean fHighjackExisting)

  at Microsoft.CLRAdmin.CFullTrustWizard.TryToCreateFullTrust()

  at Microsoft.CLRAdmin.CFullTrustWizard.WizNext(Int32 nIndex)

  at Microsoft.CLRAdmin.CWizardEngine.onNextFinishClick(Object o, EventArgs e)

  at System.Windows.Forms.Control.OnClick(EventArgs e)

  at System.Windows.Forms.Button.OnClick(EventArgs e)

  at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)

  at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)

  at System.Windows.Forms.Control.WndProc(Message& m)

  at System.Windows.Forms.ButtonBase.WndProc(Message& m)

  at System.Windows.Forms.Button.WndProc(Message& m)

  at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)

  at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)

  at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

The Zone of the assembly that failed was:

MyComputer

# April 27, 2008 3:11 AM

Jayadev said:

Hi Misha,

I’m facing problem in deploying the add in setup.

When I run the application using Visual Studio 2005, Add-in is getting added to my excel menu. but when I try installing it using the setup file it is not getting added.

Can you halp me!

Thanks

# April 27, 2008 5:36 AM

See what I see. said:

I got ahead of myself and thought it was one week later than it really is (sort of good because I was

# April 29, 2008 9:18 PM

Hu Mi? said:

Jayadev,

1.  You're getting the 'System.Security.SecurityException: Hash for the assembly cannot be generated.' error because your assemblies aren't strongnamed.

2. Use the dotNet 2.0 'caspol' command through a 'Run Exe' custom action to give 'FullTrust' to your assemblies so the add-in will be loaded.

'caspol' allows you to give trust to your assemblies besides just using 'strongname' on them (for example, you can give trust to the assemblies' location so anything in that location will be trusted).    

# May 1, 2008 5:48 PM

Open XML, VSTO, Deployment, .NET und anderes said:

Das Office 2007 Security Modell erlaubt es nicht, unter HKLM registrierte Managed Add-Ins zu verwenden.

# May 9, 2008 10:20 AM

Andrew Coates ::: MSFT said:

While the default mechanism for deploying VSTO v3 Add-Ins is ClickOnce, there there's now also a documented

# May 15, 2008 10:04 PM

mathjcb said:

Hi Misha ,

Thanks for the post , we have issue with our add-in working just for the installed user . To fix the problem we are planning to push a registry patch to perform this forward propagation .

Before doing an enterprise level push ,wanted check if this could cause any registry screw ups , will it be compatibile with future service packs? . is this recommended by Microsoft  ?

Thanks !

# July 14, 2008 12:30 PM

Misha Shneerson said:

Matchjcb,

I can not make any guarantees to compatibility with future service packs since this is an undocumented feature in Office. It works though but as far as Office is concerned - they have not promised anything here.

# July 15, 2008 1:38 AM

Andrew Coates ::: MSFT said:

I had a great time over the last couple of days hanging out with Christen Boyd and some of the other

# July 26, 2008 10:54 AM

Tom said:

Hi This works fine for me. But when i uninstall the component the reg keys in de HKLM are removed. But the settings in HKCU are stil there. This causes outlook to search for an add-in witch issnt there.

I did read about an other key  named: "delete" instead of "create" wich is also located in "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\User Settings\TestPropagation\Delete\". But does this key always delete the keys or only when i have uninstalled my component?

# July 29, 2008 9:32 AM

Misha Shneerson said:

Hello Tom,

This and the part II (http://blogs.msdn.com/mshneer/archive/2007/09/05/deploying-your-vsto-add-in-to-all-users-part-ii.aspx) both cover the Delete reg key. On uninstall, Create reg key is removed and Delete reg key is added to the HKLM. This causes the HKCU keys to be delete.

The downside of this, of course, is that this Delete key is left on the machine after the uninstall.

# July 29, 2008 2:20 PM

Eva said:

Thanks for this post. It is great! Helped me a lot.

# August 14, 2008 4:43 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker