I have an OfficeJS Excel add-in that I want to deploy in an environment, where neither centralized deployments, nor a SharePoint catalog is available for distribution.
Loading the add-in via a shared network drive works, but according to the microsoft docs this is not an option for a production deployment.
Other add-ins in that environment are all VSTO based.
Now my question is, if it's somehow possible to deliver the web-based add-in via a VSTO wrapper?
Would it alternatively be possible to provide the manifest on the the local drive for each user somehow?
EDIT:
Just to make it clearer - still want to serve the web-app via a server. I basically only want to distribute the manifest differently.
Loading the add-in via a shared network drive works, but according to the microsoft docs this is not an option for a production deployment.
When production options are not available, all other possible ways are good.
my question is, if it's somehow possible to deliver the web-based add-in via a VSTO wrapper?
To deliver the manifest is not enough, so you need to sideload the add-in by adding the manifest file to the Office application. Isn't better to provide URL to the network share where manifest resides to users? VSTO is useless in that scenario. OfficeJS (not Excel) doesn't provide any API for loading web add-ins programmatically.
Would it alternatively be possible to provide the manifest on the the local drive for each user somehow?
There is no need to keep the manifest on the local drive. You can provide URL of the manifest to sideload the add-in if the centralized deployment is not available (via the Office365 admin center).
Read more about possible routes in the Deploy and publish Office Add-ins article.
Related
I have made a OneNote add-in, as specified here. All local tests were successful.
This project is a prototype for the development of a proprietary OneNote add-in for a client. Hence the add-in will not be published to the Office Store.
I will not be giving a development phase add-in for my clients so following Microsoft's publishing guide here, I have hosted the add-in as a Static Website on Azure. This process has provided me with a permanent link where the add-in will reside.
Using the guide provided by Microsoft, add-ins will be able to be loaded from a local manifest.xml file. but there is no input for loading the add-in from a url.
My question is, how can the client load the add-in from the link provided?
I started recently to build a office add-in (the web-based ones, not VSTO) and I would like in addition to have it in the office store (the preferred method of distribution) to also distribute the manifest through a setup file. Is this possible?
I searched around the web but the only things that come up are for VSTO add ons.
Web add-ins are not designed for distributing via standalone installers like MSI. You/administrator can sideload them for the organization unit (OU) or just install them from the store. See Centralized Deployment via the Office 365 admin center for more information.
In this doc, it is mentioned that
The following features aren't yet supported in the Developer Preview.
... ...
Publishing add-ins to the Office Store or Office 365 centralized
deployment that use custom functions.
I just want to make sure it means that at the moment we cannot submit to Office Store any add-in that has custom functions; what we can do is only internally deploying add-ins with custom functions, right?
Your interpretation of that guidance in the documentation is correct. i.e., an add-in that uses custom functions cannot currently be published to the Office Store or via Office 365 centralized deployment.
For information about other ways to publish an add-in, see Deploy and publish your Office Add-in.
Was meaning to reply back to this, but add-ins with custom functions are available to be submitted to the Office Store, as announced here: https://developer.microsoft.com/en-us/office/blogs/office-extensibility-build-2019/
Note: Centralized Deployment is still being deployed through all tenants and that will take a few more weeks to complete.
Users are getting an error message when opening Excel workbooks that have a web add-in manifest pre-inserted into them, instead of getting prompted to trust the add-in.
Message:
"ADD-IN BLOCKED Untrusted web add-ins from the Internet are blocked by default. This add-in is from \\myhost.us.mycompany.com\web-addins."
Environment:
Windows, Excel 2016 desktop.
Our web add-in (fka Office add-in) is hosted on a non-MSFT server.
The catalog location hosting the manifest is on a Windows file share. Call it \\myhost.us.mycompany.com\web-addins.
Research:
Googling for the first sentence in the error message returns 0 hits.
Looked for a setting in Excel > File > Options > Trust Center > Trust Center Settings > Trusted Add-in Catalogs. Nothing found to override this blocking behavior.
Question: Is there a way to avoid this message, other than adding the trusted catalog setting to every end-user's Excel configuration?
To configure trusted catalogs automatically across an organization, you can set group policy using use the Office Customization Tool and the Office Administrative Templates.
The settings for this feature can be found at:
Microsoft Office 2016 > Security Settings > Trust Center > Trusted Catalogs. We also support these settings for Office 2013.
The 3 relevant template settings to enable are:
Allow Unsecure web add-ins and Catalogs
Trusted Catalog Location #1
Default Shared Folder Location
And here's an example for how you would complete the Default Shared Folder Location setting:
And as Philip's answer explains, deployment via a network share is not the recommended solution, but you can still use my instructions above if there's some reason why you want to deploy it this way.
The general way to make apps available within your business is to publish them to an internal App Catalog, more information can be found here - https://dev.office.com/docs/add-ins/publish/publish-task-pane-and-content-add-ins-to-an-add-in-catalog and
https://technet.microsoft.com/en-us/library/jj219429.aspx
If you want to publish them via a network share, then yes you would have to push out this setting to each end user individually.
I have a Web application which will be deployed to Windows Azure and I'm looking for alternatives to generate Excel spreadsheets.
Can I use VSTO to programatically generate an Excel spreadsheet in a Web Role running on Windows Azure?... If yes, how should I deploy the application to Windows Azure? What assemblies should I include?
Joni and Joe are correct. VSTO will not run on Azure.
I believe you're looking for the Open XML SDK. That lets you create Excel or other Office files from .NET without using Office automation.
Edit: Here's one option I have considered for those times when the Open XML SDK just doesn't have the functionality I can get from accessing an Office app's object model directly. Set up a machine outside of Azure that operates just as an Azure worker role would by processing messages from an Azure Queue. Since the app on that machine could be setup to execute tasks sequentially, you should be able to get away with things that wouldn't be advisable if you were trying to execute an Office app from a web role. This machine could be in your data center, or you could use an Azure VM so that you could install Office. If that VM was creating and/or reading Excel documents, then just use Azure Blob storage to store the documents.
If the machine running Office is outside of Azure, you will incur additional bandwidth costs for all the data coming in and out of Azure.
I tested this and apparently it won't work, VSTO requires Office to be installed.
I've been successful with generating Excel Spreadsheets in Azure using EPPlus open source project. It builds on the OpenXML SDK, but is much simpler to use.
I've been deploying the code to Worker Role instead of Web Role (as per Lokad.CQRS for Azure architecture) in order to pregenerate reports, so that the application would be more scalable. And the only required assembly was the Epplus.dll.