The Office add-in I am working on will be supported only for the Office Online platform. There are configuration to set Host in which the add-in will work, that can be added in manifest.
Is there a similar setting/configuration available in manifest to explicitly mention that the add-in will support only Office Online platform and not Office for Windows, etc.
If you are planning to publish your Office Add-in to the Office Store (which I assume you are, since you added the office-store tag to your question), it must comply with all Office Store Validation Policies.
As stated in section 4.12.1 of that documentation:
Your add-in must work across all platforms that support the methods that you define in the Requirements element in your add-in manifest.
In other words, if your add-in uses requirement sets and methods that are supported cross-platform, then your add-in must work cross-platform.
There are three base conceptions behind Office Add-ins as of:
Security
Resiliency
Cross-platform
Your question fall into "Cross-platform" concept which by the way means the following: "Write once, run everywhere Office runs. Add-ins are currently supported on Windows, Office Online, Mac, and iPad."
Basically what you are asking is against of the main concept for Office Add-ins. This means (unfortunately) it cannot be done as long as Microsoft follow those concepts. There are no any manifest settings to limit online products version only. By the way we would like to have this too as our desktop version of COM add-in is feature reach and robust.
If you require this manifest option you may post your scenario at officespdev.uservoice.com
Related
We have a client that uses SCCM to deploy Excel to their users and according to them, they package other add-ins with Excel so that when it's installed they have access to these add-ins.
We have an Office Add-in (specifically Excel), not the VSTO or COM add-ins, a web Office Add-in.
I've done some research and I'm struggling to find a solid answer as to if it's possible to deploy the add-in with SCCM? So far my deduction is no, but I thought let me confirm with the professionals.
And then is there any other solution on how to deploy the add-in otherwise?
Please note the following restrictions on their end
Locked the Office store, users cannot install an add-in from the Office store
Don't have access to the Admin Center to deploy the add-in
We created multiple powershell scripts that read from word document and extract required information.
Locally on laptop all works fine, but when we deployed on production server.... they dont work.
We run powershell scripts through asp.net web app... that's where any powershell scripts that refers to WORD.APPLICATION are not working
Components we deployed on production server:
operating system: Windows Server 2012
Powershell: Version 5
MsOffice 2010 installed
Asp.net 4.5 all components installed
We have created web application in ASP.NET 4.5 Core where user upload documents and based on certain criteria documents will be searched for specific keyterms. if keyterms found, values will be displayed.
Asp.net invokes powershell script which has all document library code to search through. Everything gets executed in PS script, except where WORD-APPLICATION code is referred.
Has anyone faced any issues while deploying them on server?
Required reading:
https://support.microsoft.com/en-us/help/257757/considerations-for-server-side-automation-of-office
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.
...
Besides the technical problems, you must also consider licensing issues. Current licensing guidelines prevent Office applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office. Using server-side Automation to provide Office functionality to unlicensed workstations is not covered by the End User License Agreement (EULA).
As you can see, the scenario you're trying is officially unsupported, and license wise very expensive, as you officially require an Office license for each user invoking your functionality or for whom you're invoking the functionality.
There is an official Open XML SDK, which will allow server-side processing of the XML-based office documents:
https://learn.microsoft.com/en-us/office/open-xml/word-processing
If that isn't enough, there are a number of 3rd party libraries that provide server-side execution and don't require office licensing, some commercial, some open source:
Aspose: https://www.aspose.com/
NPIO: https://github.com/dotnetcore/NPOI
There are ways to get your code working on the server from an ASP.NET Application. They are officially unsupported, they open up your server to a number of extra security issues, they are very expensive from a licensing perspective and there is no guarantee they will remain working.
I am trying to use Microsoft.Office.Interop.Word in an asp.net core 1.0 application, but its not supported in .net core app
when I try to add reference to the dll I get this error
Error NU1002 The dependency Microsoft.Office.Interop.Word 15.0.4797.1003 does not support framework .NETCoreApp,Version=v1.0.
see the below image.
since its not supported is there a way to work with Microsoft office word files in .net core 1 application?
note that same problem occur when using openxml sdk
Syncfusion File Format libraries for reading, writing and manipulating Word, Excel, PDF and PowerPoint files, will be capable of being used with ASP.NET Core 1.0 from their upcoming release. Please create an thread in their support system to get more details about it.
Note: I work for Syncfusion.
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. Read more about that in the Considerations for server-side Automation of Office article.
As a workaround you may consider using the Open XML SDK, see Welcome to the Open XML SDK 2.5 for Office for more information. Or just any third-party components designed for the server-side use.
I am using .Net Core 1.1 and found this Open XML SDK library to work.
See: https://github.com/OfficeDev/Open-XML-SDK
You will need to get the latest CI build via nuget from this feed:
https://dotnet.myget.org/F/open-xml-sdk/api/v3/index.json
I've successfully created a VSTO Add-In for Outlook 2007 in VS2010, yay! Now comes the deployment part, which seems to be even more arcane.
I need to deploy this Add-In on my company's server, which is running Windows Server Standard, SP2. It has MS Office 2007 on it, and the clients talk to a different Exchange server. The company has thin clients that all Remote-Desktop the Server to access their Outlook.
What would be the procedure for this? There's various articles that Google pulls up on deploying Office Add-Ins, all of which are a tad over my head. My impression is that there are many different ways to install Add-Ins, based on what Office version you have, what VS version you have, what OS you are installing it on, if you want to install for a single user or all users on the server, and various other circumstances. I can't get a clear picture of what to do. The fact that I'm installing on a system with a server/thin-client arrangement possibly complicates things.
Anyway, I can spend the next few days researching how registry keys work and how they affect Add-Ins, learning how to make .MSI packages, exactly how certificates work and if I need one to publish or if I can deploy into the Program Files directory, or if that option in the .NET 4.0 framework even applies to a VSTO Add-In, etc., etc., etc.
There's just a lot of variables and I would appreciate advice that pertains to my exact scenario. Or, barring that, exactly what subjects I need to study up on to know what to do, and links to them.
Edit: I need to deploy to 1 user on the server first, for testing, and then eventually all or most of the users, so help for singular and broad deployment would be appreciated.
The following articles helped me a lot when I first tried to deploy an add-in. Unfortunately my scenario did not included server/thin-clients, I used the MSI only for per-user installations, so I cannot say for sure what will be the complicates to rise from the side.
Here is the article:
http://msdn.microsoft.com/en-us/vsto/ff937654.aspx
There you should find all the info required for registry location, files, manifests, etc...
Is it possible to place an application using vsto if the office is not installed? It doesn't appear to be so, but I was wondering if anyone had a work-around.
VSTO wraps Office's Automation interfaces. Office is doing the work under the covers, so must be installed.
Just to compare with Web Office Extensions, did it also need Office installed on the server?