We have created Outlook Ribbon Webaddin. It is working as expected(ribbon Addin) and loading in top ribbon place. But for some customer, it is loading as contextual Addin.
Manifest URL : https://www.backflipt.com/app/addin/Backflipt-Beta.xml
Outlook diagnostics info :
{"host" : "Outlook", "platform": "PC", "version":
"15.0.0000.0000"}
Is there any way outlook configuration affects manifest loading way?
Check the below image(blurred for security reasons) :
Green color section is the plugin which is loaded as contextual addin
Seems it is not an issue with outlook mail box version or client
version. I can see Cisco webex is installed in his ribbon. If it is
because of version, then he should not able to install any in ribbon
right.
Based on the version of Outlook that you posted in your question (15.0.0000.0000), the reason it's showing up in the horizontal bar, is because that Outlook client is significantly out of date. Please update Outlook to 15.0.4805.1000 or higher.
Please also make sure you have the following updates downloaded and installed as well (they are all required):
https://support.microsoft.com/en-us/help/3114816/march-8-2016-update-for-office-2013-kb3114816
https://support.microsoft.com/en-us/help/3114828/march-8-2016-update-for-office-2013-kb3114828
https://www.microsoft.com/en-us/download/details.aspx?id=51285
This happens generally for customers who are using older version of outlook ,most of the time upgrading outlook to latest/newer version will solve the issue
Related
I am using Outlook 2013 application to test the Outlook add-in I am creating. At the moment, when I click a button on my add-in, it is just saying App Error and I don't know what is causing it.
Is there a way for me to debug my code to see where the error is coming from?
I depends on your windows version, have a look here.
For Windows 10:
Launch the F12 development tools that corresponds to your version of Office:
For the 32-bit version of Office, use C:\Windows\System32\F12\IEChooser.exe
For the 64-bit version of Office, use C:\Windows\SysWOW64\F12\IEChooser.exe
I am creating an Outlook Add-in using Office js libraries. I was using the option to attach the debugger to debug my javascript application. But it seems that after an Outlook update the option is no longer available. I have tried reinstalling Office but dit not help. Also i created a new Add In with the default functionality and this has no option to attach the debugger. When i click with the right mouse I see no options. Do i have to enable it in some new way ? Has somebody else seen this problem ?
Beginning with Office 365 version 16.0.11629 and Windows 10 version 1903, Office Add-ins running on Office 365 for Windows will use a Microsoft Edge WebView as the runtime.
The Microsoft Edge WebView performs much better than Internet Explorer and features enhanced compliance with modern browser standards including support of the full set of HTML 5 and ECMAScript 2015+.
We recommend that you download the Microsoft Edge DevTools Preview for debugging.
link
I have created an add-in for outlook but I cannot get it installed on one person's computer.
Here is the message she gets:
I am posting this on stack as opposed to another site because we are the developers so it might be a development issue.
Here is what I have tried to get rid of this message:
exiting outlook.
uninstalling plugin from control panel.
rebooting computer.
starting outlook and observing that the add-in is gone.
install the add-in using the setup.exe that is generated by visual-studio
observe that add-in is not active and that the error message above is displayed.
This add-on works on several other people's machines.
What is different for this person is that she was the first to have it installed so she had a version that did have a startup issue that I would expect this error.
I suspect that somehow outlook is "remembering" the add-in rather than the add-in is still failing.
Two questions:
What can I do to get it installed?
What can I do to detect this in the add-in so I can report it automatically?
Set your addin's key to 1 in
HKCU\Software\Policies\Microsoft\Office\16.0\Outlook\Resiliency\AddinList
and
HKCU\Software\Microsoft\Office\16.0\Outlook\Resiliency\DoNotDisableAddinList
and delete it from
HKCU\Software\Microsoft\Office\16.0\Outlook\Resiliency\DisabledItems
"16" in the keys above refers to the Outlook version (16 for 2016, 15 for 2013, etc.)
I am working on an Outlook add in and it works fine for all the browsers. However it does not work with Outlook 2016. Initially it worked with Mac, but now it doesn't seem to work with either. It seems like the Office.initialize is never called?
I've searched and tried things for hours but nothing works. Comparing my manifest and initialization to others, I seem to have essentially the same code.
I used the yeoman generator and I am using Office UI Fabric React as my framework. Really at a loss at this point, wondering if anyone has any suggestions or a way to see if any errors are thrown in the Outlook Desktop app?
Update
After much searching and trying things, and starting from scratch, it seems that the add-in stops working as soon as I start using the Office-JS API. Specifically I'm getting the userProfile and the to, from, cc fields from the email Office.context.mailbox.item.
Still unable to find a solution.
When using Office-JS APIs, be sure to call those APIs only after Office.initialize has been called.
Beyond that, there are a few options for debugging add-ins in Outlook 2016. The last section on this page describes how to attach the Visual Studio debugger to the process running the add-in. Be sure to enable Script Debugging in IE options.
There also are a couple of newer options for debugging Office add-ins:
Launch the Visual Studio debugger from a task pane (in Outlook, I right-clicked on the task pane to see this option)
On Windows 10, debug using F12 tools (simple to use, and doesn't require Visual Studio)
For an Outlook add-in running in OWA, just open F12 Developer Tools in any web browser.
I have a VSTO document-level customisation which was originally built with VS2005, VSTO 2005 SE and Excel 2003. In that configuration, I published the customisation from VS2005, copied it to where I wanted it on a user's PC, and ran a tool I have developed which set the CAS policy correctly and used the ServerDocument class to add the customisation to the user's workbook. The user could then restart Excel, open the workbook and the customisation would run. We could just copy a new version of the customisation to the same location and it would be used next time the user opened the workbook.
I've now upgraded to (gasp!) VS2008, VSTO 3.0 and Excel 2007. I've reworked my custom policy tool so that it works with the new version of VSTO. I can still attach the customisation to the workbook, but on first opening the workbook it seems to "install" the customisation into the user's AppData\Local\Apps folder. This then causes considerable grief when we want to update the customisation later. This also changes the value of AppDomain.CurrentDomain\BaseDirectory.
Is there a way in VSTO 3.0 to go back to how we used to work, without installing the customisation to the Apps folder?
As I understand it, Microsoft shifted VSTO in VS2008 to use ClickOnce for deployment and Authenticode for Code Access Security (CAS).
However, you can avoid ClickOnce by appending |vstolocal flag to the _AssemblyLocation custom property value of your customized workbook file. This |vstolocal instructs "VSTO to run the solution from the installation folder" according to this VSTO Team blog post on deploying VSTO add-ins to everyone on a machine
The VSTO loader's change from CAS policy to Authenticode may also effect how you sign your assemblies.