Deploying your VSTO Add-In to All Users (Part I)


UPDATE March 11, 2010: Office 2010 does support deploying managed add-ins to HKLM which makes the below article a little bit outdated nowdays. There is also an optional download for Office 2007 containing the same fix. Check this article out for more details.


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.

Comments (78)

  1. Samuel Jack says:

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

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

  2. 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. HKLMSoftwareMicrosoftOfficeExcelAddInsMyAdd) 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.

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

  4. 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

  5. Jie Wang says:

    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

  6. Jie Wang says:

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

  7. Jie,

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

  8. Jie says:

    I mean in order to do the reg file test on x64 Windows, we’ll have to modify the reg file (Wow6432Node) mentioned above. šŸ™‚

  9. Ben Lait says:

    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 SoftwareMicrosoftOutlookAddins<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.

  10. 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.

  11. BobChauvin says:

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

  12. Namita says:

    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

  13. John says:

    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.

  14. John, Namita,

    You are running Office 2007, right?

  15. 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_MACHINESOFTWAREMicrosoftOffice12.0User SettingsTestPropagation]

    "Count"=dword:00000001

    [HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice12.0User SettingsTestPropagationCreateSoftwareMicrosoftOfficeTestKey]

    "TestValue"="Test"

    This will work

  16. (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_MACHINESOFTWAREMicrosoftOffice12.0User SettingsTestPropagation]

    "Count"=dword:00000001

    [HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice12.0User SettingsTestPropagationCreateSoftwareMicrosoftOfficeTestKey]

    "TestValue"="Test"

    This will work

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

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

  19. Christopher Painter says:

    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?

  20. 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?

  21. 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.

  22. Joe says:

    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

  23. 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.

  24. geetha says:

    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

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

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

  27. DarinHIggins says:

    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

  28. 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.

  29. Jayadev says:

    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

  30. 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

  31. Jayadev says:

    Misha,

    What about VSTO 2.0?

  32. 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

  33. Jayadev says:

    Misha,

    Thank you for your post.

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

  35. Jayadev says:

    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

  36. Jayadev says:

    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

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

  38. Hu Mi? says:

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

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

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

  41. mathjcb says:

    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 !

  42. 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.

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

  44. Tom says:

    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_MACHINESOFTWAREMicrosoftOffice12.0User SettingsTestPropagationDelete". But does this key always delete the keys or only when i have uninstalled my component?

  45. 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.

  46. Eva says:

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

  47. alan glover says:

    Misha,

    I don’t understand your response to the question about Office 2003. You say:

    "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. HKLMSoftwareMicrosoftOfficeExcelAddInsMyAdd) 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."

    The first paragraph seems to say you don’t need to do it but the second paragraph implies that you do??

    I recently discovered this article from January 2008:

    http://msdn.microsoft.com/en-us/library/cc136646.aspx#AutoDeployVSTOse_InstallingtheAddinforAllUsers

    Which states:

    "For Outlook 2003, it is a simple matter of creating the appropriate registry entries in the HKEY_LOCAL_MACHINE hive in the Windows registry instead of the HKEY_CURRENT_USER hive. The MyOutlookAddInSetup project that Visual Studio generates already creates the registry entries that you need. All you need to do is move the settings from HKEY_CURRENT_USER to HKEY_LOCAL_MACHINE."

    I’ve modified my set-up project to install to HKLM and it does that OK. Outlook 2003 just ignores it and my add-in does not appear.  Despite the pages and pages of stuff on the web about deploying Office Add-ins I still can’t find a simple description of deployment for "All Users" that works for Outlook 2003. I can only get it to work if I deploy to HKCU but that is not what my client needs.

    As you can tell I’m getting quite desparate as a very large sale and 6 months of development are at risk. Can you give me any advice?

  48. Why do we need to alter the &quot;SetSecurity&quot; and the &quot;Setup&quot; project? I sincerely suggest

  49. Seba says:

    Hi alan:

    For me this works for Office 2003. I just move alle the reg key from HKCU to HKLM in VS and the addin gets installed for all user. For Office 2007 this doesn’t work. But with Misha’s solution deployment for Office 2007 works great. Thanks a lot Misha !!!

    Greetz

  50. arun says:

    Good Article.

    Thanks

    Aarun

  51. David says:

    Hi Alan and all,

    we have the same problem when installing an VSTO 2005 SE Outlook 2003 add-in on a Terminal Server. We moved the keys (in the setup project) from HKCU to HKLM (as said by Seba) and this works when installing it on Windows XP or Windows Server 2003. But it doesn’t seem to work on a Windows Server 2003 which functions as a Terminal Server.

    Did you or anyone else have this problem? There are some sources on the Internet ‘complaining’ that installing a VSTO 2005 (SE) Outlook 2003 add-in does not work on a terminal server… but there are no solutions to it?

    greetings,

    David

  52. Prabhakar says:

    Hi Misha,

    I have created a Visual  Studio Word Add-in in Visual Studion 2005

    and created a set up

    ‘Custom Word addin’= is my Word add-in

    During installation of ‘Custom Word addin’, screen ‘Select installation folder’ gives the options ‘Everyone’ and ‘Just me’. When ‘Just me’ is selected, the installation gives a good result. When ‘Everyone’ is selected, the ‘Custom Word addin’modifications are not shown in the Word addin after installation.

    I have run the testpropagation_create.reg

    but i am unalbe to acess the Add-in in the another user

    can u please help me i am stuck in this for the past 2 days

    Thanks

    Prabhakar

  53. Prasanna says:

    Hi Misha,

    I’ve creaetd a simple Word 2007 Addin in Visual Studio 2008 VSTO 3.0 and create a msi installer with custom actions to increment the count value in the the registry key. Everything is working perfectly except when I uninstall the addin the uninstaller remove the Count key under [HKLM…MyAddin]. Is there any way no uninstall the addin without removing the Count key.

    Thanks.

    Prasanna.

  54. Prasanna,

    see the second post in the series located here – http://blogs.msdn.com/mshneer/archive/2007/09/05/deploying-your-vsto-add-in-to-all-users-part-ii.aspx

    In particular:

    "Notice that now we need to add a Count value under the MyCompany.MyAddIn key. Using the Registry View to add this value would not work because any registry keys and values added through this view will be removed on uninstall. On opposite, we need Count value not just stay when Add-In is uninstalled, but its value should be incremented.

    To achieve the desired effect we will create a Custom Action that will add Count value or, in case it already exists, we will simply increment its value. "

  55. Jason Drawmer says:

    Hi Misha,

    I am having the same problems as Alan Glover (September 8th 2008).

    I have an add-in created and working fine when registered to HKCU but when I move to HKLM it doesn’t appear. Could this be the Install for all users issue (property in setup project) you mentioned?

  56. Jason Drawmer says:

    Also Misha, I have been attempting to find out about another similar issue through the forums but haven’t got anywhere as of yet.

    I’ve been developing an add-in for an office within a massive organisation. Each employee has a user profile as you might imagine. My issue is that at present if an employee has the add-in installed and moves to a different machine and attempts to install, it won’t allow it because (i can only assume) it thinks the add-in is already installed as it’s in their user registry.

    Will this be solved by moving to HKLM hive does that just copy the registry to the HKCU hive upon launch?

  57. Niklas says:

    Is this also working with Visio 2007? I have a Visio add-in that needs this functionality during installation, but the trick doesn’t seem to work there.

  58. Wamiq Ansari says:

    Hi Misha,

    In my case, after uninstallation process, the addin registry key in HKCU is not removed. However, the Count value in HKCU is updated from HKLM.

    Then I manually updated my addin key (under ‘delete’ key) in HKLM to include all the values from HKCU addin key (e.g. Description, FriendlyName, LoadBehavior, Manifest) and also incremented the Count value in HKLM. After doing this I open MS Word 2007, now the addin key under HKCU still exists but it is empty so my addin does not try to load. The Count value in HKCU is again update to match HKLM.

    Could you tell me if there is something more to it? Should the Office Registry Propagation mechanism work (able to remove registry keys) when the user is a non-admin?

    Thanks for a fabulous article.

    Wamiq

  59. Steven Specht says:

    Misha,

    I’m not seeing the replication happen when Project 2007 is started up.  Everything appears to work fine if Word or Excel is started up, but if Project is the first Office app used then the registry entries are not copied from HKLM to HKCU.

    Since I’m creating a Project add-in, this is problematic.  Any thoughts?

    Steve

  60. Alfred says:

    Hi Mishna,

    works perfectly well for Excel 2007,Word 2007, …

    Unfortunately it does not work for MS Project 2007. MS Project simply does not copy from HKLM to HKCU. Your Addin will be ignored by MS Project until you start Excel or Word.

    Leaves one important question: What if you have installed MS Project 2007 but all other office applications are Office 2003?

    Thanks,

    Alfred

  61. RE: MS Project …. I have received numerous reports that this technique does not work and currently I am trying to figure out what’s going on.

    Meanwhile, another possible technique here is to register a little logon script (under HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun) that will check for your add-in’s registration keys and add those if needed.

  62. Zengfu Xu says:

    Hi, We have a VSTO Add-Ins for Word 2007 installed in a PC with Vista operating system to customise the Word 2007 Fluent Ribbon. It had been working ok but suddenly stop working. I checked the Word option and

    find out that it can not be loaded. The COM add-in appears in the COM add-in list but not in the Active

    Application Add-ins list. I checked the check box for the COM add-in the the COM add-in list. But when I get out and get in again, it becomes unchecked. Can anyone help to solve this problem? Many thanks!

  63. We are currently deploying a VS2008 Office Addin that needs to target systems with possible multiple installations of Office. ie. PowerPoint 2003 and 2007. We have followed the propogation process which works well in 2007 but found we need to move the reg keys for Office 2003 from HKLM to HCUM. If you leave them in HKLM the plugin doesn’t load. Is it possible to set have an option that will allow a wide deployment for Office2003 combined with a propogation technique for 2007?

  64. Nigel says:

    RE: MS Project …. I have received numerous reports that this technique does not work and currently I am trying to figure out what’s going on.

    Meanwhile, another possible technique here is to register a little logon script (under HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun) that will check for your add-in’s registration keys and add those if needed.

    Hi, we are experiencing exactly the same problem. Also many of our clients could be using either Office 2007 or 2003, or Project 2007 or 2003. We are creating an installer that must work for all users on the machine and am wondering what would be the best solution for this scenario?

  65. If you can create a working solution for Office 2003 (which you would register in HKLM) then you can install this solution on Office 2007 and it is supposed to continue working.

    But there is one thing you need to watch out for. In particular, make sure you do not deploy Manifest registry value in HKLMSoftwareMicrosoftOfficeMS ProjectAddins<MyAddIn1> (I think VSTO 2005 SE tools will put this reg value in by default – so just remove it).

    Office 2003 ignores this registry value

    Office 2007 disables the addin if it sees Manifest in HKLM hive

  66. Raghu says:

    we are trying to load Excel 2003 VSTO add-in from a machine which has excel 2007. But we are getting a message ‘Excel 2003 (Version 11.0) is needed to edit this workbook’ and also it shows save/cancel dialog. After the message add-in loads fine. How to get rid off this msg. Excel 2003 add-in should load fine in excel 2007 without any issues I don’t know why we are getting this message.

    We have deployed excel 2003 VSTO add-in in a machine which has office 2003 under IIS and trying open it from excel 2007 from other machine.

    Any help would be appreciated. thanks in advance.

  67. Raghu,

    I have no idea who/why displays this message and how VSTO plays any part in it. Sorry.

  68. Martin says:

    Hi, I have problem with MSI installation. I have created Excel Add-in project in C# (Visual Studio 2008), which use web services of MS Office Project Server 2007 and external files (XML and load create excel template). I have created to this project Setup project (Windows Instaler) following steps at http://msdn.microsoft.com/en-us/library/cc563937.aspx. I have added external files yet. Then I have build setup project successfully. But when I execute MSI installation and instal it with message "successfuly instaled" – after this, it is not instaled in specific folder, but all files are in "D:" and Add-In is not appeared in Excel! I try this also at developement machine and the restul was the same (OS Vista, administrator permissions).

    Have you any idea?

    Posible problem?: in the Prerequisites dialog box I do not have choise of "2007 Microsoft Office Primary Interop Assemblies", but I have correctly instaled MS Office and also Visual Studio 2008.

    Thanks for help

  69. IlkkaV says:

    It is indeed true that Office 2010 allows registering the add-in to HKLM, but it doesn't seem to be the case with inclusion list entries. Is this propagation mechanism still the only way to get an add-in to be also trusted for all users?

  70. Gaurav Jain Software Developer1 says:

    Hi,

    I am developing a excel addin in Excel 2003+VSTO2008.

    Can any one guide me how can i deploy excel add for all user in local machine ?

    Thanks & Regards,

    Gaurav Jain

  71. Gaurav Jain Software Developer1 says:

    Hi,

    I am developing a excel addin in Excel 2003+VSTO2008.

    Can any one guide me how can i deploy excel addins for all user in my local machine ?

    Thanks & Regards,

    Gaurav Jain

  72. Mathew says:

    I have got this working on a windows XP machine . Now I'm trying to achieve the same on windows 7 64 bit machine but registry is not propagating from HKLM to HKCU . Any thoughts on this ?

  73. Vera Dobryanskaya says:

    Thank you for the article – worked great for my project.

    The UserSettings section in registry is amazing piece of information – I even was able to create all-users registration for automation add-in(UDF) that is wrapped inside the Excel DNA. I feel like I need to post an example on my findings(once I find out how to create my own posts), because everything you can find online about registering automation add-ins talks about either using OPENx or doing the Excel.Addings(NAME).Installed = true and so forth that did not seem to work too good through the installer process.

    Thanks aagain

  74. Sizzler says:

    I don't know how to thank you.

    Your post helped to solve the head banging problem straight away.

    Great, Thank you

  75. shmulik says:

    this is my firt addin project and i have a huge problem.

    i create an addin project and its work fine on the develop computer,but when i deployed it to the test computer the addin don displays the new command bar and button,but he is located in the 'active addins' i mad an project setup as thy say in the microsoft msdn, add a registry as they said and all the basic step, so what is the problem the the addin work fine after the deployed on my computer,but not on the test computer. the project is addin 2007 and vs2010. thx alot!

  76. Mike Gledhill says:

    Amazing.  

    This article is 6 years old, and has helped me a huge amount today.

    Great stuff.

  77. T800 says:

    Make sure you adjust the Office version for the registry key,

    eg. Office 2010 =>> 14.0

  78. tushar bhatnagar says:

    Thanks Misha, it was really helpful !!