One of my add-ins, Formula Formatter, works well in Office 365. However, one client told me it cannot be loaded in Office Professional Plus 2016.
Does anyone know what may be the reason? Should we do something special in the manifest xml for Office Professional Plus 2016?
In its manifest, Formula Formatter specifies the requirement set ExcelAPI with a minimum version of 1.2. Per the documentation for that requirement set (https://dev.office.com/reference/add-ins/requirement-sets/excel-api-requirement-sets) your customer will need to be running "Version 1601 (Build 6741.2088) or later". Customers that have a non-subscription version of Office won't have that requirement set.
If you remove the requirement set from the manifest, your add-in would be available on Office 2016 but you would need to ensure that your add-in has a good user experience when they are not present.
Related
On an Intranet web page, I have a link to an Excel document that resides on a network drive, like so:
ms-excel:ofv|u|file:///N:/folder/file.xlsx
This is an office protocol handler described here.
On computers with Office 2019 installed, the Excel document opens with the registered application (Excel) without problems; on computers with Office 2016 I get the following error:
The action couldn't be performed because Office doesn't recognize the command it was given.
I compared the registry keys at \HKEY_CLASSES_ROOT\ms-excel\ and they are basically the same (of course the path to protocolhandler.exe is different).
When I execute protocolhandler.exe on the command line on the computers with Office 2016, I always get the above error regardless of how I try to launch an Excel or Word document (e.g. ms-excel:ofv|u|file:///... or ms-word:ofv|u|http://...)
Versions of Office:
Office Professional Plus 2019 Version 1808 (Build 10382.20010 click-and-run) 64-bit
Office Professional Plus 2016 Version 16.0.5266.1000 MSO 64-bit
Is there any way to make the protocol handler work with Office 2016?
As you can imagine, that exe handles all the different protocols integrated into MS products. Because of this, every variation of office (or windows) need to have their very own version of this file, in order to operate correctly. Which is also why this file comes deeply embedded within the Office product folder.
I Have an add-in that is working on Excel in chrome, excel in Edge, but doesn't work in excel desktop.
Any clues?
Thanks
In the article amitklein gave, it says:
Office will still use the EdgeHTML base for add-ins until a build of Office 365 that supports Chromium is installed on the computer. We expect these builds to ship in 2020. They will likely appear in the Insiders channel in the first half of the year.
I haven't found the Chromium based Office 365 in insider channel so I think the version for now is still EdgeHTML based and Excel uses Edge Legacy.
Excel addin which uses Excel API 1.2. Add-in loads fine in Excel 2016 for Windows and Excel online. Save the file from Excel online and open in Excel 2013, addin fails to load in Excel 2013 with following errors:
When loading the Addin published in Store:
APP ERROR We can't load this app because we could not connect to catalog
When sideloading the addin from trusted catalog:
This app could not be started. Close this dialog to ignore the problem or click restart to try again
I know that Excel 2013 does not support Excel API 1.2. Could you please confirm the recommended way to make sure the add-in loads in Excel 2013?
• Should we use runtime checks using isSetSupported method?
• In such cases, how to debug which line of code is failing in Excel 2013 client?
• Is there any logging that can be enabled to troubleshoot such issues in Excel client?
I tried debugging a default add-in created by VS 2015 which uses Excel 1.2 API in Excel 2013. I added the following requirements set to the Manifest:
<Requirements>
<Sets DefaultMinVersion="1.2">
<Set Name="ExcelApi" />
</Sets>
</Requirements>
The addin also fails to load in Excel (15.0.4849.1003) when debugging using VS 2015. It works fine in Excel 2016 client.
I think there are two separate issues here (though there's a good chance that they're related, and the platform is simply giving the wrong error string. If so, let's confirm, and then I can file a bug to have us fix this).
Excel 2013 does not support the "ExcelApi" requirement set, which is a 2016 addition of the host-specific APIs (same goes for "WordApi"). If you specify ExcelApi in the requirements section of the manifest, as you have above, this will always fail to load in Excel 2013 -- by design. Essentially, you're requesting an API set and marking it as "required" for something that Excel 2013 does not support -- so it has no choice but to refuse to run it.
This is where the runtime check (isSetSupported) comes in. Please see my answer at Neat ways to get environment (i.e. Office version) for more details.
I am not sure what you mean by "how to debug which line of code is failing" or troubleshooting techinques. Essentially, any call to an Office 2016 API (anything in the ExcelApi set) from 2013 will result in a runtime failure...
Hope this helps!
I have a couple of Excel Add ins. If I move to Office 365, will these add ins be available ? Is there any development support(VSTO) for Office 365 ?
I to have been curious about the answer to this, so went looking online. From the following site, I'd say the answer is no. It looks like developing for Office 365 is more along the lines of SharePoint development.
http://blogs.msdn.com/b/donovanf/archive/2011/06/29/office-365-developer-guidance-and-resources.aspx
I have seen advertisements online for products such as this... http://www.ocxt.com/products that look like they could provide a possible solution for taking a vsto application to the web.
I think things have moved on substantially since this question was asked. Microsoft seem to be fully committed to the Add-in approach with Office 2013 and the equivalent VSTO tooling available in VS2012.
The Office Dev Center home page has Office 2013 and VSTO Add-ins written all over it.
This MSDN Blog Post also clearly shows Add-ins are still part of the strategy.
Until the full capabilities of Desktop MS Office are available in a browser, I can't see this situation changing.
If you mean Office 365 installed on client PC then there is no issue with VSTO Add-ins. Our Chem4Word Add-in is using Office 2010 VSTO and happily works with 2010, 2013, 2016, 2019, O365.
If you mean Office 365 on-line then you have to redesign them using the Office 365 Javascript API
I have a site developed in Microsoft Office SharePoint server 2007 and I have installed Microsoft office 2010 on my machine. When I try to access excel file stored in document library. It gives me an error saying that it requires a Windows SharePoint Services compatible application.
It was working fine when I have Microsoft office 2007. So I am confused whether SharePoint is compatible with office 2010 or not...?
Thanks
Sachin
Yes it is compatible and it should work. A number of things could be going on.
The OWSSUPP.DLL may not be registered correctly.
You could register it manually or reinstall
If you have the 64 bit version of office there are some known issues opening data in SharePoint.
http://www.knowsharepoint.com/2010/06/sharepoint-datasheet-view-and-office.html
Windows SharePoint Services Support files may not be installed.
in this case install these through Add/Remove programs. It's in the office tools section of the MS Office application.
If you have some applications that were part of Office 2003 or earlier you may need to uninstall them.