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.
Related
Q1. Are there any method to distribute excel office add-in(w/ office.js) in privately?
(Will office.js add-in also be distributed like VSTO's .exe OR .xla/.xlam macro files with password?)
Q2. If I run office add-in server(node.js) on my on-premise server, What will have to be distributed to the end-users?
(I want to hide the core source logic unlike VBA macro.)
I am now developing an excel office add-in. But there seems to be some limitation to deploy to the end-users in my company.(We are now testing environment for pilot, and using office 365 but it is restricted by IT's policy)
When I refer to the official documentation below, the docs says that the way to deploy add-in in privately are Microsoft 365 admin center OR SharePoint catalog.(AppSource is publicly for everyone.)
refer. https://learn.microsoft.com/en-us/office/dev/add-ins/publish/publish
However, it seems that it have to use Microsoft's services or components like SharePoint or admin center. I don't want to use these items because I want to flexibly cope with various environments.
I have also read the article as below.
refer. How to distribute private office add-ins?
But the reply thread seems that the writer couldn't get the appropriate answer what I also want to know.
I want to know the other ways to distribute excel office add-in(w/ office.js) without unveiling my core source logic and what is the minimum materials I have to provide to the end-users(i.g. manifest or something).
Typically, as you have already know, you need to host the add-in's source code on the web server anywhere. The manifest file just refers to the place where the sources are stored. And the single file which should be provided to be able to side-load add-ins locally is the manifest file. Everything else is hosted under your control.
Due to the nature of the web technology you can't hide the source code from users. The add-in acts like a regular web page. The best what you could do is to obfuscate your code.
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.
Do any of you have advice on methods for deploying an office VSTO addin, especially Excel, that makes it easy to update and deploy the document as well as the addin.
I have a document level addin for Excel 2010 that I created using VSTO. I currently deploy it using click once. However, this has a few problems. The first problem is that I publish it to ftp then users install it from my website. Since the document and addin are downloaded from the internet, I obviously have trouble getting proper permission for the addin to run and the document to be trusted. Currently I just have users manually adjust permissions and grant access when the solution is installed. That part works and is fine, but if any of you have suggestions on how to automate this that would be great.
The second problem, the main one I am wanting help with in this post, is deploying updates. I generally like using clickonce because of its ease of installation and automatic update features. The solutions I develop are used in rapidly growing fast changing companies, which means I am often making updates. Click once makes it easy enough to update the "code" or addin itself. I just have it automatically check for updates when it is started, and if there are updates it will prompt the user to download them. But what about the document? My solution doesn't only include the code. It also includes the highly customized Excel workbook.
When the solution is initially installed a copy of the workbook is just downloaded to the local computer. But what about after it is deployed to dozens of computers? Does a document level change (adding a column for example) mean going to each computer and downloading the updated workbook manually?
Surely there is a better way to automatically deploy updated versions of the workbook. Any suggestions?
Here are a few ideas I thought of:
Use some installer other than clickonce. Any suggestion on one that allows easy automatic updates?
Somehow package the workbook as an application resource. I have actually done this in some situations, but not in cases where the document itself included a VSTO addin.
Related to the previous idea. Make a "wrapper" project that includes the workbook & VSTO addin. Then the addin would be launched by clicking on a regular icon on the desktop, which would download the workbook (if an update was needed) then open it in Excel. I would prefer that method of launch over simply opening the workbook anyway.
Note: No user data needs to be preserved in the Workbook when an update is done. The old version could simply be overwritten by the new one. The workbook gets all its data from an SQL server.
You could use a Visual Studio Setup Project which leverages Windows Installer. See this deployment walkthrough guide on using VSTO 4.0.
In Visual Studio 2012, support for Setup Projects is being deprecated in favor of InstallShield LE which is another alternative.
We have a requirement to store documents in SharePoint Online as people copy files to a shared network directly.
Is there a way of automating this? I was thinking of a windows service which will poll the directories, find any changes like new subdirectories or new files, then upload them to a SharePoint Online document library.
You don't have to poll if you use a FileSystemWatcher inside your Windows service for real-time notifications.
http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx
However, if your requirement is 100% accuracy, you will need to build in some sort of tracking/checksum mechanism to make sure that every document was 1) detected and 2) successfully moved to SharePoint.
You may want to have your service check the delta every time it starts up, and then subsequently only respond to FileSystemWatcher events.
EDIT: Per Tony's question below, here are some additional thoughts on getting files to SharePoint.
First, try a simple test.
1) Copy the URL of a document library within the BPOS SharePoint site. Make sure you're on a machine that has the Office Online sign in app on it.
2) Open Notepad. Type some random text.
3) Click on File -> Save As.
4) Paste the URL.
5) Attempt to save the file.
This works great on "regular" SharePoint (done it many times). If this works with BPOS, it opens up several options.
File System Replication to a SharePoint Online or Office 365 document library is planned to be released with the "Cloud Connector for Office 365". With the current version database content is supported only, but bi-directional with V2.0
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