we have excel js add with custom function support and because of it, this add-in works just in excel office 365 version.
here we met a problem - "npm validate" define this add-in as an add-in for excel 2016, but that is not correct for us.
so the question is - how to correctly set the "requirements" section in the manifest file to define this add-in as an add-in for office 365?
currently, it looks like
<Requirements>
<Sets DefaultMinVersion="1.1">
<Set Name="CustomFunctionsRuntime" MinVersion="1.1"/>
</Sets>
</Requirements>
Custom Functions use separate requirement sets from the core Excel JavaScript APIs. You could refer to this page for Custom Functions requirement sets:
Custom Functions requirement sets
Related
How can I add text to Excel footer using Excel Addin? (Office.js)
The Word case is well documented: https://learn.microsoft.com/en-us/javascript/api/word/word.section?view=office-js#getfooter-type-
However, there doesn't seem to be a similar set of documentation for footers in Excel.
Thanks!
There is a preview API for Excel.HeaderFooter that requires a beta version of Office.js and a custom "Office Insiders" prerelease Office installed in order to interact with Excel headers or footers.
Note
This API is provided as a preview for developers and may change based on feedback that we receive. Do not use this API in a production environment.
Excel JavaScript API requirement sets:
"Please use the latest Office version to try preview APIs (you may need to join the Office Insider program)"
When submitting our addIn we got the following message back:
If you do not support 2013 SP1 because you are using an API only available in 2016/Online, you must put these apis in the requirements tag in your manifest.
Our addIn does not work in Office 2013 since it uses both WordApi and ExcelApi (When opened in Word and Excel accordingly) which is not available in Office 2013.
Therefore we tried to specify in our manifest file that our addIn requires WordApi 1.1 by adding this to the manifest file:
<Requirements>
<Sets DefaultMinVersion="1.1">
<Set Name="WordApi" MinVersion="1.1"/>
</Sets>
</Requirements>
However, when we add the requirement of WordApi then the addIn doesn't show up in PowerPoint and Excel and vice versa.
How do we specify that the addIn is not available in Office 2013 without having to create separate manifest files for each office Host?
If your manifest contains Word API (or any host specific API) then it will not show up in other clients.
If your add-in is designed to work in multiple clients, and requires an API not currently supported in Office 2013, please include these details in the test notes of your next submission. Should the validation team need any additional information to resolve the issue, they will reachout to you at the email address on record to discuss how to proceed.
It looks like you're tag is correct. I don't have a solution but perhaps something to try. I've read that the location of the Requirements Tag matters. I put my requirements tag above the tag.
The article [https://learn.microsoft.com/en-us/office/dev/add-ins/testing/troubleshoot-manifest][1] discusses validating your xml file with office-toolbox. You run the command "npx office-toolbox validate -m MANIFEST_FILE" (see the article for full details). When I run this validation command on my manifest which has ...
<Sets DefaultMinVersion="1.1">
<Set Name="ExcelApi" MinVersion="1.1"/>
</Sets>
</Requirements>```
It returns
```Validation: Passed
Based on the requirements specified in your manifest, your add-in can run on the following platforms; your add-in will be tested on these platforms when you submit it to the Office Store:
- Excel for iPad
- Excel 2016 for Mac
- Excel 2016 or later
- Excel Online```
The key here being that it recognizes that it is only valid for Excel 2016. We've been using this to identify when our tags are working without having to submit to MSFT.
[1]: https://learn.microsoft.com/en-us/office/dev/add-ins/testing/troubleshoot-manifest
I'm currently developing a tool using the Office javascript API. However, I would like to provide an own Excel function (something like =SUM(A1:A5)), which is based on code in C#.
Is there any way to avoid shipping two individual plug-ins from the users point of view? Can I combine both technologies to one plug-in?
If you are only targeting the desktop version of Excel then you can create a VSTO add-in instead of a JavaScript-based add-in. Within this adding you can include the code for your custom functions in the VSTO project and make sure they are correctly registered. One solution could be to create your own MSI-based installer, e.g. using Windows Installer XML (WIX) or Nullsoft's NSIS tool.
With this "classic" VSTO add-in technology you won't be able to target Excel on Mac, on mobile platforms or Excel Online in the browser though.
Yes there is also an alternative solution to creating a desktop C# add-in with VSTO or ExcelDNA as suggested by Dirk.
A javascript web add-in is just a web page with a library : office.js filling the gap between your logic and the office host application.
Why not passing the input to an API written in C# (this can be or not the same server serving the add-in) that will do the calculation ? The javascript will be there only to pass data and set the calculation results in spreadsheet.
I use ILMerge to combine my dlls. You can add it as a post build command so that they are merged on successful build.
Following this thread, I have modified the manifest file of my two add-ins, and resubmitted to the store. Yesterday, I got a mail to say one is approved, and today I got another mail to say the other one is approved as well.
However, I could not find them in Excel 2016 for Windows. Then I go to the web page of the Office Store. I could find the two add-ins, but I see in their page: This add-in requires one of the following applications: Excel 2016 for Mac, that's it, it does NOT mention Excel 2016 for Windows. (I have not checked them in Excel 2016 for Mac, because I have not installed Excel 2016 for Mac).
The follows is the part related to version in their manifest file. So does anyone know how to modify this to make the add-in available in Excel 2016 for Windows, where my add-ins work fine.
Moreover, once I modify their manifest, I should unpublish the add-ins, and then re-submit them?
<?xml version="1.0" encoding="UTF-8"?>
<Hosts>
<Host Name="Workbook" />
</Hosts>
<Requirements>
<Sets>
<Set Name="ExcelApi" MinVersion="1.2"/>
</Sets>
</Requirements>
<DefaultSettings>
<SourceLocation DefaultValue="...Home.html" />
</DefaultSettings>
<Permissions>ReadWriteDocument</Permissions>
Your manifest is correct for enabling an add-in in Excel 2016 for Windows, Mac, and Excel Online.
It's possible that the validation team manually tagged your add-in to not support Excel 2016 for one of the following reasons:
You specified in the description or the "Testing Notes" field that the add-in shouldn't be supported on Excel 2016 for Windows.
The validators found a bug that was specific to Windows. Normally if that happened they would reject your submission at least once first and include an explanation in the report. So check all your previous submission reports for information.
If none of the above are the reason, then there was some other problem during validation, perhaps a bug. On your Seller Dashboard page:
Scroll to the bottom and click Support:
Problem type: App submission and validation
Category: App validation results
Start email (the team with expertise here is in Europe, so the chat/call is likely to be unsuccessful during North American business hours)
Describe the issue briefly/politely, including links to your add-ins, and submit
Is it possible to access Office.context.document.settings from VSTO?
We have an VSTO AddIn that currently writes to the CustomXML in Excel workbooks. We would like to make it Napa/O365 compatible. Since Napa can't read CustomXML parts in Excel we want to write to Office.context.document.settings, hence the question above.
Or is there a better way to share storage between VSTO and Napa in a Excel workbook?
Ron.
The JavaScript for Office API can't be used in a VSTO solution, as it requires a web context. Your desktop add-in solution would have to be ported to use the web-based APIs and tools.