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 https://code.msdn.microsoft.com/VSTO3MSI. 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
[HKEY_CURRENT_USER\Software\Microsoft\VSTO\Security\Inclusion\30b8e0dd-8ff5-4828-a53b-4933424888fd]
"Url"="file:<SOMEPATH>/ExcelWorkbook1.vsto"
"PublicKey"="<RSAKeyValue><Modulus>nPAT3uo/l/ba+L74Am8cHuxNwe50oXwpVgdKyKQOjskBkZWMMb8vcFzN91NxMj3p7CehgQeGZNuuy64wmvwiFRRq20lKXca3Iv7dkWgED6rkG20EGp4je0E1LrxdwYQg5tj5OO0gn4+nXR201tBy2BuqV1hI1ydxCPNZ+jDX+Gk=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>"
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]
"Url"="file:[TARGETDIR]ExcelWorkbook1.vsto"
"PublicKey"="<RSAKeyValue><Modulus>nPAT3uo/l/ba+L74Am8cHuxNwe50oXwpVgdKyKQOjskBkZWMMb8vcFzN91NxMj3p7CehgQeGZNuuy64wmvwiFRRq20lKXca3Iv7dkWgED6rkG20EGp4je0E1LrxdwYQg5tj5OO0gn4+nXR201tBy2BuqV1hI1ydxCPNZ+jDX+Gk=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>"
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
Anonymous
April 24, 2008
PingBack from http://msofficesecurity.com/officesecurity/microsoft-office/deploying-your-vsto-2008-add-in-to-all-users-part-iiiAnonymous
April 25, 2008
Over the past few weeks, I've attended and presented at a number of conferences (specifically VSLive,Anonymous
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 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
May 20, 2008
Misha, 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! Thanks, GaryAnonymous
May 20, 2008
Misha, 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.WordAddInThis 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, Gary
Anonymous
May 20, 2008
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.Anonymous
May 20, 2008
Misha, 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, GaryAnonymous
June 08, 2008
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. Regards,Anonymous
June 08, 2008
Hello asurachman, Sorry, but I do not understand what you mean by "application creates new record in GACdownload" and why this is a problem.Anonymous
June 24, 2008
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! SvetoslavAnonymous
June 25, 2008
Svetoslav, can you contact me offlne using the email link at top of this page?Anonymous
June 25, 2008
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 thanksAnonymous
June 26, 2008
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.Anonymous
June 27, 2008
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 thanksAnonymous
June 27, 2008
Debuggers work pretty well to trace failures :)Anonymous
June 29, 2008
Hi Misha, I found following article very helpful regarding COM Addin deployment for Office 2003 applications. http://blogs.msdn.com/vsod/archive/2008/04/22/Troubleshootin g-com-add-in-load-failures.aspx Thanks anyway for your prompt response.Anonymous
July 17, 2008
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.Anonymous
July 24, 2008
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. ThanksAnonymous
July 24, 2008
Josh, 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.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
August 11, 2008
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.Anonymous
August 11, 2008
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.Anonymous
August 13, 2008
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.Anonymous
September 11, 2008
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.Anonymous
October 29, 2008
The comment has been removedAnonymous
October 29, 2008
Hey, one more detail. The installation is not registering the formregions.Anonymous
October 31, 2008
Taryon, 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?Anonymous
November 03, 2008
The comment has been removedAnonymous
November 05, 2008
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()Anonymous
January 07, 2009
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. EdwardAnonymous
January 08, 2009
Edward, 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.Anonymous
July 22, 2009
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? -Thanks, KapilAnonymous
July 23, 2009
Kapil, I can not think of any way to restrict non-admin users from disabling their add-ins.Anonymous
September 02, 2009
The comment has been removedAnonymous
September 15, 2009
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 SwitzerlandAnonymous
September 20, 2009
The comment has been removedAnonymous
October 15, 2009
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. Thanks, FarzadAnonymous
October 28, 2009
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 :) Cheers, BryanAnonymous
October 28, 2009
Bryan, 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.Anonymous
November 02, 2009
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?Anonymous
November 16, 2009
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 !! Thanks!!Anonymous
November 29, 2009
The comment has been removedAnonymous
November 30, 2009
I just added a little "Update" to the blog with the location of a tutorial showing how to add the setup project.Anonymous
November 30, 2009
The comment has been removedAnonymous
November 30, 2009
Roy, 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.Anonymous
December 01, 2009
The comment has been removedAnonymous
December 01, 2009
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: http://msdn.microsoft.com/en-us/library/bb772087.aspxAnonymous
December 01, 2009
Thanks a ton for your support Misha....Anonymous
December 14, 2009
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.Anonymous
December 15, 2009
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.Anonymous
January 06, 2010
Hi, 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?Anonymous
January 07, 2010
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.ZMN393ccd55�05bc3d4_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, MichaelAnonymous
January 07, 2010
@Michael: Right-click on your setup project, choose View -> File System, open the properties for Application Folder, change DefaultLocation to [ProgramFilesFolder][Manufacturer][ProductName].Anonymous
January 07, 2010
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. Thanks, MichaelAnonymous
January 08, 2010
The comment has been removedAnonymous
January 10, 2010
Thanks Misha for the quick reply and the very useful articles.Anonymous
January 14, 2010
Has anyone got this deploy to all users method to work with Office 2010? looks like I am not the only one having issues.Anonymous
January 14, 2010
For Office 2010 you actually have 2 options:
- 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)
- Or, just create entries under HKEY_LOCAL_MACHINESoftwareMicrosoftOfficeAddIns - In Office 2010 the support for HKLM registration has been re-enabled
Anonymous
January 14, 2010
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 :-)Anonymous
February 17, 2010
When adding the inclusion as written I get in the registry keys like: file://c:program.... which is not a valid URL. Is there a way to translate the TARGETDIR to a URL wihtout using code?Anonymous
February 24, 2010
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.Anonymous
February 25, 2010
Ragdoll, no the value of the key is not important and is generated arbitrary.Anonymous
February 25, 2010
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. Thanks, RobertAnonymous
February 26, 2010
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. ;) Thanks, RobertAnonymous
March 02, 2010
The comment has been removedAnonymous
March 03, 2010
The comment has been removedAnonymous
March 04, 2010
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.Anonymous
March 04, 2010
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 - http://support.microsoft.com/kb/976811Anonymous
March 05, 2010
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()Anonymous
March 05, 2010
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.Anonymous
March 05, 2010
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. :)Anonymous
March 05, 2010
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.Anonymous
March 17, 2010
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: http://msdn.microsoft.com/en-us/library/cc563937.aspx but experienced 2 problems.
First is that while building my setup project the [TARGETDIR]test.vsto|vstolocal changes to [TARGETDIR]test.dll.manifest during build 2) 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 http://msdn.microsoft.com/en-us/library/cc563937.aspx comment "Deployment manifest requires <deployment> section." and "[TARGETDIR]ExcelAddIn.vsto|vstolocal changes to [TARGETDIR]EPMForecaster.dll.manifest during build". Any help would be really appreciated! Thank you!
Anonymous
March 17, 2010
Dima, 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, MishaAnonymous
March 17, 2010
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!Anonymous
March 17, 2010
Misha, thx a lot for your help! Renaming the registry hive like "something.myaddin" took effect, now everything work's as it should! =)Anonymous
June 02, 2010
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?Anonymous
September 28, 2010
Hi, I created a Word-Addins using this link www.vba2vsto.blogspot.com 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-
- can u guide me how can i deploy word Add-ins to all users of my machine.
- 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
Anonymous
May 29, 2011
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 2007.my 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 . picasaweb.google.com/.../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 social.msdn.microsoft.com/.../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 .. stackoverflow.com/.../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 . Thanks Shashank shekharAnonymous
May 27, 2013
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, regards Bala