Develop Office Business Applications using Visual Studio
An often-requested feature for VSTO add-ins is the ability to install an add-in for all users of a machine. Misha Shneerson had blogged about a workaround to enable this scenario here. This workaround is not recommended. Now, deploying an add-in to All Users is supported for both Microsoft Office 2007 (through a hotfix) and Microsoft Office 2010.
With Office 2010, it is possible to directly register a VSTO add-in under the HKLM Office add-ins registry hive such that the add-in gets installed machine wide for all users of the machine.
The registry keys under HKLM are very similar to the registry keys for the current user as described in this MSDN topic. Each Office application has its own node at the following location where it will try to load add-ins that are installed machine wide:
e.g. HKEY_LOCAL_MACHINE\Software\Microsoft\Office\application name\Addins\add-in ID
These machine wide add-ins load and behave similar to add-ins that are installed per user, However, there are some important differences you should remember when deploying such add-ins.
1) You need administrative privilege on the machine in order to install an All User add-in.
End users running with current user privilege cannot install/uninstall or disable an add-in. This could potentially lead to a worst case scenario where an add-in fails unexpectedly resulting in the host Office application crashing, and the end user cannot do anything to stop the Office application from crashing because they cannot disable the add-in causing the crash. So, make sure your add-in is thoroughly tested before deploying to it to all users of a machine.
2) An all user add-in cannot be deployed through ClickOnce and must be deployed through a Windows Installer MSI.
Writing to HKLM requires administrative privileges, so you cannot use ClickOnce to deploy your add-in because ClickOnce only works with current user privileges. This means that you need to create your own MSI package that registers the add-in under HKLM and installs it for all users. This whitepaper and MSDN topic should give you the necessary background information to create a MSI package for your VSTO solution. The most important thing to remember while creating this all user installation is to always append a “|vstolocal” to the manifest registry value pointing to the add-ins deployment manifest location.
e.g. manifest = “C:\Program Files\MyVSTOAddIn\MyVSTOAddIn.vsto|vstolocal“
Appending the “|vstolocal” tells VSTO to run the solution from the installation folder (like C:\Program Files\MyVSTOAddIn) instead of installing and running it from the ClickOnce cache.
3) Trusting the Add-In for all users
To trust an add-in for all users of a machine, it must be signed with a Trusted Publisher’s Certificate (See Authenticode Certificates in Granting Trust to Office Solutions and How to: Add a Trusted Publisher to a Client Computer for ClickOnce Applications for more information). If the add-in is not signed with a trusted publisher’s certificate, each individual user sees the Microsoft Office Customization Installer dialog box (aka trust prompt) asking them whether they want to install the add-in the very first time the add-in is loaded for them. If they choose to install the add-in, the add-in will run and they will not be prompted again. However ,if they choose to not install the add-in, the add-in will not load and they will continue to see this trust prompt every time they open up the Office application and the add-in tries to load. If you are developing your solution with Visual Studio 2010 and targeting .NET 4, an alternative to signing with a Trusted Publisher certificate is to install the add-in into the machine Program Files location. This location also needs administrative privilege to write to and will be inherently trusted by VSTO, so there will be no trust prompt even if the solution is not signed with a Trusted Publisher certificate.
4) Installing on 64-bit Operating Systems
Unlike the HKCU registry hive, the HKLM registry hive for Office add-ins is redirected on a 64-bit Windows OS. So if you are trying to register an add-in with 32-bit version of Office running on a 64-bit OS, the add-ins registry will be under the WOW6432Node. The 32-bit Office running on 64-bit OS will always load the add-ins listed under this key.
e.g. HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\application name\Addins\add-in ID
A 64-bit version of Office 2010 on 64-bit OS will always load the add-ins under this key:
With the ability to directly register and load VSTO add-ins from the HKLM hive on Office 2010, you can easily deploy VSTO add-ins to all users of a machine and no longer need to follow the steps outlined in Misha’s blog
Update for Office 2007 A recent hotfix (KB976811 available through KB976477) for Office 2007 also makes it possible to register and load VSTO add-ins under HKLM for Office 2007. The process works exactly like Office 2010 but to make this work for Office 2007 you will have to download and install the hotfix on every machine where you want to deploy the all user add-in.
In conclusion, you can install an Office2007 or Office 2010 add-in to All Users if you use Windows installer to deploy your add-in and the add-in is installed with administrative privileges. To secure your All Users add-in, sign your Office add-in with a certificate that is in the Trusted Publisher list or install the add-in to the Program Files directory.
please find the first link here to the above post.i have kept all registry setting info here
desperately waiting for your reply
We created an addin for Excel 2010 using VS 2010 and plan deployment using MSI on 64bit OS (Window 7) and Office 2010 32 bit for all users.
We keep getting the trust prompt to install add-in when we start Office applications first time. The add-in is installed in C:\Program Files (x86) but the article says C:\Program Files is trusted. Could you please confirm if C:\Program Files (x86) is also trusted like C:\Program Files ?
How can VSTO add-in be used in a Citrix/RDS environment where you need per-user activation of the add-in? COM add-in allowed them to be installed by admins, then just remove the HKLM add-in entry. Then a login script rule and action could place the same entry but in HKCU\addins. Can VSTO be treated the same way? How can I disable it's activation for everyone after installing?
We are trying to deploy PowerPivot for Excel 2010 on 2008 R2 RDSH and only want it to activate for certain users that will be on the same host as users who do not need it. Where exactly is do I first disable it's load point for everyone so I can switch to using the COM addin keys as described but in HKCU? Or can I use the native VSTO activation but only filterd, per user? Right now it tries to load for everyone but works for no one! I know that is another issue and I need it working for everyone first. I only need it to be fully preinstalled with admin rights and working for any user without admin rights.
There are 2 problems with this blog post that are likely the cause of the other commenters' problems:
1. Appending the registry Manifest path with |vstolocal doesn't work, at least for me with Office 2010 x64 for Windows 7 x64. My add-in would load but not function, then would not load in subsequent instances of Word.
2. When writing the registry keys to HKEY_LOCAL_MACHINE you must ensure they have been removed from HKEY_CURRENT_USER.
I never did figure out my VSTO installation issues so my last comment may be off, especially point #1 about vstolocal.
FYI This blog's instructions worked for me with Office 2007 on a 32-bit machine. However they didn't work for Office 2010 on a 64-bit machine.
I have been able to make this mostly work for 32 bit Office on a 64 bit (2008 R2 Server) OS with RDC configured. Editing the registry HKLM in the Wow6432Node creating a new key for the Add-In does cause it to be installed for all users as they launch the Office application on the RDC server.
The issue I cannot figure out is how to get an updated version of an already installed Add-In to install the same way. The registry entry for each Add-In points to a .vsto manifest file which does contain the version number in it, but apparently when the Office application (in my case Project Pro) launches and checks the registry for Add-Ins it does not compare the installed version to the version in the .vsto file so it doesn't know that an updated version needs to be installed.
Similar to Kieth's experience, when I add "|vstolocal" to the registry entry for the manifest file path the Add-In does not even load. I am continuing to Google search and experiment with this. I posted on the MSDN forum as well, but so far my only response from anyone at Microsoft was less than helpful: social.msdn.microsoft.com/.../2ab357ea-74c8-4eb4-ba6b-865408a3d569
I have developed an Add-In for MS Project. The add-in is working fine for MS Project 2010 as the add-in is registered under HKLM, but when i try to load an add-in for MS Project 2007 the "LoadBehavior" value changes from 3 to 0, so i was trying apply the above mentioned hofix (office-kb976477) in order to get add-in worked for MS Project 2007.
But i am not able to install this hofix on my machine, it shows the message "The expected version of the product was not found on the system." when i try to install the hotfix.
I tried to resolve the problem by installing "Microsoft Office suite Service Pack 2" as it is mentioned at support.microsoft.com/.../976477 and then applying the hotfix but it gives the same message.
There is Microsoft Office Standard 2007 and Microsoft Office Project Standard 2007 installed on my machine.
Nice article. Office 2010 uses which dll? is it 12.0.0 or 14.0.0. This will decide the local machine registry set up
The following article, last updated in 2010, solved the issue for me.
It describes the registry entries you need to set when installing an Addin, and which entries you need to delete and set when uninstalling an Addin.
Using that tutorial, I was able to create an Addin which could be pushed out to our company's users (as an Admin account), and when the users next opened Outlook/Excel/etc, it'd copy the registry values to their HKCU, so they would be able to use the Addin.