I am confused about Office Scripts and Office Lab.
Both can run javascript in Excel, but it seems the code can't be shared in them.
For Office Scripts, some code like
function main(workbook: ExcelScript.Workbook) {
// Set fill color to FFC000 for range Sheet1!A2:C2
let selectedSheet = workbook.getActiveWorksheet();
selectedSheet.getRange("A2:C2").getFormat().getFill().setColor("FFC000");
}
For Script lab, the code is
await Excel.run(async (context) => {
let sheet = context.workbook.worksheets.getActiveWorksheet();
sheet.tables.add("B2:E5", true);
await context.sync();
});
The workbook are different in ExcelScript.Workbook and context.workbook
They’re extremely different but there is an element of perceived cross over.
The script lab is in place to help you with the process of building Office JS add-ins but it's not the complete solution. You need to build the add-ins using the SDK's Microsoft provide through an IDE like VS or VS code. It's the cross platform mechanism for building add-ins that work on Excel for web, Windows and Apple platforms.
Office Scripts provides a mechanism for writing Typescript functions that are then able to be executed from PowerAutomate flows.
Also, with Office JS, you can create a fully functioning action pane with HTML/CSS, etc. that your user can interact with. The current extent that Office Scripts provide is a button with script behind. It's really more of an interface mechanism that the user wouldn't typically interact with. They're really powerful when you consider you can mix and match the inputs and outputs with other actions in PowerAutomate.
This is a direct quote from the documentation.
Office Add-ins are cross-platform. They work across Windows desktop,
Mac, iOS, and web platforms and provide the same experience on each.
Any exception to this is noted in the documentation of the individual
API.
Office Scripts are currently only supported by for Excel on the web.
All recording, editing, and script management is done on the web
platform.
While the Office JavaScript APIs for Office Add-ins and the Office
Scripts APIs share some functionality, they are different platforms.
The Office Scripts APIs are an optimized, synchronous subset of the
Excel JavaScript API model. The major difference is usage of the
load/sync paradigm with add-ins. Additionally, add-ins offer APIs for
events and a broader set of functionality outside of Excel, known as
the Common APIs.
An add-in compared to a flow function are very different from a usage perspective and so is the development process. Also, you host your add-in on a web server somewhere when you build it using Office JS whereas with Office Scripts, it's all done for you. The scripts are stored in your OneDrive and the platform has the application model for execution, you don't reference and use that SDK in a self contained project like you do for Office JS.
Some resources to reference ...
https://learn.microsoft.com/en-us/office/dev/scripts/resources/vba-differences
https://learn.microsoft.com/en-us/office/dev/add-ins/overview/explore-with-script-lab
There are two different APIs: Office.js and Office Scripts. Office.js has APIs available on platforms other than Excel (e.g. Word, OneNote, etc.). Office Scripts is currently only available for Excel.
ScriptLab is an add-in meant for exploring the Office.js APIs. While you can try to use it for automation, it's not meant to be a development environment. You can however experiment with the API, create custom functions, etc. You can later create more sophisticated add-ins using an Office Add-in creator like Yeoman generator for Office. Add-ins would then be deployed to a server where they could be utilized on any platform supported (PC, Mac, Web, etc.)
Office.js is more suited towards traditional developers. To develop add-ins, in addition to TypeScript, you may also need knowledge of HTML / CSS. In terms of JavaScript / TypeScript, you also need to know about promises or asynchronous concepts
Office Scripts is a simplified API. It is actually built on top of Office.js. It does not require knowledge of HTML / CSS, promises, asynchronous concepts, etc. It also does not require deployment to a web server. Because it's simplified, the APIs actually end up being different. But overall the APIs aren't too different. If you're looking to do relatively simple automation and don't want to deal with the overhead of developing add-ins, Office Scripts are a good choice. It's also a good choice if you want to do simple scripting to integrate with PowerAutomate.
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 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 have read the entire VSTO documentation to start with and skimmed over most of the Office Add-ins (office.js) documentation on MSDN but not found the answer to my question.
Could you please provide me with an answer and also, if possible, please point me to the page on MSDN that answers my question?
Question
In a scenario where the client computer does not have Microsoft Office installed, and is using a browser to access Office Online, and he loads an Office add-in written using Office.js, in such a scenario, where is the computer that hosts the COM objects and the Office process they reside in?
Here is my understanding of the elements involved in using Office.js add-ins:
There's the Open XML document that has the data. This is just dead-meat. It had to be loaded into a process.
Earlier, that process used to be the unmanaged WINWORD.EXE (or EXCEL.EXE or POWERPNT.EXE or another office application) process.
Now, with office.js, when using Office Online, i.e. the Web client, the unmanaged Office process still has to be allocated in memory in some computer? Basically, that's the core of my question.
My guess is
that it has to, and that the process may be run remotely on a
server. The document itself may be hosted remotely, which isn't a
big deal but the process, too, is required and in the case of Office
Online, the unmanaged office process is run on a remote computer. It
is this assumption I want to confirm or invalidate.
There's the client UI. This used to be a mesh of unmanaged C++ code within the office application and managed UI created by .NET using VSTO and Windows Forms or WPF. Now, with Office.js, this is done using HTML/CSS/JavaScript and can be loaded by any kind of a client (desktop/Web).
The process hosting the document and providing the underlying Document, Bookmark, Range et al objects. My question is -- for Office Online clients that do not have MS Office installed on the client computer, where is this process now if they use Office Add-ins written using office.js?
Am I wrong in assuming that the JavaScript API for Office Add-ins merely calls into the existing Office COM infrastructure we already know about? If I am right, then where is the machine that hosts the Winword.exe (or whichever Office application) process?
To answer the question of where the code is executed: There are no "COM" objects per se (the new wave of Office.js APIs is not based on the VBA COM objects, at least not directly). But there is indeed a backing server that has the document open and in-memory. In the case of Excel, the Excel Online front-end is a fairly "thin" layer, and almost all operations are executed by the supporting server. That server doesn't run EXCEL.exe directly, but it has a web service that is kinda-sorta-like Excel (and that shares a lot of the same underlying C++ code), which runs in a "headless" mode, one instance per document. In the case of Word, on the other hand, Word Online has a lot more business logic that it can execute locally, and so a lot of the operations are executed on the browser and sync back up to the server at idle time (much like end-user operations), but there is still a backing server that serves the appropriate data to the Word Online front-end, and that processes some operations (e.g., range.getOoxml(), or image.getImage()).
Hope this helps.
Office Web Add-ins (office-js) are web apps that leverage a specific library (office-js) to facilitate communication between the add-in and the host application.
As these add-ins are simply web apps, they work across the various Office platforms (Windows, Web, Mac, iOS). For browser based Office editions, add-ins are surfaced in an iframe. For native editions they are hosted in an embedded browser (IE11, Webkit, etc. depending on the platform).
Add-ins consist of two components, an XML manifest and the web app. The manifest can be loaded from a number of locations from directly side-loading, to a network share, to the Office Store. The web app is hosted wherever you would normally host your web apps (I recommend Azure but then I'm a bit biased). They are never hosted by Microsoft directly.
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.
I am wondering if it is possible to pass data from an ASP.NET MVC controller to Microsoft Word 2013 Template, using an instantiated Host Item, and bind it to content controls within the template.
Ideally I would like to pass the data to the ThisDocument class and have the data applied to the template's databindings, however I cannot find how to instantiate and use the ThisDocument object after I have created an interop instance of the Word template.
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. You can read more about that in the Considerations for server-side Automation of Office article.
Consider using the Open XML SDK, see Welcome to the Open XML SDK 2.5 for Office for more information. Or any other third-party components designed for the server-side execution.