I have an add-in developed for Outlook 2016 installed on everyone's machine in my company (about 200 users) but on one user's machine the add-in never loads (even under the "Disabled Add-Ins" or "Inactive Add-Ins"). The correct registry key is setup and all of the files are there but I see the following error from the windows event viewer:
Customization URI: file:///C:/Program Files (x86)/.../MyAddIn.vsto
Exception: Downloading file:///C:/Program Files (x86)/.../Microsoft.Office.Tools.dll did not succeed
I don't understand why it's looking for that file in that particular folder. I don't see this file on anyone else's machine in that directory and yet my add-in works for them. I thought that it should be loaded from the GAC (his GAC matches everyone else's with the same "Microsoft.Office.Tools.v9.0"). What could be the problem on his machine?
Note - I'm installing my add-in through a windows installer made using WiX. I've tried it with both Outlook 32-bit and Outlook 64-bit on his machine and that didn't change anything.
The exception detailes belongs to the ClickOnce installer, not MSI (WIX). I'd recommend removing any previous editions of your add-in first.
Related
My goal is install VSTO Outlook Addin for all users on local PC instead of current user. I used Publish method from Visual Studio and result is exe file, which means ClickOnce method. (not posible for install for All)
Well i start my research i found Wix.
My first question is, when i create Build from Visual Studio from my VSTO addin, i have 2 dirs and 20 files, is possible to assign dirs in product.wxs file in WIX Directory ref?
Second question, when files and dirs are "installed" to target directory, (program files for example) how can be VSTO be assigned to Outlook ? Its becouse to add VSTO to registry HKLM ?
Im asking if im closer to my goal
Not sure if I understood your first question but I will try to answer it anyway. The only files you have to bring to a user's PC are those that are located under bin/Release folder, except for those that have the *.pdb extension. There are 2 ways how you can add them into the installation:
First way is to manually add each file you want to include in your installation as the file component in you Product.wxs. You can find a good example of that in their official tutorial.
Second way is to utilize the harvest tool (Heat) from Wix Toolset. This tool can generate a list of components automatically during a build.
As for your second question. To make Word or Outlook see your add-on you have to create an entry in Windows registry during installation. For example for Microsoft Word you have to create a new key HKLM\Software\Microsoft\Office\Word\Addins\MySuperAddOn with the following entries:
Entry
Type
Value
Description
REG_SZ
Required. A brief description of the VSTO Add-in. This description is displayed when the user selects the VSTO Add-in in the Add-Ins pane of the Options dialog box in the Microsoft Office application.
FriendlyName
REG_SZ
Required. A descriptive name of the VSTO Add-in that is displayed in the COM Add-Ins dialog box in the Microsoft Office application. The default value is the VSTO Add-in ID.
LoadBehavior
REG_DWORD
Required. A value that specifies when the application attempts to load the VSTO Add-in and the current state of the VSTO Add-in (loaded or unloaded). By default, this entry is set to 3, which specifies that the VSTO Add-in is loaded at startup. For more information, see LoadBehavior values. Note: If a user disables the VSTO Add-in, that action modifies LoadBehavior value in the HKEY_CURRENT_USER registry hive. For each user, the value of the LoadBehavior value in the HKEY_CURRENT_USER hive overrides the default LoadBehavior defined in the HKEY_LOCAL_MACHINE hive.
Manifest
REG_SZ
Required. The full path of the deployment manifest for the VSTO Add-in. The path can be a location on the local computer, a network share (UNC), or a Web server (HTTP). If you use Windows Installer to deploy the solution, you must add the prefix file:/// to the manifest path. You must also append the string |vstolocal (that is, the pipe character | followed by vstolocal) to the end of this path. This ensures that your solution is loaded from the installation folder, rather than the ClickOnce cache. For more information, see Deploy an Office solution by using Windows Installer. Note: When you build a VSTO Add-in on the development computer, Visual Studio automatically appends the
You may want to read the official documentation to see more details.
Wix Toolset does allow to do that as well. You have to declare the RegistryKey component in your Product.wxs.
We are developing an Outlook Add-In VSTO using C#, it reads a configuration by using ConfigurationManager.AppSettings["key"].
We made a .msi installer by WIX and installed to Outlook, then the Add-In can't read the config value.
But when trying with Advanced Installer, the add-in works perfectly.
I'm not sure what the Advanced Installer does with my msi file (or registry), can you please help me to solve the problem with WIX because we want a free installer creator tool (Advanced Installer costs me 1500$).
Thanks a lot
Does the add-in assembly name correspond to the config file name? Are they located in the same folder? Is the config file deployed?
The Deploying an Office Solution by Using Windows Installer article provides all the required steps for creating Windows installer setup programs.
First let me get this stuff out of the way:
This happens with my own addin, as well as another third party VSTO add-in, so I don't think I'm doing anything incorrect
.net 4.0. VSTO runtime 10.0.50701
Windows 8. Also tried Windows 7
I am using the |vstolocal suffix in the HKLM registry for the addin
I have also tried adjusting the 'program files' paths in the registry here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion to point to my new 'F:' location, and that didn't change any behavior
Here are the steps I'm taking:
Create a new volume on a separate disk other than C:. I called mine 'F:'
Add the program files structures F:\program files and F:\program files (x86)
Install your VSTO addin (I'm using Outlook but it will happen with Word too) to "F:\program files (x86)" instead of the 'C:' drive
Launch Outlook.
Result is this dialog:
According to this, I shouldn't be getting this since its an all users install (see the Inclusion List section):
Is this a Microsoft issue? I realize I can add to the Inclusion myself however then I would be subscribing to more of a per-user approach, and that seems like a bad approach. Is this coming up because anything other than the 'real' program files folder cannot really be trusted by VSTO loader?
The dialog window belongs to the ClickOnce installer. But the link goes to the Windows Installer section in MSDN.
It is up to you where to install the add-in, there is no need to use the Program Files folder.
Make sure that you did all the steps described in the Deploying an Office Solution by Using Windows Installer article. It describes all the required steps for creating add-in installers.
I recently went through the same thing, i got this when i just published the vsto from vs2015. I tried using installshield, yielded the same issues, eventually i switched to wix installer, now i don't have any update checks running and its a clean install. These are some customization updates and our client actually had a firewall blocking it so the install failed. Try wix it worked great for me. Hopefully you don't end up with my current issue of not seeing the add-in if i am not running outlook as Administrator, driving me nuts, good luck.
I'm following the excellent tutorial by Malte Ahrens on how to create a OneNote add-in.
Initially I followed it step by step, making a few changes (just renaming the class, and using my own name and GUID in the assembly) info. As I'm using VS2012 and am not yet ready to hand-roll a WiX installer I manually copied over the built dll to the correct place and also created a registry file to make the requisite entries. I confirmed that they were all there, loaded up OneNote but no add-in, going to "mange COM addins" section I saw the following error:
Load Behavior: Not loaded. A runtime error occurred during the loading of the COM Add-in.
I spent some time debugging this but didn't get very far. So this afternoon I decided to start again but copy his code verbatim. I simply downloaded the example project, used the trial of Vdproj to Wix to create the installer and built everything.
I get the exact same error.
Why is this please? What does this mean and most importantly how do I debug the problem?
A few specifics about my environment and where it may differ from the original tutorial.
I am running Office 2013 AND it's 64bit. His tutorial is for 2010. This means when I loaded up the demo solution I had to remove the non-existent reference to the Onenote 14 Interop and add the v15 version.
In terms of registry entries they go to the right place, not the WOW6432 registry nodes. I doubly know this as if I load up OneNote and then refresh the HKCR registry node for the add-in, the LoadBehavior switches to 0x00000002, (disabled).
Other things that may be worth noting.
I have enabled OneNote logging and it's quiet on my issue.
There are 2 other posts on here with a seemingly similar problem (but Office 2010) here and here, neither got a response. The first guy had it loading once, but then had to manualy start it each time, mine never loads (and I've not signed my assembly) the second guy never got a response.
As I say, even knowing how to debug this further would be a great step forwards.
Edit:
I've gone back to debugging my own version, which is almost identical anyway as I'm not sure what the installer is actually doing and I think because it's a demo of the wix converter it's only allowing me to build for x86.
If I add OneNote.exe under "start external program" and run debug on my add-in, I see the following lines appear when I try and tick the add-in under "manage COM add-ins" within OneNote. I'm afraid I'm still pretty green at all this so I'm not sure what it means.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
Also, since reading up more I think me simply copying my dll into the install folder program files\[manufacturer]\[application] (as I don't have an installer) was not enough. I've now executed this against my dll
PS C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319> .\RegAsm.exe
and it came back with
Microsoft .NET Framework Assembly Registration Utility version 4.0.30319.33440
for Microsoft .NET Framework version 4.0.30319.33440
Copyright (C) Microsoft Corporation. All rights reserved.
Types registered successfully
Is there anything else I should be doing to register the dll correctly?
Enable logging for OneNote 2013:
Create a file "EnableOneNote2013APILogging.reg"
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\OneNote\Options\Logging]
"EnableLogging"=dword:00000001
"EnableTextFileLogging"=dword:0000001
"ttidLogObjectModel"=dword:00000001
"ttidLogObjectModelAddins"=dword:00000001
Create a file "DisableOneNote2013APILogging.reg"
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\OneNote\Options\Logging]
"EnableLogging"=dword:00000000
"EnableTextFileLogging"=dword:0000000
"ttidLogObjectModel"=dword:00000000
"ttidLogObjectModelAddins"=dword:00000000
This is based on http://blogs.msdn.com/b/descapa/archive/2006/12/08/debugging-the-onenote-api-enable-logging.aspx but you need to add EnableTextFileLogging ;-).
The logfile is created in %temp%\OneNote.log
For OneNote 2010 change the path in the .reg files to \14.0\ instead of \15.0\
Our entire team installed VS 2010(It has both VSTO runtime 2010 and .net framework 4).After installing that some of our developers are getting the below error (but for majority its working fine) while opening the deployed VSTO application from server developed in framework 3.5 and VSRO runtime 3:
***** Exception Text *******
Microsoft.VisualStudio.Tools.Applications.Runtime.CannotCreateCustomizationDomainException: Customization does not have the permissions required to create an application domain. ---> System.Security.SecurityException: Customized functionality in this application will not work because the administrator has listed file://fmrdmwaprd2/CA-INSTALL/Demand/Templates/GeoDSS_Templates_UTT/APAC_RevOpt_OEM_Good_Bad_News/APAC_RevOpt_OEM_Good_Bad_News_UTT.vsto as untrusted. Contact your administrator for further assistance.
at Microsoft.VisualStudio.Tools.Office.Runtime.RuntimeUtilities.VerifySolutionUri(Uri uri)
at Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.CreateCustomizationDomainInternal(String solutionLocation, String manifestName, String documentName, Boolean showUIDuringDeployment, IntPtr hostServiceProvider, IntPtr& executor)
The Zone of the assembly that failed was:
MyComputer
It sounds like your computers have "trust issues". Here is a link with more information about the trust levels for different locations / items and how you can change them:
http://msdn.microsoft.com/en-us/library/6exya3kf(v=vs.80).aspx
I also found this SO article that might be close enough to your issue to help you out:
Installing VSTO 4.0 Causes VSTO 3.0 Addin to quit working
I've run into this issue before and solved it. It's related to the fact that VSTO creates a custom AppDomain at load time for the VSTO AddIn. The action uses Shadow Copy to copy the VSTO .DLL into a temporary location and loads it from there.
Anti-Virus tools like McAfee actively kill this shadow copy operation, hence the AddIn will not load on protected computers, or any with tight security permissions.
To circumvent shadow copy, have your installer place your AddIn .DLL in the Global Assembly Cache. With it in the GAC, the Shadow Copy process is avoided, and the .DLL should load.
Keep in mind - this can cause issue with development, so do not deploy the .DLL into the GAC on your development machine. If you do, you'll not be able to run your changes in Visual Studio (the DLL in the GAC will run instead).