I just got a change recommendation report for one add-in I submitted. It says Your add-in is not working in the Excel 2013 client on Windows 7 with Internet Explorer 11.
When you use the Office.js APIs, you will see that each method is annotated with an API set designation. For example:
These API sets correspond to what versions of Office the add-in will work on. The list of requirement sets, and where they're supported, can be found at http://dev.office.com/reference/add-ins/office-add-in-requirement-sets.
Any of the new Office 2016 host-specific API sets (ExcelApi, WordApi, etc.) are only supported on Excel 2016+ (and Office Online and Mac/iOS equivalents). The API version number (1.1
vs. 1.2
vs. 1.3
) corresponds to updates to the APIs, that were added past the RTM build of Office 2016 (which shipped with 1.1
out-of-the-box). Those updates are available to customers who have an Office 365 subscription (home or business). Customers who bought a disk/MSI product of Office 2016 will only have the original 1.1
APIs.
You can use the requirement sets in two ways. If your add-in 100% depends on a particular API set, you should list it in your manifest file. That way, the add-in won't even be proffered on the "Insert/Manage Add-ins" dialog for Office versions that don't support that particular API set.
On the other hand, if you're only using a few APIs in the set, and could do without (even if it's a bit of a degraded experience), you can do the "light-up scenario". That is, you will list the lowest possible version that you do need, and then use a runtime check to detect whether a particular API set is available.
Concrete example: suppose you have an Excel Add-in that creates a new sheet and outputs data into a table. This requires ExcelApi 1.1
version or higher. Ideally you would also like to be able to set the column widths, but range.format.columnWidth
is only available in ExcelApi 1.2
. You don't want to block customers from using your Add-in if they have an old version -- after all, the bulk of your functionality will still work, even if not optimally -- but you do want to make use of the new APIs. In that case, you should specify ExcelApi 1.1
in your manifest, and then do a runtime check in you JavaScript to determine if you can run the range.format.columnWidth
code. I.e.:
if (Office.context.requirements.isSetSupported("ExcelApi", 1.2 )
{
range.format.columnWidth = 25;
}
For a related answer, see Neat ways to get environment (i.e. Office version)
Excel 2013 supports some things, but there's lots that it doesn't support, including anything using Excel.run().
http://dev.office.com/reference/add-ins/office-add-in-requirement-sets