Develop Office Client 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.
Does this also work for an VSTO 2005 SE Addin running on Outlook 2007?
Yes, the change itself is specific to Office and does not depend on the version of the VSTO runtime.
Note that if you are installing a 2005SE add-in then the manifest value in the registry will point to the .dll.manifest file and there is no need to append any |vstolocal parameter. This would be quite similar to how you install a 2005SE add-in under HKLM for Office 2003.
At last, back on track. Office addins that can be deployed to all users like the good old days. VSTO was supposed to make programming Office in .net easier - it introduced as many hurdles as it was supposed to solve. VSTO still leaves many Outlook COM referencing headaches.
Hi. I've got question if is it possible to make install addin for only one non admin user?
I'm slightly confused about this article and one experience we had with an Office Add-in application solution we developped (VS2008 - VSTORE 3.0)
- Initially we used a MSI (Windows installer) to install our Add-in for all users. It worked fine except for big document manipulation for which we got IsolatedStorageException: unable to determine caller domain.
- To avoid these exceptions, we read here (http://blogs.msdn.com/shawnfa/archive/2006/01/18/514407.aspx) that we had to have our solution being ClickOnce. So we did, and the exception disappeared.
- But now, we cannot deploy our Add-in for all users.
My point is then: is it currently impossible to develop an Add-In that can both:
1) manipulate big Word documents - and perform big XMLDocument.Save() -
2) be deployed for all users ?
I thank you in advance for reading my post,
PS: Please note that this was not our choice to use isolated storage, but a default mecanism behind saving xmldocuments process. We also granted our code full trust.
I'm trying to create an installer for all users and after installing the patch and following the instructions in the white paper I can't get anything.
I build the installer and it sets the loadbehaviour to 3 and then when I open excel it gets set to 0. I've tried the environmental variable and that does nothing.
Have you got any ideas??
When I try to run the KB976477 hotfix I get the following error: "the expected version of the product was not found on the system"
I is a Windows XP PC with SP3 and Office 2007 (SP2)
Any help would be appreciated
@Bob: If you want a single use non admin install just use clickonce - publish the add-in from the publish page in VS to create the installer package. (http://msdn.microsoft.com/en-us/library/bb386095(v=VS.100).aspx)
@Ace: I am confused by your question too, If you are using MSI to deploy your add-in as mentioned in 1) then you should not need isolated storage in 2) which is a ClickOnce concept. Are you using the |Vstolocal appended to the end of your add-in registration which would ensure that the add-in doesn’t get installed to the clickonce cache (http://msdn.microsoft.com/en-us/library/bb386106.aspx)? If the add-in is configured to run from folder and not install to clickonce cache then 1) and 2) should not conflict.
@Amjid: Does the add-in work for single user? Does the add-in work with ClickOnce? Most likely the add-in might be throwing some runtime exception. Please see (http://msdn.microsoft.com/en-us/library/6s0wczt9(v=VS.100).aspx) for debugging options.
@GM: Can you try repairing the installation of Office you have installed. If you continue to have trouble you might want to try contacting support: http://support.microsoft.com/contactus/?ws=support
I have had a similar problem with installing patches using the exe provided. Try installing the msp file directly. First extract the msp file from the exe by using /extract. To get the exact extract command, on the command line run the exe with a /? or /help.
Next just install the msp by using this command:
msiexec /update <msifile> /qn /norestart
@GM and Mundrick: It might entirely be possible that this patch is already on your machine. One way to find out would be to find this file and see if the version number matches:
You might be able to find this information in the help ->about section of Office 2007, otherwise you can do a filesystem wide search for this file.
You can also find the file information on the KB support page: http://support.microsoft.com/kb/976477
Was my fault I forgot to set the registry setting after doing adding the KB976477 (as explained in the hotfix notes). Cheers for the response though
The whitepaper - to create a MSI package - lists the
Office 2007 component ID.
What about Office 2010? Please update - thanks.
Check out this forum post for the Office 2010 PIA Component ID's: http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/9bde5b41-f5da-4918-b62b-8ab24479ef93
Has this hotfix been included as part of Office 2007 SP2? I tried to install the package and it says that it has already been applied, but it's not listed in the Add Remove Programs list nor can I find any references to KB976477 in the registry. Do you know of a method to detect whether this hotfix has already been installed?
I have a Windows XP SP3 machine with Office 2007 SP2. The mso.dll file is version 12.0.6529.5000. I also have this issue on a Vista machine with Office 2007 SP2.