I'm currently running Windows 10 with Microsoft Excel 2016 MSO (16.04266.1001) 64-bit. I'm under the impression that that is the version installed via MSI.
Over the course of the last few months I've implemented a React-based Excel add-in using the Excel Host APIs. Per the Excel JavaScript API requirement sets document available at the Office Dev Center, that build appears to contain the "ExcelApi 1.1, WordApi 1.1, and common API" requirement sets.
As of yesterday, I am no longer able to access the Excel host APIs through JavaScript or through the F12 developer tools (window.Excel === undefined). It appears that all the functionality under that had previously existed under that namespace has become unavailable.
It appears that (among other scripts), the office.js script loaded from the CDN now requests and embeds Excel-15.02.js for the add-in.
I do not know the version of Excel-*.js that was being embedded before yesterday, but after perusing the contents of both Excel-15.02.js, Excel-winrt-16.00.js and other versions available on the CDN, I suspect that it was a later version than 15.02.
For the record, both of the following runtime checks return false - I say both, because "API" is capitalized inconsistently in the documentation available at dev.office.com.
Office.context.requirements.isSetSupported("ExcelApi", 1.1); // false
Office.context.requirements.isSetSupported("ExcelAPI", 1.1); // false
Please advise; best regards.
I am investigating the issue. A few questions:
You mention that the files being loaded include Excel-15*.js files. How are you seeing this -- is it through Fiddler, or through a debugger? If you can send a Fiddler trace, that would be really useful (a Fiddler trace may contain some sensitive info, so you may want to scrub it -- and feel free to send it to me directly rather than posting it here online)
If you browse to https://appsforoffice.microsoft.com/lib/1/hosted/office.js in a browser, what is the version number that you see at the top of the file?
If you are comfortable deleting your IE cache: could you see if the issue continues to repro even after you've cleared the cache?
Feel free to reply here via comments, or as updates to your questions, or to email me directly. My email is my full name (separated by a dot between first and last) at microsoft.com.
I will be updating this answer as I have more info.
Related
I am developing an add-in for Word, Excel and PowerPoint. I need to fetch the version of the add-in installed in client machine. I can see the version under 'Security Info' but I need to get it in my script at runtime.
Is there any OfficeJS API to fetch add-in version or get 'Security Info' programmatically ?
Have a look at this question. There isn't currently an API to get the version of the add-in from the add-in manifest.
If this solution described doesn't meet your needs, please head over to Microsoft 365 Developer Platform and post a request for the API team to consider. It will be helpful, if you provide more details on why getting the version information from the manifest is valuable for your use case.
The Office JavaScript API (OfficeJS) doesn't provide anything for that. Typically the version of Office add-ins is specified in the add-in manifest file where you can't access it from JS until it is hosted with a web app. If it is uploaded to the same place/server with your web app and you know the exact URL you may try to fetch the content and read the version from there. Otherwise, you have to define the version in the JS files or pass it as an URL parameter like Michael described.
If you find it inconvenient (as I do) you can post or vote for an existing feature request on Tech Community where they are considered when the Office dev team go through the planning process.
Hi allHaving an issue with an add-in I developed for Outlook using the newest Office API set of 1.8. I added the requisite <SupportsSharedFolders>true</SupportsSharedFolders> to load the plug-in on the ribbon of the Shared Calendar portion of the Appointment tab and it works on all instances of client/OWA except Windows.
In Windows the system does not show any loading errors, issues from the app, etc. but does not load. While in the OS X client the system works as intended. Loading in OWA works as well, but just not in Windows.
I can provide the full manifest though the needed portion should only be the "SupportsSharedFolders" being enabled to get it into the system. Anyone else having this problem?
Thanks!
All for whomever might be running into this same issue:
The 'fix' for this was making sure the versioning of Outlook matched the minimum of version 1912 on the Monthly track. Any less, 1908 was not working, the system does not load the most current Outlook/Office API 1.8 so does not recognize the Shared Calendar access for add-ins.
My company uses a SharePoint site for our department where we share resources and documentation. We currently have a primary Excel sheet linked that contains a massive amount of our day to day info and our most common hurdles and pertains to about 80% of our workflow. This was created before the company switched (recently) to Office365 and the web based applications vs the standalone programs. Now it is not letting anyone open the the sheet because it is still trying to open in the Excel program and not the web app.
We previously used Office '13 and there was never any issue. The link is meant to open the Excel sheet right up in a read only capacity and not save the program because the content is being updated regularly with new information and regulations. With the "upgrade" from the older version of Office to the 365 web based standard version this link no longer opens the file directly, it saves to the PC and then needs to be loaded to the web app from the saved version which completely negates the ability for it to be dynamically updated. Inversely, we could import that into One Drive and update it to the new system and set the link to the view only shareable link but that would take an excessive amount of time to reformat and edit on top of everything else. If that is how we need to do it then that is how we need to do it, but is there anyway to just update the link already in the system so that it can allow the file to be opened in the web app as well as the stand alone for those not upgraded yet or with the advanced version (managers) that still uses the programs and not the web apps?
I expect the file to be able to be opened in Office365 Excel web app read only as opposed to being saved to the local machine and if possible also be opened directly in the standalone Excel program for those using the 365 Advanced version or who have not yet completed the upgrade process that the company is currently rolling out.
Thank you for your time with this.
We solved this by simply upgrading the whole department and to the Office 365 Advanced version circumventing the entire issue, thank you for your time regardless.
I am developing an Excel add-in. My local version of Excel is running the latest so I have access to all of the most recent API calls. However, I want to be able to test the experience (and work around potential API holes) for a user that has a different version.
As an example, I am making use of the getRangeOrNullObject call which became available in v1.4 of the API. Is there any reasonable way to simulate using an older version? I want to be able to handle a bad range without making use of getRangeOrNullObject in a "real" environment.
I have tried pointing to a specific version, eg:
https://appsforoffice.microsoft.com/lib/1.1/hosted/office.js
However that seems to load the most recent. Other versions (1.2, 1.3) are a 404.
From the Office Dev Center:
Specify Office hosts and API requirements
Your Office Add-in might depend on a specific Office host, a requirement set, an API member, or a version of the API in order to work as expected. For example, your add-in might:
Run in a single Office application (Word or Excel), or several applications.
Make use of JavaScript APIs that are only available in some versions of Office. For example, you might use the Excel JavaScript APIs in an add-in that runs in Excel 2016.
Run only in versions of Office that support API members that your add-in uses.
This article helps you understand which options you should choose to ensure that your add-in works as expected and reaches the broadest audience possible.
For a high-level view of where Office Add-ins are currently supported, see the Office Add-in host and platform availability page.
See full article at the source.
Related links:
Microsoft Docs : Usability testing for Office Add-ins
GitHib : NamedItem Object (JavaScript API for Excel)
GitHub : Excel JavaScript API requirement sets
Microsoft Docs : Specify Office hosts and API requirements
We have a weird intermittent problem with saving from Word 2007 to our SharePoint 2007 (MOSS) document libraries that gives a dialog box that never goes away - it is titled "Content Types" and the message "Getting list of available content types..." with a green progress-type bar that keeps scrolling. It happens a lot on our training server (self-contained virtual machine with separate SQL Server) but more worryingly is happening on our live production server (which is in a medium server farm arrangement - web application server, another server for search/indexing and a SQL Server). All servers in the farms are 64 bit.
It is strangely random - the user has to kill Word 2007, then they recover their document and try to save to the same document library and it saves without a problem.
It happens more on the training server than the live server. The live web application server rarely goes over 20% CPU (usually around 5%) and memory peaks at 2Gb of the available 4Gb (usually at 1.5Gb) so I don't think its a resources issue.
The document libraries are customised and deployed using Features in a Solution. The only content type in them is the standard Documents content type.
Update We opened this with Microsoft as a support issue and it is a known issue that is targeted to be addressed in a Cumulative Update hotfix package for SharePoint in February 2009.
Edit Copied the above response to an answer so this question could be flagged as answered.
I have encountered this issue as well. Do you know if it was corrected in MOSS Service Pack 2? Do you have a KB# or other ID from Microsoft which references this problem?
We opened this with Microsoft as a support issue and it is a known issue that is targeted to be addressed in a Cumulative Update hotfix package for SharePoint in February 2009.
Edit: As at 27 January 2009 we have the test patch so it looks like the official patch is set to be released on time.
Edit: This problem was fixed by the February Cumulative update which is also part of SP2:
http://blogs.msdn.com/sharepoint/archive/2009/04/28/announcing-service-pack-2-for-office-sharepoint-server-2007-and-windows-sharepoint-services-3-0.aspx
However, you also need to patch Word for it to be effective; that patch is available here:
http://support.microsoft.com/?id=962872
That is for Word 2007, other versions may need other patches.