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.
I have always been testing my add-in in Excel 2016 and Excel Online. So I just installed Excel 2013 (version 15.0.4841.1000, which includes SP1), indeed the add-in does not work. But it seems that few things work...
For example, the following example function writes haha in Cell A1 under Excel Online, whereas, it does not anything in Excel 2013.
function test () {
Excel.run(function (ctx) {
var range = ctx.workbook.worksheets.getItem("Sheet1").getRange("A1");
range.values = [["haha"]];
return ctx.sync();
});
}
So does anyone know if JavaScript API supports Excel 2013? If not, many professionals will not be able to use add-ins because they are still with Excel 2013...
PS: I see there are lots of add-ins in office store require Excel 2013 or later or Excel 2013 Service Pack 1 or later. If JavaScript API does not support Excel 2013, how have these add-ins (eg, Stock Connector) been developed?
Edit 1: In my manifest xml:
<?xml version="1.0" encoding="UTF-8"?>
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bt="http://schemas.microsoft.com/office/officeappbasictypes/1.0" xmlns:ov="http://schemas.microsoft.com/office/taskpaneappversionoverrides" xsi:type="TaskPaneApp">
In my Home.html, I have:
<script src="https://appsforoffice.microsoft.com/lib/1/hosted/office.js"></script>
Edit 2: I guess the following setting is equivalent to say the add-in is not supposed to be used in Excel 2013?
<Hosts>
<Host Name="Workbook" />
</Hosts>
<Requirements>
<Sets>
<Set Name="ExcelApi" MinVersion="1.2"/>
</Sets>
</Requirements>
<DefaultSettings>
...
</DefaultSettings>
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
Related
Just now i realized that my Excel Version is missing some functions, e.g. =UNIQUE() or =XLOOKUP(). Also in the tab with the list of all functions these are not available. Other functions work fine though. Is there a way to install these functions manually?
I am using: Microsoft® Excel® 2016 MSO (Version 2112 Build 16.0.14729.20156) 64 Bit
I just tried to update, but it is already up-to-date.
[Sidenote: I am using the German Version, so I am actually missing the functions =EINDEUTIG() and =XVERWEIS() but either or - these functions are missing in my Excel]
Unless you're using Microsoft Office 365 compatible version of Excel, your only other chance might be to sign up with Office Insider, which gives you access to exclusive new content / features as a trial user (whilst unique, filter, let, sort, sortby etc. functionality has been out for some time, there may well be dependencies on this RE: new content). Thanks to Insider I had access to unique functionality long before the Office 365 build was officially launched (about a year before if I remember correctly).
You can do both this and see what version Excel you are on by opening Excel and selecting File -> Account:
I have created an Excel document-level customization in Visual Studio 2017 using Windows 7. The document provides a set of tools for charting and analyzing data that are contained in several worksheets within the document.
I would like to provide the end user multiple versions of this document without publishing each one separately. Each version differs only in the data that will be contained. All the code, classes, subs, and functions would be identical for each version. I was hoping they could
rely on the same assembly.
I tested this by publishing a document (named DocumentA) on a test PC (Windows10) and then copying an additional file (named DocumentB). Trying to open DocumentB in Excel produces the following error:
Could not load assembly "DocumentA", Version 1.0.0.0. Culture =Neutral or one of its dependencies. The System could not find the file specified.
I think I understand why this happens. However, if I save the original published document DocumentA as DocumentB1, I can open the renamed file
with no problem. Not sure why this works and the other case does not. The property settings for assembly name and location were identical for DocumentA and DocumentB.
Is there any type of work-around? Or must I publish each of these additional documents separately?
Thanks!
I would like to provide the end user multiple versions of this document without publishing each one separately.
You need to create separate document level add-ins then. Or you may consider developing a single application-level add-in instead. See Walkthrough: Create your first VSTO Add-in for Excel for more information.
I built an Add-in for Excel using VSTO, and deployed it over...
now i have an updated version (where there are some new Toolbar Controls, a new column, and some bugs fixed in the behaviours).
my problem is that my client was working with the previous version, was filling his Data inside the sheet.
How can I Update the VSTO Add-in, and Migrate the Data ?
thanks for your help
Well it depends on how you created the add-in. An add-in is NOT coupled with any workbook (which is different to document level customization) unless you make it so.
Basically you just change your code, deploy a new version and your client will install it. When Excel is launched the new version will be used so if you have a button on Ribbon, the button now will use the new version.
If you, for any reason, make the add-in tightly coupled with a specific workbook (format) you'll have to deal with it.
So for example, if the new version is now expecting a new layout of data you'll either ask clients to change it manually or write a function that will do that for them.
Example: We have a VSTO Word add-in that does a lot of stuff, the add-in is using a template which has a version like (1, 2, 3, 4 ...) when we change the template (e.g. adding styles, addin shapes, removing shapes, etc.) we also maintain a recursive update method that is triggered on opening a document.
The method is checking the version of the template with the version hardcoded in the code, comparing and if the template version is older will trigger the update functionality (step by step, so from v1 to v2 then v2 to v3 and so on till it reach the latest version)
Hope that helps
We have an Excel 365 Add-In, which is using Document.getFileAsync (because it is the only way to access the complete spreadsheet, without requiring the user to select it).
This API is not available in Desktop Excel (neither 2013 nor 2016).
How we are supposed to handle the MS complaint on Office Store certification, that the App is not running in Desktop Excel?
Is it enough to include
<Requirements>
<Sets>
<Set Name="File" />
</Sets>
<Methods>
<Method Name="Document.getFileAsync" />
</Methods>
</Requirements>
in the manifest?
Testing shows that Excel is ignoring this options (at least when the manifest is coming form a local folder).
Or are we supposed to implement a second code path (with a different UI), that requires the user to select the complete spreadsheet, so that we can export it via getDataAsync for Desktop Excel?
How can find out, if we are embedded in Excel Desktop or Excel Online?
You seem to have a typo in your manifest, it should read
<Method Name="Document.getFileAsync" />
And not
<Method Name="Doument.getFileAsync" />
In any case, I'd encourage you to take a look at Worksheet.GetUsedRange, which allows you to retrieve the range that encompass all the data of a worksheet as in the following sample :
var ctx = new Excel.RequestContext();
var sheetUsedRange = ctx.workbook.worksheets.getActiveWorksheet().getUsedRange();
sheetUsedRange.load('values');
ctx.sync().then(function() {
console.log(sheetUsedRange.values);
});
Now, to answer your question on how to know whether you're embedded in Excel Desktop or Excel online, I'd suggest looking a Michael Zlatkovsky's answer on that matter.
Gabriel Royer
Developer on the Office Extensibility Team, MSFT
I am stuck with a problem
The Requirement is that, there a complex Excel file(XLS) that is used as template; it has Macros and all the worksheets are either locked or hidden. When the user clicks to download it, the follows operation occurs
Unlock a particular worksheet, fill some data # certain cells and then lock it back.
Unhide a worksheet, fill some data # certain cells and then hide it back.
I think there are two options to resolve it (if there are more then please let me know)
Interop libraries / Excel Object Library
OLEDb Driver
I cannot got with the option 1 as excel is not installed on the webserver and I heard that it's not a good option to install MSOffice # webserver.
My question is that can we use OLDb to perform the operations mentioned above OR is there any other option ???
BTW Sharepoint service is also not available :(
Please help!!!!
You could maybe try ExcelPackge.
See this article:
Server-Side Creation of Excel 2007 Files Using .NET 3.0 and Office Open XML
see also:
Office Space - Building Office Open XML Files
Check out this question I asked some time ago for an overview of options. I ended up going with the Aspose library, which I link to in my original post. It's not cheap, but it does the job very simply and elegantly. It even has templating functionality built in (called SmartMarkers, IIRC).
SpreadsheetGear for .NET will handle this and has an API which is very similar to Excel. You can see what our customers say and download the free, fully functional evalution here.