Problem summary: I need to create an Outlook 365 add-in that can change visual properties of items in a mailbox.
I've created a plugin using Yeoman Generator using the instructions here:
https://learn.microsoft.com/en-us/office/dev/add-ins/quickstarts/outlook-quickstart?tabs=yeomangenerator
This works fine, but the add-in only seems to be enabled for opened email items.
In the following image you can see the generated add-in is disabled, but the Viva Insights add-in is enabled:
Is what I am trying to do possible with the Yeoman generator? How? If not, can it be done with a VSTO add-in? Is there any place that has example code?
Please refer to the ExtensionPoint element in the XML manifest. It defines where an add-in exposes functionality in the Office UI. The documentation can be found here: https://learn.microsoft.com/en-us/javascript/api/manifest/extensionpoint?view=powerpoint-js-preview
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.
At this moment, I have a VSTO add-in fulfilling my requirement. But it needs to run with Visual Studio or installed. Ideally, I want to have a Word file containing this VSTO add-in and put this file on my server so that user can use my add-in just by downloading this file, no need to any extra work. Is it possible?
Any help would be appreciated.
A VSTO project must be installed, whether it's an add-in or a document-level customization. Installation ensures that the correct version of the .NET Framework and other pre-requisites are installed. It also includes the user explicitly trusting the solution.
If you want something that distributes with a document then you need VBA, embedded in the document and saved as a *.docm file. Note that this file type will trigger macro security - some people will have settings that won't allow VBA to run. Some will have settings that can allow "trusted" and/or signed projects to run (you can research that).
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.
Working on an outlook addin and I was wondering if manually replacing the compiled DLL on a target machine is sufficient when I decide to update my addin ? is that practice even valid for stability ?
on some minor changes i did to my addin for tests, It seemed to work, even without changing the manifest, or re-deploying but I'm not sure it will still work if the project changes from end to end - Like, is it possible to take a whole different addin dll, and simply place it instead of a dll that is already installed - and walla ? does its manifest even acknowledge the content of the dll or simply point to it?
is sufficient when I decide to update my addin ? is that practice even valid for stability ?
Theoritically, you can replace the add-in assembly with a new one. But the host application should be closed at that time to let you delete/overwrite an existing file. Be aware, the Trust center settings in Outlook can be adjusted to load only signed with a digital signature assemblies. In that case your add-in will not be loaded by the host applications.
Consider using ClickOnce for updating add-ins on the fly. See Deploying an Office Solution by Using ClickOnce for more information.
Yes, as long as you do not change the addin's class name.
I've just installed latest Wix v3.7. I created a VS 2010 "Excel 2010 Add-in" project and, in the same solution, a Wix "Setup Project".
Problem is, when I try to reference the Add-in project from the Wix project, it is not there,
I tried a simple console app, and in that case works well.
Question - why the reference to the Add-in project cannot be added? Any fix or workaround?
Thanks in advance!
This is not a WiX problem; you cannot add a reference to VSTO Addin project in general. You could try that with any other (non-WiX) type of project - same result.
The problem is that VSTO project were specifically disabled to be added as references. For whatever reason, hail Microsoft.
Was changed (fixed?) in VSTO 2013 Update 3. After updating VSTO, you should be able to add references now.
http://blogs.msdn.com/b/vsto/archive/2014/08/04/visual-studio-2013-update-3-released.aspx, item #3