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.
Related
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.
In our organisation a problem occurs when saving Excel files.
Whenever we close a file there is a 50/50 chance that it saves in the location it was already in, but the other times it saves where another file was last saved.
We are all working on a Terminal Server (Windows 2019) using Office 2019.
Did anyone else stumble upon this as well? And perhaps found a solution?
The Considerations for server-side Automation of Office article states the following:
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.
I'd suggest using the Open XML SDK instead if you deal with open XML documents only, see Welcome to the Open XML SDK 2.5 for Office for more information.
I have a Windows service filling cells in an Excel Workbook via OLE Automation.
The save process is not working, the file is never saved. But when done in a GUI app, the save process works.
The service user is an administrator account. I suspect the interaction with the Desktop.
Any idea?
Don't do this. Find another solution. Microsoft does not support or recommend OLE automation of Office software from anywhere but a workstation desktop session. I can't paraphrase any better than what they say directly, so here's the advice (link above goes into more detail) :
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.
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.
If you need your service to store data, a database is probably a good choice. Any users that require the data in an excel spreadsheet could populate their documents from the database. You could even set up template documents to do this automatically.
I had the same problem, run a Delphi software as service, with an administrator user and it gave to me a lot of errors in the read/write process like SaveAs method of Workbook class failed
The solution for read/save was create both folders below:
C:\Windows\System32\config\systemprofile
C:\Windows\SysWOW64\config\systemprofile\
There isn't much sense at all, but it worked.
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.
Is it posible to create outlook meeting on Sharepoint page behalf on current sharepoint user?
I try to create meeting by button click with next code
Application oApp = new Microsoft.Office.Interop.Outlook.Application();
AppointmentItem appointment = (AppointmentItem)oApp.CreateItem(OlItemType.olAppointmentItem);
appointment.Start = DateTime.Now.AddHours(1);
appointment.End = DateTime.Now.AddHours(2);
appointment.Subject = "Some subject";
appointment.Body = "Some body";
appointment.Recipients.Add("user1#somemail.com");
appointment.Recipients.Add("user2#somemail.com");
appointment.Save();
But i get this error, on calling appointment.Recipients
Operation aborted (Exception HRESULT: 0x80004004 (E_ABORT))
When i run this code in console application it works fine. Any ideas?
Thanks in advance
The Considerations for server-side Automation of Office article states the following:
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.
If you deal with Exchange profiles, you may consider using EWS (Exchange Web Services). See EWS Managed API, EWS, and web services in Exchange for more information.