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
Anonymous
September 05, 2007
Is it possible to do this same trick with Office 2003? If not, is there any other way of achieving machine wide deployment?Anonymous
September 05, 2007
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.Anonymous
September 05, 2007
In this post I am going to discuss how the observations made in the previous post can be incorporatedAnonymous
September 11, 2007
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! KenAnonymous
September 14, 2007
For Chinese readers, there is a translated version (Simplified Chinese) of this article at: http://blog.joycode.com/vsto/archive/2007/09/15/108493.aspxAnonymous
September 14, 2007
As for x64 OS, the registry keys mentioned in this article should be moved to SoftwareWow6432Node, otherwise it will not work.Anonymous
September 14, 2007
Jie, To address 64-bit OS you can just mark the Custom Action assembly as 32-bit platform code.Anonymous
September 15, 2007
I mean in order to do the reg file test on x64 Windows, we'll have to modify the reg file (Wow6432Node) mentioned above. :)Anonymous
October 03, 2007
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.Anonymous
October 04, 2007
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.Anonymous
October 06, 2007
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 PMAnonymous
October 25, 2007
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! ThanksAnonymous
November 07, 2007
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.Anonymous
November 07, 2007
John, Namita, You are running Office 2007, right?Anonymous
November 08, 2007
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 workAnonymous
November 08, 2007
The comment has been removedAnonymous
November 26, 2007
Eine wesentliche Limitierung von managed Office 2007 Add-Ins ist die Beschränkung auf eine per-User -Anonymous
November 26, 2007
Eine wesentliche Limitierung von managed Office 2007 Add-Ins ist die Beschränkung auf eine per-UserAnonymous
January 19, 2008
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?Anonymous
January 23, 2008
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?Anonymous
January 23, 2008
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.Anonymous
January 29, 2008
The comment has been removedAnonymous
January 29, 2008
The comment has been removedAnonymous
February 19, 2008
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.dllAnonymous
February 22, 2008
There are many resources to learn about Visual Studio Tools for Office, and they are scattered throughAnonymous
February 22, 2008
There are many resources to learn about Visual Studio Tools for Office, and they are scattered throughAnonymous
April 04, 2008
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 2cAnonymous
April 04, 2008
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.Anonymous
April 18, 2008
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 ThanksAnonymous
April 20, 2008
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.aspxAnonymous
April 20, 2008
Misha, What about VSTO 2.0?Anonymous
April 21, 2008
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, MishaAnonymous
April 21, 2008
Misha, Thank you for your post.Anonymous
April 24, 2008
This post is both the continuation of part I and part II installments but it also addresses new productAnonymous
April 26, 2008
The comment has been removedAnonymous
April 26, 2008
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! ThanksAnonymous
April 29, 2008
I got ahead of myself and thought it was one week later than it really is (sort of good because I wasAnonymous
May 01, 2008
The comment has been removedAnonymous
May 09, 2008
Das Office 2007 Security Modell erlaubt es nicht, unter HKLM registrierte Managed Add-Ins zu verwenden.Anonymous
May 15, 2008
While the default mechanism for deploying VSTO v3 Add-Ins is ClickOnce, there there's now also a documentedAnonymous
July 14, 2008
The comment has been removedAnonymous
July 14, 2008
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.Anonymous
July 26, 2008
I had a great time over the last couple of days hanging out with Christen Boyd and some of the otherAnonymous
July 29, 2008
The comment has been removedAnonymous
July 29, 2008
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.Anonymous
August 13, 2008
Thanks for this post. It is great! Helped me a lot.Anonymous
September 08, 2008
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?Anonymous
October 17, 2008
Why do we need to alter the "SetSecurity" and the "Setup" project? I sincerely suggestAnonymous
November 12, 2008
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 !!! GreetzAnonymous
November 18, 2008
Good Article. Thanks AarunAnonymous
November 27, 2008
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, DavidAnonymous
May 19, 2009
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 PrabhakarAnonymous
July 09, 2009
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.Anonymous
July 09, 2009
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. "Anonymous
July 26, 2009
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?Anonymous
July 27, 2009
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?Anonymous
July 28, 2009
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.Anonymous
July 30, 2009
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. WamiqAnonymous
August 06, 2009
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? SteveAnonymous
August 16, 2009
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, AlfredAnonymous
August 17, 2009
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.Anonymous
August 31, 2009
The comment has been removedAnonymous
September 05, 2009
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?Anonymous
October 19, 2009
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?Anonymous
October 19, 2009
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 hiveAnonymous
April 04, 2010
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.Anonymous
April 05, 2010
Raghu, I have no idea who/why displays this message and how VSTO plays any part in it. Sorry.Anonymous
April 19, 2010
The comment has been removedAnonymous
June 30, 2010
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?Anonymous
August 16, 2010
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 JainAnonymous
August 16, 2010
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 JainAnonymous
November 12, 2010
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 ?Anonymous
January 27, 2011
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 aagainAnonymous
February 01, 2011
The comment has been removedAnonymous
April 02, 2013
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!Anonymous
October 30, 2013
Amazing. This article is 6 years old, and has helped me a huge amount today. Great stuff.Anonymous
December 24, 2014
Make sure you adjust the Office version for the registry key, eg. Office 2010 =>> 14.0Anonymous
April 14, 2015
Thanks Misha, it was really helpful !!