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.
Related
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
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.
I've created a library to pass/get data to/from excel.
To execute in my machine i modified the access permisions in COM+ console.
The thing is that im interested in upload this component to my online server, but there i havent installed excel.
Are there any way to register excel in COM+ without install excel?
Thanks in advance.
Best Regards.
Jose
If your library uses Office Interops to manipulate Excel, then no you can't register Excel in COM+ without installing Excel, since there would be nothing to register against, or interop for that matter.
Even if you use late binding in your code, so that it compiles, you will experience runtime errors if the Excel components are not installed.
"All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended." - http://support.microsoft.com/kb/257757
I had two clients with a save issue in SharePoint.
When they try to save they would get a a very generic error: "Document Could not be saved"
The only way they could get them into SharePoint was by:
Saving to local File System
Using the Upload option from the SharePoint menu
Configurations
Client 1: Vista and Office 2007
Client 2: XP and Office 2003
I was able to fix client 1 by having him Map a Network Drive to the Sharepoint Site.
After mapping the network drive, somehow the OS magically knew about the SharePoint documents folder and he was able to save.
I'm not having the same luck with Client 2.
It won't even let me map the network drive. I get an error (one that I did not take a screenshot of and don't remember the exact wording...sorry). but it was an error trying to map the network drive to the SharePoint site.
So, after some Googling, I had him go to Windows Update and download all the latest patches for his OS.
He claims he did, but is still getting the problem.
Before I do another WebEx and start taking stabs in the dark to try and fix him, I was wondering if any veteran SharePoint users have run into this same issue and what they did to fix.
Or, is there some OS setting I should be looking at that needs to be toggled/modified.
I can access his SharePoint site just fine from several PCs and make modifications and save as necessary.
Did you try running the Microsoft Office Diagnostics?
Start --> Microsoft Office --> Microsoft Office Tools --> Microsoft Office Diagnostics
Let that scan and repair any issues it finds and see if that helps. That tool has fixed similar issues for me many times.