We build an Outloook Addin and are testing it across different platforms.
It works on all the browsers (IE 11, Edge, Chrome and Safari), but not in the Outlook 2016 on Windows 10.
We root cause it, looks like the problem is Office JS API UI.displayDialogAsync() .
It does not open a dialog in Outlook 16 and the addin just hangs in there with the following progress message spinning forever,
[Your Addin] is working onr your [Request]
The closest thing we found on the Internet is this Stackflow post in which the answer says
the oldest Outlook build that supports this API is 16.0.6741.0000.
We are using 16.0.9226.2114, so we meet the requirement.
Here are versions of OS/Outlook and Office JS we use in the test:
OS: Window 10 Home, Version 10.0.16299, x64
Outlook: 16.0.9226.2114, 32bit (Version 1804)
Office JS: 1.1.5-release-next.1 (We download the exact package from GitHub and host it on our server)
Wonder is there any known issue of this API on Outlook 2016? Need some help here, thanks!
We have also been trying to debug Outlook 2016 using F12 developer tools .
But our addin cannot show up in the chooser page, no matter we launch the chooser before or after
we click on our addin. We have tried this on several windows 10 machines, but none of them work. Any suggestions that what we could possible miss here?
Seems to me that you had a similar issue to mine. For me adding the remote domain in the manifest resolved the case. Find and update the following section:
<AppDomains>
<AppDomain>https://your.domain.com/</AppDomain>
<AppDomain>https://auth.com/</AppDomain>
</AppDomains>
Proxy HTML works cause it's loading from your domain and still is viable solution.
Related
My Excel add in with custom functions using a shared runtime was happily chugging along with the IE11 webview, until about a week ago when it stopped working because it started running only on the Edgium webview.
I think the documentation still says the expected webview is IE11 in the shared runtimes page, but the webviews page could be interpreted as saying it's the edge2 webview.
Did anybody else see the same effect? I mean, that's great if it works (My add in has other problems now, and I can't fully test), I just didn't expect it.
It is a feature. See this note from the article Browsers used by Office Add-ins
If your add-in includes the <Runtimes> element in the manifest, then it will not use Microsoft Edge with the original WebView (EdgeHTML). If the conditions for using Microsoft Edge with WebView2 (Chromium-based) are met, then the add-in uses that browser. Otherwise, it uses Internet Explorer 11 regardless of the Windows or Microsoft 365 version. For more information, see Runtimes.
The Add-in was working fine under Internet Explorer 11 and I was able to reliably observe and debug its behavior in Visual Studio 2017. Recently after some automatic Windows/Office updates, I noticed that iexplore.exe was not being used as the host browser. This resulted
in not being able to know what process to attach to for debugging.
At this point, out of desperation I executed the following steps to to set JS_DEBUG:
In a windows power shell window executed command
Get-AppxPackage Microsoft.Win32WebViewHost
The command listed the package information including full package name for Win32WebViewHost , which was
Microsoft.Win32WebViewHost_10.0.18362.449_neutral_neutral_cw5n1h2txyewy
I then executed the following
setx JS_DEBUG Microsoft.Win32WebViewHost_10.0.18362.449_neutral_neutral_cw5n1h2txyewy
After some poking I noticed that WWAHost.exe was being used as the browser. Now the add-in is deploying fine but is encountering strange errors.
Is it possible that the above steps resulted in WWAHost.exe as the browser being used to host the add-in. So wondering how to undo the above setting so Internet Explorer 11 is the browser used by Excel to host the add-in.
You cannot control which browser is used to host the add-in. Office decides that. For details how this is determined, see the article: Browsers used by Office Add-ins.
I was made aware of an interesting situation by my client today. I am sure it is something simple but seems like I can't put my finger on it. Have never faced this issue and Google has not been too helpful.
Problem
On my client's laptop, the Add-In is created with Add-in Express™ for Microsoft® Office and .net. When running the Add-in from VS, the breakpoints do not trigger. I logged in via teamviewer. We created a new test project (Add-in) and added this simple code.
Private Sub AdxExcelAppEvents1_WorkbookOpen(sender As Object, hostObj As Object) Handles _
AdxExcelAppEvents1.WorkbookOpen
MessageBox.Show ("Hello World")
End Sub
I put a breakpoint on AdxExcelAppEvents1_WorkbookOpen and ran. I got the message when I opened a new workbook but the breakpoint did not trigger.
I tested the same code on my laptop and it works just fine.
What has he and I tried
Unregister, Clean + Rebuild, Register
Manually cleaning the Debug folder
Repairing Add-In Express
Uninstalling/ReInstalling Add-In Express
Jumping between frameworks 4.5 and 4.6, 4.7.1
Toggling Tools | Options | Debugging | General require source files to exactly match the original version
Toggling Solution platforms (x86|64|AnyCPU)
Applications
Visual Studio Version: 2019 Pro
MS Office: 2016 Professional Plu 2016
Let me know if you need anything else?
FYI: This has been crossposted at Add-in Express forum I usually do not crosspost but seems like my client is under pressure and has to deliver this project on monday morning.
You can use the method Debugger.Break from System.Diagnostics and observe if you get more information about a plausible unhandled exception. In this case, we get the exception wkernelbase.pdb not loaded and Siddharth found it can be fixed by selecting : Tools->Options->Debugging->Symbols->Select "Microsoft Symbol Servers".
I suppose there's an {excel}.exe.config file in the Office folder. The .config requires all add-ins to use .NET 2.0 (3.0, 3.5).
That would explain the issue: you use .NET 2.0 (3.0, 3.5) while the debugger expects to use .NET 4.0 (4.X).
And yes, Add-in Express is built around the COM Add-in technology, not VSTO Add-in.
I have a client who is asking me to fix an issue they are having with Microsoft Project.
The issue is that they are attempting to open a task list on SharePoint Online via the 'Open with Project' button in the ribbon, but after the alert asking them if they would like to open it in Project 2016 pops up nothing happens.
I have set up a fresh SharePoint environment and tried it at my end, but I get the same problem. There is no error message (as an alert or in the console) and I have wracked my brain and come up dry.
What I have tried:
New SharePoint instance.
Fresh Microsoft Project install.
Looked at the site/site collection features
Multiple browsers (specifically Chrome, IE and Firefox)
The issue is the same no matter what I do.
Has anyone else come across this problem before and, if so, how did you solve it?
Are you using 2016 Click-to-run (C2R) or MSI version? Can you share the build number from winproj.exe?
If you are on C2R version, can you try making the following registry edits (save the following as a .reg file and run it) and see if it helps?
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\Microsoft\Office\16.0\Common\ExperimentEcs\Overrides]
"ofhdegpklv1irq0"=dword:00000000
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\ExperimentEcs\Overrides]
"ofhdegpklv1irq0"=dword:00000000
How to fix this error in SharePoint:
"The list cannot be displayed in
Datasheet view. A datasheet component
compatible with Windows SharePoint
Services is not installed, your
browser does not support ActiveX
controls, or support for ActiveX
controls
It started to days ago, for apparently no reason. ActiveX is enabled on this site and I had everything working fine so far. Not sure what went wrong.
Thanks,
... from IE check out your Internet Options, and look under 'Programs'->'Manage Add-Ons'
When I had this problem it was because an add-on was missing or disabled... * thinks * "Microsoft Office List 12.0" or something.
I was getting the below in SharePoint 2010.
The Standard View of your list is being displayed because your browser
does not support running ActiveX controls.
Turns out the site (master page) was being rendered in IE9 mode and the datasheet supports only up to IE8.
The datasheet mode can be used temporarily by switching the Document mode and the User agent string both to IE 8, or permanently by using the meta tag X-UA-Compatible IE=8.
This is known issue and you have to install the hotfix provided by Microsoft.
The issue is addressed in the below specified link along with the URL for the hotfix.
http://www.himmeltech.com/blog/fix-for-datasheet-view-issue-error-in-sharepoint-2010/
Let me know whether the suggested solution fixes your issue
Please install below data connectivity component to resolve this issue.
http://www.microsoft.com/en-us/download/details.aspx?id=23734
This link helped me and it worked fine. Our environment was Windows 7 64bit and MS office 64bit as well, after installing this connectivity tools, user had a option edit the data sheet view in sharepoint.
I ran into the same issue after updating to Office 365 but remaining with IE 11 and Sharepoint 2010.
Issue:
using a 64-bit version of Office with a 32-bit version of IE
Reference: Technet
Resolution: Installed 2007 Office System Driver: Data
Connectivity Components
Seems like a client/browser problem.. do you have Microsoft Office installed? Did you change security settings in Internet Explorer?
My environment is SP2010 enterprise and after trying several solutions, I realized that the user that could not see the views in Datasheet style was because did not have installed "Microsoft Access" that is required when you are using views in datasheet style. So the solution for me was to upgrade that specific user from Office Standard to Office Professional
For me, I performed the following and it worked for me:
Open Control Panel and open Programs and Features
Find your instance of Microsoft Office and select it
Click change at the top
On the dialog that comes up, click Add or Remove Features and then continue
Make sure Microsoft Access Web Datasheet Component is installed under Office Tools/Microsoft SharePoint Foundation Support
Even if it is showing as installed, click Continue.
Let everything install, close any office programs out, then try again
These steps worked for me.