We have a custom Outlook VSTO add-in. We publish to a location which installs based on version, and it has worked perfectly for years. For some reason, the new version we pushed today is not running properly. It installs fine, it appears to be running (i.e. shows in the list of Add-Ins, has delays ignored, and shows as active) but the icon that should show up in the ribbon for a meeting is not appearing. It does work on the developer machines. No errors are logged anywhere, including Application Event Viewer. The install package does seem considerably larger, but there are no massive upgrades, and the machines with the issues have .Net 4.8 as do the development machines.
but the icon that should show up in the ribbon for a meeting is not appearing
By default, if a VSTO add-in attempts to manipulate the Microsoft Office user interface (UI) and fails, no error message is displayed. However, you can configure Microsoft Office applications to display messages for errors that relate to the UI. You can use these messages to help determine why a custom ribbon does not appear, or why a ribbon appears but no controls appear. See How to: Show Add-in user interface errors for more information.
Also you need to make sure that images are available on the end user machine.
Related
I have an Add-in I have written for Microsoft Outlook. The Add-in runs in a task pane. I have a button on the html in the page that opens a new window using Office.context.ui.displayDialogAsync. This button works fine in the web client, but when clicked in the full Outlook client, a window appears and disappears in a split second. This Add-in was developed outside VS so not sure how I can debug apart from in web client, which not does have the issue.
The domain is the same, and the domain is in the appDomain of the XML manifest. The URL is also https.
Does anyone have any ideas, have I missed something that says this isn't available in full client and only available in web client?
About Outlook version:
Version 2102 (Build 13801.21004 Click-to-Run)
Microsoft Office for Outlook 365 MSO (16.0.13801.21002) 64-bit
If I clock Office Updates, it tells me Office is up to date.
Update
I have another machine with Outlook installed, and I have discovered the dialog opens fine on the full outlook client. Looking at the version for that version of outlook (logged in to the same Office 365 account), the version shows as:
Version 2110 (Build 14527.20226 Click-to Run)
Microsoft Office for Outlook 365 MSO (Version 2110 Build 16.0.14527.20168) 64-bit
So it looks like maybe the earlier build had an issue in Outlook?
Would you like to share a screen recording in the machine where the API is not working?
Besides, you could also try a test add-in with this: Manifest.
It's an app command so you can click "Show Taskpane" first, and then click "launchDialogSameOrigin" button in the taskpane. You can observe whether the dialog is working correctly in this add-in.
Thanks.
I work on an add-in for Microsoft Outlook, and recently we’ve received reports from some users that they can no longer click on buttons in the taskpanes of add-ins. Other add-ins, not just ours, have been affected by this issue. Affected users can still open the taskpane without issue. Our taskpane web view loads correctly, but then any clicking inside the taskpane has no effect. We are not seeing console errors when this happens.
To help narrow things down further: we’ve seen this issue occur in Outlook 2019 and Outlook for Microsoft 365 MSO with Office 365 accounts so far. We’ve seen this issue happen when the taskpane is opened from Compose view. One affected user was using Outlook 2019 version 16.0.13127.20266 (32-bit). Affected users have been running Windows 10, version 2004. A team member was able to reproduce the bug by updating to version 2004, but the bug disappeared for them after a subsequent system update on the same version 2004.
Has there been any recent change to add-in taskpane behavior that could be causing this issue?
This issue was fixed, and the fix should be available in Windows build 19043.1266 or later. Note that it is the Windows Build that matters, not the Office build.
We are seeing the same thing since updating to Windows 10 build 2004. For us, the add-in task pane freezes when the user tries to reply to an email (which is also compose view I guess).
Would be good to get an update on this as it is breaking the add-in for our users.
We are using Outlook Version 2009 (Build 13231.20200)
This is Outlook for Microsoft Office 365 MSO (16.0.13231.20146) 64 bit.
I have notice this error happens for ALL modern Outlook Office Add-ins. Searching the net I can also see that many other Modern Outlook Add-ins are having the same issue. We know that this is an Outlook Client issue. You never get the error on OWA.
I have also seen that Microsoft are suggesting
Open Internet Explorer
Click Tools
Click Internet Options
Click Security tab
Select Internet Sites zone
Select Enable Protected Mode (make sure box is un checked)
Click OK
Restart Internet Explorer and Outlook
However, we cannot ask customer to do this. Many are not even using IE. And it doesn't work most of the times!
In our case the Add-in service is running on Azure. We have enabled application insight and are monitoring failures on a daily basis. Our service is running on 20% of the avilable capacity. I feel that we have done all that we could. We are stock! and very frustrated.
Logically, when the Add-in works with no error in OWA, and only fails in the Outlook client this can only mean the error is in Outlook or windows or.... meaning it is a Microsoft error.
This error is by-design for add-ins in Outlook clients that are rendered using IE and do not have Protected Mode enabled. Protected Mode is a security feature when using IE, and it is strongly recommend that it be enabled while using add-ins.
If you do not or cannot enable Protected Mode, a possible workaround is to upgrade to a newer Windows and Office, so add-ins are rendered using Edge Webview instead of IE. Details about what versions that Webview are supported can be found here.
I've built and deployed an Outlook 2016 VSTO plugin and built an installer for it using the following walkthrough - https://msdn.microsoft.com/en-us/library/cc442767.aspx. The installer has been compiled for x86 and x64 architectures (two separate installs).
However, I'm seeing a variety of different issues when I install in different environments.
In a Windows 7 (x64, Office x32), the plugin loads as expected and works perfectly.
In a Windows 7 (x64, Office x64), the plugin installs, the LoadBehavior is correct, the plugin is loaded in Outlook but it is never displayed? I have tried to disable all other add-ins and still it doesn't show up?
I have tried using the suppressed alerts - How to troubleshoot a VSTO addin that does not load? - but this has not yielded any useful information at this moment.
Some of these peculiarities extend into Windows 10 itself.
What I'm trying to ascertain is why some environments the plugin goes in smoothly and in others why it fails or worst, faults. Are there other keys I need to look at?
Thanks
There are a lot of pitfalls why you may not see the plug-in in Office applications.
The very first option I'd suggest checking - UI errors. By default, if an VSTO Add-in attempts to manipulate the Microsoft Office user interface (UI) and fails, no error message is displayed. However, you can configure Microsoft Office applications to display messages for errors that relate to the UI. You can use these messages to help determine why a custom Ribbon does not appear, or why a Ribbon appears but no controls appear. See How to: Show Add-in User Interface Errors for more information.
Second, make sure that you included all the required prerequisites to the installer. Sometimes the plug-in can't run correclty because any of the dependencies is missed. Or you just use platform-specific assemblies...
Third, make sure no exceptions are fired at startup.
Below you may find some helpful articles:
Troubleshooting COM Add-In load failures
Resolving performance issues with loading Office add-ins (VSTO add-ins or Shared add-ins)
Thanks for the info - the end result issue ended being a combination of registry keys being deployed to the wrong location for x64 platforms on an x86 Office install.
The solution was to cover my bases with both registry hives to ensure things loaded as expected.
I am willing to develop an Outlook add-in for both, the web and the desktop version. My questions are:
When I upload a new version of the add-in, is it automatically updated (per default) in the users' devices / outlook web accounts?
Is it the same add-in for both, web and desktop, uploaded to office store?
If you are only updating the source code of the add-in (HTML, JavaScript, CSS) on the web server where you host it, then all users will get that right away since like Dmitry explained, Outlook will download the page like a browser would download it. So you should be careful updating the page of the production add-in - users will get the updates right away (although keep in mind that user's system/browser may cache previous version of the page for some time), so if you break the page or functionality of the add-in, users will get affected immediately, which may result in negative reviews for your add-in in the Office Store.
If you are updating the manifest XML file of the addin, then you need to publish new version of it to Office Store. Once it's published, that new version will automatically be updated for users who already installed an earlier version of the add-in. This automatic update will happen after they login to any of their Outlook clients that support add-ins.
Yes it is the same add-in for both web and desktop - that's the beauty of the new Office add-ins!
Hope this helps.
Web addins are never even stored locally, (desktop) Outlook downloads the addin source code every time it starts up.