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.
Here is what you can do to determine if the patch is installed.
You know that the patch installs version 12.0.6520.5000 of mso.dll
Check the registry to get the path to mso.dll.
Use that path to retrieve the version of the file. If the version is less than 12.0.6520.5000, then you know that the patch needs to be applied.
You are confused about a question asked by Ace and comment: "then you should not need isolated storage".
I think you've missed his point. His application, like mine, requires saving large files *from an Office add-in*. Note this is different to saving a document opened by, say, Word where the COM interop can be used to save the document. The issue arises when saving Office 2007 files (or an XPS file) using the System.IO.Packaging API because the API hits Isolated storage (and there's nothing the caller can do about it). However because it uses Isolated storage, the lack of a domain causes the exception when any one part exceeds 8MB. Using ClickOnce may solve the problem for the single user case but, as Ace asks, what about installing for the machine?
Currently my installer deploys Outlook-PIAs and VSTO-Runtime by using bootstrapper packages.
My question: May I create an own bootstrapper package around mso-x-none.msp (retrieved by using /extract on hotfix exe) without getting legal trouble with Microsoft? On support.microsoft.com/.../en-us ("Hotfix") Microsoft says:
"Additional information: Hotfixes are distributed by Microsoft Customer Service and Support. Customers may not redistribute hotfixes without written, legal consent from Microsoft."
Does this mean, all of my users have to request KB976477 by themselfs and install it before installing my addin?
Any chance someone from the VSTO Team can follow up with MS Office Team to get the Office 2007 Help Tab Add-in, office2010.microsoft.com/.../download-help-to-get-started-with-office-2007-HA010214685.aspx, updated to take advantage of the KB976477 hotfix and allow installing the Add-in for all users of the computer?
You have mentioned .. "To secure your All Users add-in, sign your Office add-in with a certificate" .. can you guide me on How to add a certificate to my msi installer?
We are facing the same problem. I applied patch kb 976477 and modified the registry key but the add-in is not visible on Windows 2008 server R2 64 bit machine. Can any one know is there any other solution for Windows 2008 server R2 OS
@Varun Its generally not recommended to package your cert with an MSI. Trusted Publisher certs should be pushed through some sort of admin policy. This might be useful: technet.microsoft.com/.../cc730989(WS.10).aspx @Rahul Ekbote Is the Add-in visible in the COM Addin dialogs at all? Please make sure you are registering it under the right registry hive for 64-bit Operating Systems (Point 4 in the blog post). As such the OS should not make a difference to the add-in except for the registry location due to the bitness of the OS. If the add-in is showing up in the COM add-ins dialog but isn’t loading for some reason you can follow some of the troubleshooting steps at: msdn.microsoft.com/.../6s0wczt9.aspx Thanks Saurabh
In WS2008 R2(x64), I have a scenario where I've installed SP2(office2007sp2-kb953195-fullfile-en-us.exe) for MS Office 2007 then I installed the Hotfix(office-kb976477-fullfile-x86-glb.exe), and then launched MSExcel and encountered error saying 'Microsoft Office Excel has stopped working' and gave me 2 options 1.) Check online for a solution and close program 2.) Close Program. I've checked the problem details and it says:
Problem Event Name: BEX
Application Name: EXCEL.EXE
Application Version: 12.0.6425.1000
Application Timestamp: 49d64dd6
Fault Module Name: unknown
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: 00000000
Exception Code: c0000005
Exception Data: 00000008
OS Version: 6.0.6002.2.2.0.274.10
Locale ID: 1033
Additional information about the problem:
Read our privacy statement:
The next time i will launch excel it will be in safe mode. And i can no longer open my MS Excel. Even i run the Detect and Repair.
Any idea on this?
I would really like to see an answer to @Marco Schmittnägel question, since I have the same question. Also, is this hotfix included in any service pack or office update or do we always need all our customers to install it?
@Einar: I've recently talked to several experts at Microsoft Germany and some communities. Jens Häupel (Microsoft Germany Platform Strategy Manager) told me, that we're not allowed to embedd the hotfix in our software. Those hotfixes have to be deployed by the user himself or the central IT department in an enterprise environment.
I've also asked him in an earlier comment on one of his blog posts if this hotfix will be included in a patch or service pack: To his knowledge it won't be part of any regular update.
The strange thing is, that i've seen many posts in several communities and blogs which describe how to deploy KB976477 or other Hotfixes as bootstrapper packages. For example in social.msdn.microsoft.com/.../76f610ed-4ee3-414a-a48a-b1bb46419618 Tim Li (MSFT and Moderator of VSTO forum) points to www.pupuweb.com/.../add-microsoft-office-2007-hotfix-as-setup-prerequisite-with-bmg-tool which describes how to create a bootstrapper package for KB976477.
This particular fix has been pushed out as a public update for Office. This means that most customers will already have it since a majority of people opt in to receive updates for Office.
The preferred approach is to have your customers install the latest updates for Office and then they will have the fix.
If you are developing a solution to be deployed with in your organization, it is OK to include the hotfix with your solution. However, if your solution is being distributed to 3rd parties then they will need to download the hot fix themselves.
I hope this clarifies things.
Visual Studio Team
Looks like it's in MS10-36
I am an expert in Windows Installer and was doing the Per-User copy hack years ago before this new technique came out. I'm a little concerned about this new pattern because
1) I can't redistribute the hotfix to third parties in my installer which means I'm totally at the mercy of them using Windows Update.
2) The registry values that enable this functionality aren't included in the HotFix by default. Now I have to put that registry value in my installer which is something of a no-no ( I try to never be invasive with other peoples products or operating system settings.
Am I missing anything? I give this solution a D maybe a C-.
I have developed Microsoft Visual studio 2010 addins. it will appear in Addin- Manger but not displayed in IDE. Also i have checked the Startup. when next visual studio start the Addin is not visible in standard toolbar. Please help me in this regard.
Will the hotfix (976477) to allow all users to deploy the VSTO add-in to all users in Office 2007 be included in Office 2007 Service Pack 3 ? This would be very valuable for us and our users. Any feedback on this would be appreciated. Thanks.