I have outlook for mac version 15.34.0 and I created a addin with mailbox version 1.4 in the manifest file.
In compose mode, the addin is not visible but when I change to mailbox version to 1.3 the addin is visible.
In documentation say that Outlook for mac support mailbox 1.4 but this not work.
Any idea?
Any build on or above 15.33 (170225) supports 1.4 in Mac outlook.
Are you using versionOverrides in manifest?
Without versionoverrides support in manifest, compose mode addin's not supported in mac outlook. If you want compose mode addin's then add versionOverrides support in manifest. If versionOverrides support is already added in the manifest, please share the snippet.
Related
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
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.
After installing a few plugins, Outlook does not close. Plugins used Add-In Express version 6.
I found a blog post that says to just change the DLLs to version 7. I changed adxloader and adxregistrator but unfortunately it did not help.
Can somebody help me with that?
It could be one of the new add-ins that you installed that's not properly releasing internal objects. Try disabling them one by one until you've isolated the problem add-in.
I am building a outlook plugin, for the installer, I decided to use NSIS install script. I have place a check for .Net 4.0 and I am able to download and install .Net Framework 4.0. But, I need some guidance regarding downloading and installing VSTO 4.0 runtime if not present on the client machine.
Basically runtimes that can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=20479
I could always check for the presence of VSTO and detect OS and then using hard coded download location which is
for x64
http://download.microsoft.com/download/F/3/9/F395E3C2-28A0-4F0D-9E20-FF4D1ADB08D8/vstor40_x64.exe
and
for x86
http://download.microsoft.com/download/F/3/9/F395E3C2-28A0-4F0D-9E20-FF4D1ADB08D8/vstor40_x86.exe
Download and run the installer.
But, is there any better way of doing this.
Try this, it might help: Microsoft Office 2010 Primary Interop Assemblies Bootstrapper Package 1.0 2010-9-7.
I'm trying to deploy a VB.NET app which is an extension to Excel using VSTO. It works fine in the development environment, but when someone else (without a dev environment installed, just the .NET framework) installs it, they get:
The common language runtime could not be loaded by <application>. Contact your administrator for further assistance.
Google pops up the microsoft help page for this:
http://msdn.microsoft.com/en-us/library/6s0wczt9.aspx
But I've verified that the .NET versions are the same on both machines. For VSTO apps in 2k5 there was a specific vsto runtime library users needed to install -- is there something similar for VS2008 that I haven't found yet? Any ideas besides that?
Thanks in advance!
For VSTO apps built with Visual Studio 2008, The VSTO version 3.0 Runtime is required.
Here is the download page: http://www.microsoft.com/downloads/details.aspx?FamilyID=54eb3a5a-0e52-40f9-a2d1-eecd7a092dcb&DisplayLang=en
Make sure they have the correct version of the .NET framework. If they have .NET 1.1 (or even 2.0) installed, and you're targetting the 3.5 framework, you can get this error message.
We had the same problem. It's all to do with security policy.
There are issues with the security policy for your DLL's when running VSTO projects.
Namely you need to grant 'full trust' to your assemblies. What this means you have to A) sign your projects with a key, and B) register your assemblies as having full trust during deployment (which can be done easily with CASPOL.exe: http://msdn.microsoft.com/en-us/library/cb6t8dtz.aspx)
Its very easy to do. Alternatively you can roll your own security-setting assembly which you integrate into your msi (thats what we did)
Check out this MSDN Article for the full details:
http://msdn.microsoft.com/en-us/library/zdc263t0.aspx
Install VSTO runtime 3.0
Then update it to VSTO 3.0 SP1
also install VSTO_PTExtLibs.exe (PIA extension libs for runtime) if you are referencing these in your project.