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

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.

This post is both the continuation of part I and part II installments but it also addresses new product that has shipped since VSTO 2005 SE and this is VSTO 2008 (which is also known as VSTO 3.0 – see the complete matrix of VSTOs in this post by Andrew Whitechapel ).

Here is a quick recap of the last 2 episodes:
Traditionally Microsoft Office has allowed All Users installation of COM Add-Ins by the virtue of registering the add-in under HKLM\Software\Microsoft\Office\<Application>\AddIns registry key. There were few problems with managing HKLM add-ins – in particular non-admin users could not disable an add-in explicitly as well as crashing add-ins could not have been disabled automatically for such users. So, when managed add-ins were introduced in Office 2007 it was decided to break the cycle and disallow registering managed add-in under HKLM.

Today only those managed add-ins registered under HKCU registry hive are activated by Office 2007. This creates a different kind of problem – “how an administrator can deploy an Office add-in so that every user on the machine can use it?”.

The part I post introduced an internal Office 2007 registry replication mechanism. The very sketchy part II post described, at a very high level, how to take advantage of the registry replication and modify the VSTO 2005 SE add-ins setup projects to be deployable to all users (The technique is a mixture of moving registry keys around in the deployment project itself coupled with creating custom actions similarly to those described in Darryn’s VSTO 2005 SE deployment article). As a side note: I really should have invested more time into part II and make it a full walkthrough article. Now I am paying for my laziness since I need to answer a lot of “please clarify” comments on that post. But hey, on the flip side, trying to connect the sketchy pieces together and build the nice deployment package does build character – doesn’t it?

If you are just learning this stuff – please understand there is no quick fix solution and before trying what I am going to describe below – please make sure to read all 4 articles I just mentioned: start with the deployment article (which by itself consists of 2 articles, then post I and post II).

VSTO 2008 significantly improves over VSTO2005SE deployment experience by introducing ClickOnce based deployment. The idea is that, as it is the case for ClickOnce deployment of Windows Forms project, you can now “publish” VSTO 2008 projects. This will create a setup.exe file you can give to your users to deploy your VSTO add-in.

The problem is that ClickOnce is also a per-user solution. Notice that there is no such thing as ClickOnce for All Users. And, if you are an administrator running a server and you want to deploy VSTO solution to all users on your server – you really need an MSI based setup project. This is, of course, not something we do anymore in VSTO 2008.

Let’s see what can be done about it though. First of all, go and take a look into samples at These samples show how to create an MSI based deployment package for VSTO 3.0. The samples target single user – not All Users – but this is a very good start.

UPDATE: The above sample has been converted into a tutorial called “Deploying a Visual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft Office System Using Windows Installer” . So, instead of starting with a sample – just click the link above and follow the steps to create the MSI-based deployment project for VSTO 3.0 add-ins.

Key difference between VSTO 3.0 MSIs and VSTO 2.0 MSIs is that security model has changed. In VSTO 3.0 we no longer rely on CAS for security – both us and our users did have their share of problems with CAS so enough is enough. This was replaced with a concept of “Inclusion List” based security. Consequently, one of the things you will find in the site above is an InclusionListCustomActions – custom actions that call InclusionList APIs to pre-trust your solution.

So, now supposedly you have followed the VSTO3MSI samples and created an MSI based deployment package.

Next step for you is to follow general guidelines in the part II article and modify this solution to use Office’s replication mechanism for All User deployment by moving registry entries from HKCU under HKLM\Software\Microsoft\Office\12.0\ User Settings\MyCompany.MyAddIn\Create registry key. Also, same post describes how to add a custom action to set up Count registry value the replication mechanism is based in and as well as handling the uninstallation of the add-in.

Next step is to remove the InclusionListCustomActions – these CAs are not good for All Users deployment.

But what do you need to do instead? Read on.

“Inclusion list” is just reg entries under HKEY_CURRENT_USER\Software\Microsoft\VSTO\Security\Inclusion – notice it is under HKCU not HKLM. The format of those registry entries is pretty self-describing – we use some random GUID to create a unique entry in the list, the entry contains the path to add-ins .vsto file and manifest’s public key. Although “inclusion list” APIs create these registry entries for you but only under HKCU hive. That is not good for all users deployment. Instead your setup needs to install those registry keys into HKLM\Software\Microsoft\Office\12.0\ User Settings\MyCompany.MyAddIn\Create\Software\Microsoft\VSTO\Security\Inclusion and rely on Office’s replication mechanism to copy those into HKCU.

So, first go to HKEY_CURRENT_USER\Software\Microsoft\VSTO\Security\Inclusion and find the entry in the list that pre-trusts your solution. Export this entry into a .reg file. This file should look like this:

Windows Registry Editor Version 5.00


Next, change the highlighted text to

HKEY_LOCAL_MACHINE\Software\Microsoft\Office\12.0\User Settings\<MyCompany.MyAddIn>\Create

Next, change <SOMEPATH>\    to     [TARGETDIR]  and save .reg file.

Your .reg file now should look something like this:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\Software\Microsoft\Office\12.0\User Settings\<MyCompany.MyAddIn>\Create\Software\Microsoft\VSTO\Security\Inclusion\30b8e0dd-8ff5-4828-a53b-4933424888fd]

Go into your Visual Studio deployment project, open the Registry View, right click on “Registry on Target Machine” root node in the view and click “Import …” to import the .reg file.

That’s it – you should now have the functioning MSI based deployment package for VSTO 3.0 solution. Use it!

As usual, the post is not a complete walkthrgough and might be sketchy in parts – so if you have something to add or you have found a mistake in the post – please leave a comment.

 UPDATE: Several people has commented on this post and the the “part I” post that registry propagation does not happen when booting MS Project. I have confirmed this. The workaround is to ask users to start some other Office application first e.g. Excel or Word.

Comments (82)

  1. Over the past few weeks, I’ve attended and presented at a number of conferences (specifically VSLive,

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

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

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

  5. dwarfnebula says:


    Thanks for this fantastic post.  I have it *almost* working with a custom Word Add-In (done in VSTO 3.0), except for one weird problem.  In the registry entry for the add-in under the HKCU hive, I set the value for the ‘Manifest’ entry to the ‘####.vsto|vstolocal’ setting.  But as soon as I compile the installer, it changes the setting to the .dll.manifest file.  I can’t seem to get around it.  Once I install it, if I change it back directly in the registry, everything works fine.  But I can’t figure out how to get the build operation to leave that setting alone?  Any help would be greatly appreciated!



  6. dwarfnebula says:


    Okay, I figured it out, but I’m not sure why this fixed it.  I was just comparing my settings to those of the VSTO 3.0 installer samples, and noticed something strange about how they named their add-in key.  What I had to do was change the name of the AddIn under the AddIns key.

    The original key was: AddInsBCG.Office.Greenhouse.WordAddIn

    * This did not work (it is the same name as that of my add-in assembly)

    I changed it to: AddInsBCG Systems.BCG.Office.Greenhouse.WordAddIn

    * The compiler then left this setting alone, and everything seems to work fine.

    Really strange, but hopefully this will help someone else having this sort of issue.

    Any insight to this behavior would be great.

    Thanks again for this post, it’s just what I needed,


  7. Misha Shneerson says:

    Hi Gary,

    The solution you have found is absolutely correct :).

    Some insights on why this is happening. This strange behavior is something that is left from previous versions of VSTO aka VSTO2005SE which did maintain setup projects – it is a bug and will be fixed by a service pack. The behavior there was that upon project recompilation we woud scan the current solution for any deployment projects, look for the registry key HKCUSoftwareMicrosoftOffice<Application>AddIns<ProjectName> and update the registry values with the most up to date settings.

    Obviously, if you went and renamed the reg key to something different from …..<ProjectName> – our scanning code would not be able to make the connection and leave this registry key alone.

    Now, if you are trying to get All-Users deployment working you might still have some work to do . Part of this article teslls to move all HKCU registry keys under HKLMSoftwareMicrosoftOffice12.0 User SettingsMyCompany.MyAddInCreate hive. Once the reg keys are there – you should not be hitting this bug.

  8. dwarfnebula says:


    Thanks for the quick response.  I followed your article, and migrated the key for security to the HKLM hive, and I get the all users deployment with no problem.  The install works so far on both XP, Server 2003, and Vista!  Vista was the main reason I wanted to go to VSTO 3.0 to get around that whole CASPOL nightmare.  This is the ideal solution!

    Thanks again,


  9. asurachman says:

    Hi Mishaa,

    Thank you for your articles. My Addins has been successfully deployed.  And also I have noticed that the application creates new record in GACdownload each time it is loaded.  The new one doesn’t suppress the previous one.  

    Please your suggestion how we can handle this.


  10. Misha Shneerson says:

    Hello asurachman,

    Sorry, but I do not understand what you mean by "application creates new record in GACdownload" and why this is a problem.

  11. cyberbyber says:

    Hi Misha, I am working on a VSTO2005SE based Word 2003 add-in. I developed it in VS2008. During development and testing everything was fine on my machine. I followed all the articles on deployment of application wide add-ins using deployment packages and have developed a deployment pack from the template generated by VS, that deploys the assembly for use by all users(by registering under the HKLM hive) and sets proper security settings in CAS, by granting full access to the strong name of the assembly.

    But when I test it on a separate user station, even though the setup runs just fine, i do not see the menus that the add-in creates. In addition the LoadBehavior value in the registry switches from 3 to 2 after word opens, which according to the documentation is due to a failure upon loading the add-in. I examined the fusion logs, but there was not a single attempt of even trying to load the add-in assembly. I do not get any error messages in Word either. I even went a step further and extracted the necessery Office 2003 PIAs from the GAC and substituted the references that VS had created for me with them, just to be on the safe side on referencing the very same assemblies. VSTO as well as PIA were of course installed on the testing station prior to installing the add-in.

    For me it seems that I have no means to find out what exaclty the cause of this failure might be and would be very thankful if you could come with some tips.

    Both the development and testing environments are XP SP2 with Office 2003 Pro with Norwegian locale.

    Thanks in advance!


  12. Misha Shneerson says:

    Svetoslav, can you contact me offlne using the email link at top of this page?

  13. Nas says:

    My Addin for Outlook 2003 works great on XP machines but not on Terminal server. I am creating registry key under HKLM hives and on XP machines Loadbehavior values remains 3 but on Terminal server it is 2 after addin deployment. If I change it to 3, my Addin works but as soon as another outlook session starts on terminal server, loadbehavior switches to 2 and addin doesn’t work at all.

    I dont’t have much knowldge about Addin deployment on terminal server. I think it is not code security issue as I have given FullTrust to addin. Should I create registry entry under HKLM or HKCU?  If HKCU then how I can create registry for all users?

    Many thanks

  14. Misha Shneerson says:

    Hi Nas,

    I am not sure how Terminal Servers come into play. It is possible thought that the add-in throws exceptions on startup – you can use VSTO_SUPPRESSDISPLAYALERTS setting to enfore failure logging or just attach a debugger under the failure scenario.

  15. Nas says:

    Hi Misha,

    Many thanks for your response. I forgot to mention that my Addin is a shared IDTExtensibility2 based and not a VSTO one. I don’t think so I can be able to use VSTO_SUPPRESSDISPLAYALERTS but do you know any other method or tool to trace Addin load failure.

    Many thanks

  16. Misha Shneerson says:

    Debuggers work pretty well to trace failures 🙂

  17. Nas says:

    Hi Misha,

    I found following article very helpful regarding COM Addin deployment for Office 2003 applications. g-com-add-in-load-failures.aspx

    Thanks anyway for your prompt response.

  18. Andy says:

    Hi Misha,

    Thank you for useful post.

    But what about deploying Add-In to one standard user?

    We have some Outlook Add-in and an installer for its deployment.

    The installer works fine on XP and on Vista when I install it under an Administrator user account.

    But, when I install it for a user without administrator privileges, it doesn’t work.

    If User Account Control (UAC) is off we have an error.

    The error occurred at registration step.

    Vista says: ‘The module "MyAdd.dll" was loaded but the call to DllRegistredServer failed with error code 0x80004005’.

    Running the installer via "Run as Administrator" (form the context menu) gives the same error.

    If UAC is on, the "An unidentified program wants access to your computer" window appears.

    We must type UserName and Password for some administrator.

    As a result Add-In will be installed for this admin!!! Not for the target user!!!

    Is it possible to make Add-In deployment for a user without administrator privileges?

    Please, help!

    Andy Blanch

    P.S. NSI-installer is used for deployment.

    The "RequestExecutionLevel highest" command in nsi-script has no effect.

  19. Josh S. says:

    I created an Outlook 2007 add in in VS 2005 for allUsers following all the steps you have described in previous articles.  It worked great.

    Suddenly, the organization that I work for has rolled out a new image of Windows XP with I don’t know what Office SP 2007, and the add in is no longer active.

    I checked the registry and the registry keys were properly copied & the runtime security parameters appear to be correct.  

    What would have changed that might have caused my add in to suddenly become inactive for allUsers.


  20. Misha Shneerson says:


    I am sorry but nothing rings a bell. If you wish you can contact me offline and we could try to troubleshoot it over email.

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

  22. Jon H. says:

    Thanks for a very useful series of articles.  I have what is probably a very simple problem, I’m no doubt over looking something.  

    I’m using VSTO3 with VS2008 and have created my own setup project.  After much reading I have my setup project with a custom action as described above calling the appropriate routines; I’ve added all the right project output into the setup project and manually included the .vsto and .manefest files which seem to be omitted as part of ‘project output’.  The installer runs fine, copies the files, generates the ‘create’ registry key and the subsequent HKCU key appears as expected.  When I run Outlook, however, the addin doesn’t appear.  If I double-click the .vsto and hit ‘install’ it works perfectly.

    Could you tell me what double-clicking the vsto is doing that my installer isn’t?

    Many thanks for any assistance.

  23. Jon H. says:

    A bit more info, I’ve double checked and cleared out the old inclusion entries from development. It looks doesn’t like the count value is being created in the addin ‘create’ key, however when I add this manually (and make sure the keys are being ‘copied’ to HKCU) Outlook still doesn’t start up with my addin so my original question remains.

    Many thanks.

  24. Abhinav says:

    Hi Misha,

    I created a ribbon in Excel using VSTO 2008. My ribbon contains a button, on which I have provided screen tip & super tip as well as keyboard shortcut, after deploying it to excel; I am getting an extra tag in screen tip pop-up asking user to “Press F1 for more help”. While pressing F1 key it is opening MS online help; is it possible to customize this shortcut, I want a *.chm file to be opened which provide context help with perspective of my project.

  25. Hi Misha,

    This is not related to the deploy to all but its related to vsto deployment.

    It is possible to deploy an VSTO application without using a setup, .msi or any exe files, just by copying files or anything like it?

    thx a lot.

  26. Taryon says:

    Hi Misha!

    I used your articles (specially the Part III) and the, parts 1 and 2.

    My addin is for the outlook 2007 and it will be installed for just one user. This is a regular user and the installation needs to be done by the administrator.

    Ok. In the registry view of my setup project, I create the keys for the HKCU with FriendlyName, LoadBehavior and Manifest, as you suggest and for the HKLM all the keys for the Inclusion.

    When I install the addin in the target machine, The first one is created but the Inclusion isnt. If I create the Inclusion by manual, when i execute the outlook it asks me to install the addin, but it doesnt.

    Could you help me?

    Oh. If I install the Visual studio in this machine and compile the addin in it, it works fine.

    thx in advance

  27. Taryon says:

    Hey, one more detail. The installation is not registering the formregions.

  28. Misha Shneerson says:


    I asked Kris Makey to look into your question and hre are some tips from Kris him:

    This statement is a big clue to his problem:


    Ok. In the registry view of my setup project, I create the keys for the HKCU with FriendlyName, LoadBehavior and Manifest, as you suggest and for the HKLM all the keys for the Inclusion.


    Inclusion list only exists in the HKCU, if he’s using the replication functionality he needs to check the "end result" on the user’s machine, ignoring the add-in keys all-together.  

    He might actually have better luck copying the certificate into the trusted publisher’s store and the root certificate authority store.  He should discuss with the "administrator" this option though since putting "arbitrary" certificates is not recommended.

    If he still needs help after investigating that he should try the following things:

    Is he including the |vstolocal flag after the .vsto file in the manifest path?  

    Is the .vsto file on an internet site for the user and did he sign with the temporary certificate (user needs to add the hosting website to trusted web sites list in internet options.  Or he needs to get a "valid" certificate.   If he’s using vstolocal this may not work anyway, but I’m not 100% certain about that).

    Has he tried setting VSTO_SUPPRESSDISPLAYALERTS = 0 so he’ll get error messages, these may help him far more to debug the issue.

    Is he installing to Windows XP or Server 2003 -> Are the PIA’s installed?

  29. Taryon says:

    Hi Misha!

    Thx for your attention.

    1. I will try it with certificates. How I am the "admin" and the addin will be used in the internal network, I will use my own certificate because I do not need to be certified to my users, ok?

    2. the replication funcionality is working ok.

    3. yes, I am including the vstolocal flag

    4. The PIA’s are installed. 2007 in XP SP3 and Vista Clients

    The workaround:

    1. I install the vs2008 + SP1 + VSTO for the client into my profile then, compile and execute the addin one time.

    2. after that, I create a directory in <drive>:Program filesMicrosoft<addin> with the bindebug stuff

    3. Create the keys in registry for this

    4. Working ok for the profile

    5. After any change, I need to update the addin directory into the program files.

    After that, I uninstall the vs2008

    its ugly but works ok!

    thx again for your cooperation!

  30. Taryon says:

    Hi Misha!

    Using the VSTO_SUPPRESSDISPLAYALERTS=0 I got this:

    ************** Exception Text **************

    System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

      at System.Reflection.Module._GetTypesInternal(StackCrawlMark& stackMark)

      at System.Reflection.Assembly.GetTypes()

      at Microsoft.Office.Tools.AddIn.CreateRibbonObjects()

      at Microsoft.Office.Tools.AddIn.GetRibbonObjects()

      at Microsoft.Office.Tools.AddIn.CreateRibbonExtensibilityObject()

      at Microsoft.Office.Tools.AddIn.get_RibbonExtensibility()

      at Microsoft.Office.Tools.AddIn.Initialize()

      at oSistema.ThisAddIn.Initialize()

      at Microsoft.VisualStudio.Tools.Office.EntryPointComponentBase.Microsoft.VisualStudio.Tools.Applications.Runtime.IEntryPoint.Initialize(IServiceProvider hostContext)

      at Microsoft.VisualStudio.Tools.Applications.AddInAdapter.ExecutePhase(ExecutionPhases executionPhases)

      at Microsoft.VisualStudio.Tools.Office.Internal.OfficeAddInAdapter.InitializeEntryPointsHelper()

  31. Edward says:

    Hi Misha,

    Currently, I am working on a VSTO based Word 2003 Addins developed by using VS2005. The addins consists of 2 buttons on a Toolbar. One button to show a Form, and the other one to publish/upload the Word document to a remote directory. During development the addins works fine. Then I created a setup project for the add-ins. I installed it on several machine in my office and it works just fine. Well, the publish button works on Word 2003 runs on Windows XP, but not on Vista. But that’s just a small problem I guess.

    When I tried to install it on a Terminal Server, the toolbar did not show up. There was nothing wrong with the installation process. I made sure that the prerequisites are already installed (such as the Office PIA and VSTO Runtime). I even tried to install it locally from the terminal server but still no luck.

    It seems our Word 2003 addins doesn’t work under Vista and Terminal Server. Do you have any advice or sources of information about this?

    I would be very thankful if you could help. Thanks in advance.


  32. Misha Shneerson says:


    I am not sure what the issue is. Please contact me offline (use the email link at the top of this page) and we will see what can be done.

  33. Kapil says:

    Hi Misha,

    I have an Outlook2007 add-in which is registered in HKCU(as expected)but this creates a problem as the Non Admin users can also disable the Add-in. Is there any way, I can restrict the non admin users from disabling the add-in?



  34. Misha Shneerson says:


    I can not think of any way to restrict non-admin users from disabling their add-ins.

  35. BZ says:

    Hi Misha,

    I am creating VSTO add-in under Excel 2003 and 2007 versions. I want the setup/deployment steps to be command line scripts so it’ll be easier to integrate into another product setup. But I could not find a complete list of commands for Excel 2007 VSTO add-in deployment.

    What does the ClickOnce application do specifically on file, registry, security, etc? Is this process scriptable? Thank you for your help!

  36. Swissguy says:

    Hi Misha

    Thx man – ur tutorials (part I-III) helped me a lot. I really was in a mess, before I found them 😉

    Keep on the good work!

    Greets from Switzerland

  37. Dag Arve says:

    Hi Misha, thanks for your very useful articles regarding VSTO deployment.  I still experience problems using the technique, and have struggled for a time now trying to resolve the problem.

    I have this Visual Studio 2008 Solution, containing 3 projects:

    1. WordAddIn

    2. ExcelAddIn

    3. SetSecurity

    The two first are VSTO add-ins (Office 2007 add-ins) which in turn are depending on several additional components (which are compiled and built in a separate solution) doing a lot of stuff behind the scenes, and which are referenced under each project.  The third project contains code to add the add-ins to the inclusion list and cope with the registry counter incrementation (most of the code copied and modified from the articles mentioned later).

    The solution works perfectly fine before deploying it (running directly from Visual Studio 2008), both the Word add-in and the Excel add-in are correctly loaded and works as expected.

    The challenge is to be able to deploy the solution using an .msi file.  To do this, I have added a setup project named AddInSetup, following the guidelines given in both Misha Sneersons three articles Deploying your VSTO Add-In to All Users (Part I – III) as well as Deploying a Visual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft Office System Using Windows Installer (part 1 and 2) by Wouter van Vugt, Code Counsel and Ted Pattison, Ted Pattison Group.  

    What happens when I run the Install command from VS (or the generated setup.exe file) is that the installation seems to complete correctly; no error messages are shown, the registry is updated in the HKEY_LOCAL_MACHINE hive, setting the “HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice12.0User SettingsMyCompany.MyAddInCreateSoftwareMicrosoftOfficeExcelAddinsMyCompany.MyAddIn” registry path correctly, as well as the “HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice12.0User SettingsMyCompany.MyAddInCreateSoftwareMicrosoftVSTOSecurityInclusion2cbfd73c-c011-4248-b6b0-641db5da43fc”inclusion list entry.  At this point, the HKEY_CURRENT_USER hive has not yet been modified, which is also correct.

    When I start Word (or Excel) the HKEY_CURRENT_USER hive gets updated; the “HKEY_CURRENT_USER SoftwareMicrosoftOfficeWordAddinsWordAddin” key (and the corresponding for the ExcelAddin) has correctly been copied from the HKEY_LOCAL_MACHINE hive.  The Manifest entry has the value “C:AddovationCodeOfficeAutomationAddo.OfficeAddInOfficeAddInCommonReleaseAddoWordAddIn.vsto|vstolocal”.  The “HKEY_CURRENT_USERSoftwareMicrosoftOffice12.0User Settings<company>.WordAddin” Counter key (and the corresponding for the ExcelAddin) is created / incremented correctly.  The only thing that does not happen is: the add-ins never gets loaded.

    What seems odd is that when I check for installed programs under “Add or remove programs” (Control Panel), I can see that an application called AddinSetup has been installed. However, the WordAddIn (and ExcelAddIn) component is not installed.  If I subsequent run the WordAddIn.vsto file (from the installation location where it correctly is placed), the addin correctly installs (no error messages whatsoever) and when I start Word, it loads and everything works correctly.  When I then check for installed programs again, the WordAddIn has been installed, so now both the AddinSetup and WordAddIn exist in the list of installed programs.

    Could somebody please give a clue on what is done wrong?


    Dag Arve

  38. Farzad says:

    Hi Misha,

    I have some problems for VSTO 3.0 .

    Is it possible give us a link to download your solution?

    It will be great helps.



  39. Bryan says:

    Hi there Misha,

    This series of posts has been invaluable for me getting my AddIn deployed, thanks for taking the time to post it.

    I’ve come across an interesting quirk however, I have a user log on to thier account and the registry keys are created as normal and everything works awesomely.  When the user logs into a machine without the AddIn installed the loadBehavior is set to 2 as its not present. When the user subsequently logs into a machine with the AddIn installed it no longer loads. Short of changing that registry value everytime the user logs in I’m at a bit of a loss to work this one out.

    Again Thanks for the info 🙂



  40. Misha Shneerson says:


    Sounds like this particular user has roaming HKCU registry… I never heard about this being possible thinking that HKCU is always bound to one single machine. I am curious what are you using to do this?

    Anyway, once add-in is disabled it can only be enabled manually (either through the regkey to by using Office’s COM Add-Ins dialog).

    One option to consider is to write a simple logon script (i.e. the program registered at HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun) that would restore the value of registry key.

  41. Dan says:

    I have used the code presented here(all parts) but i have a small problem.

    At uninstall the InstallState of the custom action to install to all users project is not removed.

    What could be the problem?

  42. sandeep yadav says:

    Hi Misha,

    Article is really very useful. Just need a little guidance on following area.

    My add-in project has Form Region of adjoining type created in vs 2008. (Its not desgined by Outlook 2007) .. Form region appears in development environment but does not appear when i prepare i Installer kit and install it for AllUsers mode. Any help /guidance on thsi will be really great !!


  43. Roy says:

    Hello Misha,

       Can i edit the registries of the target machine with VS 2008. As you explained in your post that there will be a setup file created in VS 2005. But we cant find the setup file in VS 2008, so we cant actually right click and say" edit target registry". Like can we Deploy our Outlook Addins to multiple clients with Click once deployment using VS 2008.

      Please do answer immedietly. Thanks in Advance

  44. Misha Shneerson says:

    I just added a little "Update" to the blog with the location of a tutorial showing how to add the setup project.

  45. Roy says:

    Hello Misha,

      I ve gone through the update…But i still have a problem.Can i add the registries into the target machine programmatically with ClickOnce deployment?? Just confirm me whether we can deploy MS Outlook Add In’s with CLickOnce to multiple users??

        When i try to publish with clickonce on a network share, and try to access the setup on a client machine , it is throwing an error saying some exception and it cant install.?? Is there any solution for this or i need to go for another alternative deployment technique?? I require Auto update option….

  46. Misha Shneerson says:


    ClickOnce deployment is only suitable for per-user installation and you do not have the flexibility of adding your own registry keys.

    You must create an MSI package (like described in this article) if you pursue a model where the add-in deployed once by the administrator is automatically available to all users on the machine.

  47. Roy says:

    HI Misha,

     Thanks Alot for the response. I deployed an outlook Addin and published it on my local drive D. Now i shared the drive and tried to click on setup from another machine by accessing the share path. But iam thrown wth the following error:

    "Customized functionality in this application will not work because the certificate used to sign the deployment manifest for ClickOnce is not trusted. Contact your administrator for further assistance."

    Why is this not possible??

    Thanks in advance

  48. Misha Shneerson says:

    Roy, due to my limited capacity I strongly encourage you to use search engines to find answers.

    Below reference came up first in google when searching for VSTO and the keywords from the error message:

  49. Roy says:

    Thanks a ton for your support Misha….

  50. Alex says:

    Hi there,

    too bad for me I found this link after hours of eperimenting with a setup porject. But anyway, it helped me to figure out the last step 🙂 so thanks a lot for this guide on this topic.

    One question is hanging around in my case though. The whole solution works when after installation I start for example Excel. But I was working on a an add-in for MS Project. And it seems it does not scan the registry to disribute the required keys from HKLM. I was just wondering if this is only my case or thi is a feature of MS Project no being an inborn office product (i quess). Or did I missed something ?

    Thanks for any answers.

  51. Misha Shneerson says:

    To Alex,

    Indeed, I believe the only app that does not do the registry propagation is MSProject. This is unfortunate … It was noted before by other commenters as well.

  52. JK says:


    I’m trying to get an Visio Add-In with an installer which I created based on your blog entries to install on a Visio 2007 system (which works fine) and on a Visio 2010 beta system (which does not work at all, the recreation of the registry keys seems not to be done there). Any tips?

  53. Michael says:

    Hi Misha,

    Superb 3 articles – got my addin working after being very stuck.

    I don’t know if you are able to help out, but when the propagation mechanism fires, it copies the addin.dll into a user settings folder

    C:Documents and SettingsuserLocal SettingsApplication Dataassemblydl3QLER5XCO.TEWTGVGXN9J.ZMN393ccd5505bc3d4_4b90ca01

    The problem comes as a permissions issue, the user (non admin) is setup so they cannot run .dll’s from thier Documents and Settings.

    Is it possible to control the folder name at least at the QLER5XCO.TEW level to allow a consistant rule to exclude this folder? I assume this folder name is based on a Strong Name or similar.

    An alternative is installing this to a different allowable folder. Are either of these possible?

    Any advice is greatly appreciated.

    Many thanks,


  54. JK says:

    @Michael: Right-click on your setup project, choose View -> File System, open the properties for Application Folder, change DefaultLocation to [ProgramFilesFolder][Manufacturer][ProductName].

  55. Michael says:

    Hi JK,

    Thanks – the master (initial install) addin is installed there, but once Office runs, it copies the DLL into the folder under document settings for that user. I believe this is happening due to office propagation. I just don’t know if any part of that is customisable.



  56. Misha Shneerson says:

    Michael: The issue is related to shadow copying – basically VSTO AppDomains are set up in such a way that a copy of an assembly is created and executed. This is mostly done to allow in-place updates – i.e. the original file is not locked when assembly is running.

    I heard some anti-viruses do this – disallow executing code from Documenta and Settings folder. In this case we advise to work with the particular anti-virus provider to resolve the issue.

  57. Michael says:

    Thanks Misha for the quick reply and the very useful articles.

  58. david swain says:

    Has anyone got this deploy to all users method to work with Office 2010?  looks like I am not the only one having issues.

  59. Misha Shneerson says:

    For Office 2010 you actually have 2 options:

    1. Use the registry propagation (in which case you need to create a separate set of registry keys under HKEY_LOCAL_MACHINESoftwareMicrosoftOffice14.0 – notice the version change from 12.0 to 14.0)

    2. Or, just create entries under HKEY_LOCAL_MACHINESoftwareMicrosoftOfficeAddIns – In Office 2010 the support for HKLM registration has been re-enabled

  60. JK says:

    I solved my problem. A second counter was missing. Now I’m creating keys and counters under 12.0 and 14.0 so the installer will work with both versions of Office 🙂

  61. Victor Heijke says:

    When adding the inclusion as written I get in the registry keys like:


    which is not a valid URL. Is there a way to translate the TARGETDIR to a URL wihtout using code?

  62. ragdoll says:

    Misha, I have a question that I am hoping you can answer. In your example above you showed how to import the inclusion list registry value to the MSI. Each time I re-compile the MSI, the inclusion list registry key is regenerated with a different random key name on the dev machine. So the reg key I imported earlier into the MSI no longer matches (the Public key and URL are okay, but just the key name keeps changing each time I compile). I am trying to track down why the add-in doesn’t load for all users in Office 2010. Does it matter that the key name keeps changing and no longer matches? Thanks.

  63. Misha Shneerson says:

    Ragdoll, no the value of the key is not important and is generated arbitrary.

  64. Robert Nagler says:

    First of all, thanks to Misha for the extensive posts. It helps me a lot!

    But i still have problems with the setup package itself. If i build the package the *.vsto manifest isn’t packed in the msi file. Only the *.dll is included. I’ve signed the ClickOnce-Manifest and the Assembly itself. What am I doing wrong? Have you some hints for me.



  65. Robert Nagler says:

    I solved it by adding the *.dll.manifest and *.vsto file via "Add"->"File" menu in the setup project.

    The downside of this way is that you reference the default output folder of the Release build configuration explicitly. When you change the build configuration back to Debug, the setup project still references the files from this folder.

    Anyway, now i can build an complete msi file. 😉



  66. Casper says:

    This was quite a handfull 🙂

    I believe I’ve been through all the steps and I’ve got the setup.exe, the .msi file and the prerequisites.

    I’ve also got some thirdparty dlls packaged into the msi and everything does install.

    The inclusion list registry key also matches the string I inserted into the InclusionListCustomActions project.

    My Addin however does not show up in Outlook. It’s a Calendar add-in with an adjoining region with a couple of text fields.

    I’m still with the singleuser install btw. I thought I’d try to get that to work before moving on.

    It works fine when I debug on my development machine.

    Any hints to where I should look for errors?



  67. Misha Shneerson says:


    Did you try setting up VSTO_SUPPRESSDISPLAYALERTS to make the errors visible?

  68. Ragdoll says:

    It’s me again :).  With much trial and error and thanks to the information you provided, I got my Word 2010 add-in working using Visual Studio 2008 (VSTO runtime 3.0).  Now, the next step for me is to make it work with Office 2010 64 bit. It is my understnading that I will need to create the solution using Visual Studio 2010 and VSTO 4.0 runtime. I want my add-in to continue to run as 32 bit however, as it calls a couple of legacy DLLs I created in VB6. Do you have any information or pointers on how to set up the registry keys for my add-in? I will need to write the add-in registry values to HKLM under Office 14.0 User Settings so that they will propogate to all users… but if my add-in is 32 bit, I do not have access to the "real" registry. Any guidance would be GREATLY appreciated.

  69. Misha Shneerson says:

    Ragdoll, re: 64-bit support …

    Office 2010 does contain VSTO runtime 4.0 which also load VSTO 3.0 solutions. So, you should not recompile the solution in VS 2010 or neither deploy VSTO runtime onto the machine. You are correct about the registry things. I believe marking the MSI as targeting 64-bit platform is the only thing you need to do make sure the regkey do not go into the WOW portion of the registry. (There is a post I recently made about taking COM shim wizards to 64-bit – some of the registry hacking and setup adjustments described I describe ther eapplies to VSTO solutions as well).

    Also, if you are targeting Office 2010 then doing the registry propagation is no longer necessary – the HKLM support for registering VSTO add-ins have been added. For Office 2007 a similar hotfix has been made available as well –

  70. ragdoll says:

    Thanks for this info – I am trying your suggestions.

    I now have the registry keys in the right place (following your Shim Wizard article or exporting from Wow6432Node). The Microsoft Office Customization Installer appeared and asked me to verify the publisher of the add-in, which I accepted. The add-in didn’t load, however. So I enabled VSTO error logging… I am getting the same exception that Taryon reported above. Does this ring a bell?:

    System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

      at System.Reflection.Module._GetTypesInternal(StackCrawlMark& stackMark)

      at System.Reflection.Assembly.GetTypes()

      at Microsoft.Office.Tools.AddIn.CreateRibbonObjects()

      at Microsoft.Office.Tools.AddIn.CreateRibbonExtensibilityObject()

      at Microsoft.Office.Tools.AddIn.get_RibbonExtensibility()

      at Microsoft.Office.Tools.AddIn.Initialize()

      at AddInVSTO.ThisAddIn.Initialize()

      at Microsoft.VisualStudio.Tools.Office.EntryPointComponentBase.Microsoft.VisualStudio.Tools.Applications.Runtime.IEntryPoint.Initialize(IServiceProvider hostContext)

      at Microsoft.VisualStudio.Tools.Applications.AddInAdapter.ExecutePhase(ExecutionPhases executionPhases)

      at Microsoft.VisualStudio.Tools.Office.Internal.OfficeAddInAdapterBase.InitializeEntryPointsHelper()

  71. Misha Shneerson says:

    If you debug your solution now you will be able to analyze the LoaderException which will have a detailed information why some of the classes in your assembly cannot be instantiated … A wild guess is that you are implementing some of Office interfaces that have changed in Office 2010.

  72. ragdoll says:

    Thank you. Part of the problem was that I was trying to compile and build the app in Visual Studio 2008, and then install it with Office 2010. Because it uses VSTO 3.0 and not 4.0, I was not able to run/debug the code against Office 2010. (At least, I think that is how it all works – please correct me if I’m wrong. When I try to run it, I get a message stating "You cannot debug or run this project, because the required version of the Microsoft Office application is not installed." Even though I have project references set to Office 14.0 and Word 14.0.) I am in the process of installing Visual Studio 2010 so that I can debug this against Office 2010, assuming that is what I need to do.

    PS- Thank you for your support – I know you have a day job you are also trying to do. 🙂

  73. Misha Shneerson says:

    Ragdoll, ohh the "You cannot debug or run this project .." error is because your project is considered to be an Office 2007 project so by default VS will try to startup from a path registered at HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice12.0ExcelInstallRoot

    The easiest way to override this is to bing the project’s properties page, go to the Debug section and select "Start external program" option – make sure to provide the full path to Word 2010.

  74. Dima says:

    Hello, Misha! Thank’s for your splendid article!

    I have one problem, may be you can advise any solution…

    I have created Outlook Addin using VS 2008 and Setup project to deploy it.

    Did everything described in this article:

    but experienced 2 problems.


    First is that while building my setup project the


    changes to

    [TARGETDIR]test.dll.manifest during build


    If i manually, on the user PC change the registry to vsto|vstolocal and then run outllok i’ve got the error:


    Deployment manifest is not semantically valid.

    Deployment manifest requires <deployment> section.

    Both problems are described in the comments to the article

    comment "Deployment manifest requires &lt;deployment&gt; section." and "[TARGETDIR]ExcelAddIn.vsto|vstolocal changes to [TARGETDIR]EPMForecaster.dll.manifest during build".

    Any help would be really appreciated! Thank you!

  75. Misha Shneerson says:


    RE: the first issue.

    I think you are running into a bug in VS 2008. In VS2005 VSTO automatically updated the registry in the setup project when the main project was re-built … In VS 2008 this code should have been removed but it was not.

    I guess the other issue is the result of this setup unintended change to setup…

    There is an easy workaround to the first issue. VSTO is examining all setup projects, then it looks for a registry key under HKCUSoftwareMicrosoftOutlookAddIns<AddInProjectName> and if such key is found then we will add the corresonding "Manifest" registry value.

    The workaround is to either rename the setup registry key something else e.g.HKCUSoftwareMicrosoftOutlookAddIns<AddInProjectName>.Setup

    or to register the add-in under HKLM (I believe that’s what you actually want to do if you are doing an MSI deployment).

    Hope this helps,


  76. Dima says:

    Thank you very much for such a quick reply! I’ll try to rename the registry hive as you said, and see what happens!

    Thx again!

  77. Dima says:

    Misha, thx a lot for your help! Renaming the registry hive like "something.myaddin" took effect, now everything work’s as it should! =)

  78. Ashton Hobbs says:

    Misha, great article, although I am having one issue we cannot seem to get around.  For the ID (GUID) that is used as the Key for the InclusionList entry in the registry, where does that GUID come from since we seem to be getting multiple values.

    We build our software on multiple different machines so is the GUID that is generated specific to the machine or does it change based on something that we could identify and use when installing?

  79. Gaurav Jain says:


    I created a Word-Addins using this link

    I am using Word 2007+VSTO 2008

    But I am able to deploy this addins for all users of my machine.

    When i sent the word document to my client,my client is not getting that addin.

    I have 2 Question-

    1) can u guide me how can i deploy word Add-ins to all users of my machine.

    2) what are changes i have to do that my client also get this work add-ins with word document.

    Thanks in Advance.

    Best Regards,

    Gaurav Jain

  80. shashank shekhar says:

    dear Misha,

    i am posting it again because i did not find my same previous comment.

    your above article is great,but i think it works for only office problem is same but with word 2003.i.e.addin installation for all user.

    We have made a word 2003 Addin but when we are trying to install our Addin for all user , it is not working as expected .when admin account user install it for all user then it work only for his account but not for other users. It does not even show in com Addin on toolbar.

    As we can judge, our registry entry settings are correct under both HKCU and HKLM.we have kept same registry settings for both HKCU and HKLM.are we have to do something different than these settings?

    I am attaching a picture which tells about registry entry setting of our word 2003 Addin .…/General02

    We are using caspol security policy for granting full trust to assembly. We grant full trust to machine level.

    User is admin so there is no issue of permission or privileges.

    I have gone through an article…/1435e0d4-19d0-4b3f-98af-558007ab760d . but it did not solve our problem.

    I want to give you some more info about environment

    • Visual studio 2008

    • Visual studio 2005 tools for office second edition runtime

    • Visual studio built in setup and deployment.

    • We have found one strange situation that when we install word 2003 Addin for all user by admin account ,here Addin loads fine ,and then switching to another admin account Addin does not load but again switching to previous admin account and opening word 2003 again , but this time Addin does not load.

    Then we found that load behavior from registry entry under HKLM is changed to “2” .

    here i want to add that there is no unhandaled exception in our code.we have used VSTO_SUPPRESSDISPLAYALERTS and VSTO_LOGALERTS also. everything is fine(thats why it works for user who install it). Which can cause Word 2003 to change a COM-addin's LoadBehavior to 2 – other than unhandled exceptions? here is the similar link ,but i dont know what to do ..…/what-can-cause-outlook-to-change-a-com-addins-loadbehavior-to-2-other-than-unh

    while answering ,please do remember our primary question i.e. Word 2003 addin installation for all user ?

    your valuable answer will give me a great pleasure .


    Shashank shekhar

  81. Hi Misha,

    I was reading this blog and face a similar issue as reported by ragdoll  5 Mar 2010 11:07 AM above.

    we have 2 VSTO add-ins for Outlook 2007 and Word 2007. I got the Word 2007 add-in working, however the Outlook 2007 at .Initialize throws an error. After setting the VSTO_SUPPRESSDISPLAYALERTS, the message as similar to ragdoll is displayed.

    The environment is a terminal server (windows Server 2008 R2) with outlook 2007 installed. We are loading our dll libraries dynamically.

    can you assist to the above,