I'm playing with Excel Add-ins, and I'm not a specialist, so having read the documentation, I still find it complicated to publish and install it.
Basically, all I did was the very basic Excel Add-in described in the documentation and now I'm trying to figure out how to install it in Excel.
I see everywhere that this is vrey simple, all you have to do is to upload the XML manisfest file, etc. but using Visual Studio, I chose publish via FTP and I get 3 folders in my website:
Content
Functions
Scripts
These are full of js scripts, but I don't see the manifest file nor the home.css, Home.js and Home.html
Isn't it possible to just upload the files with Filezilla to a folder? Which files?
If so, then how do I install the addin in Excel?
Thank you so much for helping!
The manifest goes to a different place than the files in the web application part of the add-in. Please see this article and the links in it for the details of how to publish the web application and deploy the manifest: Deploy and Publish your Office Add-in.
UPDATE 1/10/19:
Some additional information in light of the OP's comments:
Please start with this article: Office Add-ins to get an overview. You will see that there are two main parts to an Office Web Add-in: (1) The manifest and (2) a web application.
The manifest can be sideloaded or deployed using several methods. For more information on publishing options, see this node of the documentation: Publish.
The web application can be published/hosted using any method or platform that you want. We don't give instructions for most methods because this information is already available on the web. However, this article, Host an Office Add-in on Microsoft Azure, explains how to do it on Azure. I recommend that you try that method of hosting first. Note that in step 6, you edit the manifest to point to the URL of your web app. When you feel familiar with the distinction between hosting the web app and deploying the manifest, you can try an alternate method of hosting the web app. No matter which method you choose, you will edit the manifest in the same way.
Related
I am developing an add-in for Word, Excel and PowerPoint. I need to fetch the version of the add-in installed in client machine. I can see the version under 'Security Info' but I need to get it in my script at runtime.
Is there any OfficeJS API to fetch add-in version or get 'Security Info' programmatically ?
Have a look at this question. There isn't currently an API to get the version of the add-in from the add-in manifest.
If this solution described doesn't meet your needs, please head over to Microsoft 365 Developer Platform and post a request for the API team to consider. It will be helpful, if you provide more details on why getting the version information from the manifest is valuable for your use case.
The Office JavaScript API (OfficeJS) doesn't provide anything for that. Typically the version of Office add-ins is specified in the add-in manifest file where you can't access it from JS until it is hosted with a web app. If it is uploaded to the same place/server with your web app and you know the exact URL you may try to fetch the content and read the version from there. Otherwise, you have to define the version in the JS files or pass it as an URL parameter like Michael described.
If you find it inconvenient (as I do) you can post or vote for an existing feature request on Tech Community where they are considered when the Office dev team go through the planning process.
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.
We have a solution with an app extender (mega menu and some look n feel jquery teicks) and a web part.
We are trying to deploy it. It's pretty easy getting the dev version in the App Catalog and running it with local scripts. The extender doesn't seem to show up l, however the web part is working.
We want to know if we can deploy a shipping or production version without deploying Scripts to an o365 CDN. This part is not clear since we thought we could just package all and throw it into the App Catalog...
Any guidelines if we don't want to use the CDN?
If you don't want to use CDN, as a workaround, we can create SharePoint Library as CDN.
1.Create a document library(named "SPFxDeploy") in your SharePoint Site, and give read permission to all users.
2.Configure SPFx Solution for SharePoint Library, open package-solution.json file from config folder and set includeClientSideAssets value as false.
3.Update CDN Path, open write-manifests.json file from config folder and update CDN base path as SharePoint library URL.
4.Prepare the package using "gulp bundle --ship", then upload the files from "temp\deploy" folder to SharePoint library.
5.Upload package to the app catalog.
Reference: SharePoint Framework - Deploy SPFx WebParts to SharePoint Library
I just bought an Office 365 family account, and installed Excel on my Windows.
However, I cannot find "manayge my add-ins" where we could upload an xml for testing. I have been always using excel online to test my xml/addin.
Does anyone know what's wrong here?
Side-loading on Windows is a bit different. You need to setup a network share and store your manifest file there. Once you configure your client, it will automatically start picking up manifest files from that directory.
See Sideload Office Add-ins for more complete details on this process.
I've been able to make an Office Taskpane Add-In available within Word by placing the manifest XML file on a network folder. What I would like to do, however, is have the manifest file hosted on my webserver that hosts the Taskpane webapp as well and have Office grab the manifest from there.
I tried adding the URL to where the manifest file is hosted to the Trusted Web Add-In catalogs and I see it listed as a catalog of type "SharePoint" (while it's not a SharePoint site, just a regular old http host). My add-in also isn't showing up in Word.
Is there a way for me to host the manifest XML file on a regular webhost and have the add-in made available in Office?
You can side-load add-ins but it isn't recommended for production use. It makes updating the manifest rather tedious at any scale beyond 1or 2 users.
I recommend taking a look at Publish your Office Add-in. There are sever options beyond the network share method. For internal deployments