I have a .xlam add-in which gives users an additional ribbon in Excel with several macros.
In the past, I have distributed these sorts of add-ins by saving the file to a saved network location, and asking the users to follow 5/6 simple steps to install (Excel > Options > Add-ins > Find the file and select OK). This also means that to update the toolbar across all users, I just need to overwrite the one file and everybody will then see the new version.
However, for the business I actually work for, many of our users are regularly at client sites, with no access to our own network - so the approach of saving the file to the network (as above) won't work.
I had heard that Add-ins could be rolled out via Office 365 admin center 'centralised deployment', however am I right in thinking this is for a different type of 'add-in'?
If so, are there any other approaches I can take to roll out a .xlam add-in to multiple users via the Cloud?
Thanks in advance!
Deployment by Office 365 Admin center is only for Web Add-in, the new generation, so your add-in in .xlam could not be deploy like that.
To deploy to many user you can do it by share network like you did, or by tool like SCCM to deploy more easily to lot of user
For info, I managed to solve this by saving the .xlam file into a Shared OneDrive folder, and instructing the users to install it from this location.
This allows me to update the .xlam file on OneDrive with new versions, and this will then automatically sync onto the users machines, meaning the toolbar is always up to date.
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.
(Desktop version) I'm new to using the javascript API for excel, but is it possible to create an excel add-in and share with other users without having to add the add-in to an app source etc? Can it be embedded in the excel file etc. I'd like to share scripts with other users the same way that I can share VBA if it's possible?
for security reasons as well as to make manageability of your add-ins easier, we do not store the code within the workbook, like VBA. Instead, the javascript is hosted on your website and we have a reference to your add-in saved in the workbook.
What this means, is to get a similar experience to VBA, you must either have the add-in hosted on app source (which will make it accessible via the Office Store), OR each user in an organization must have the add-in deployed or available to them (here we recommend centralized deployment as it will give the most robust experience).
This has all the current deployment options you can use for Office add-ins: https://learn.microsoft.com/en-us/office/dev/add-ins/publish/publish
thanks!
According to the API docs, the Office.Settings objects are saved per add-in and per document. That is, they are available only to the add-in that created them, and only from the document in which they are saved.
I'm a bit confused regarding the Office.Settings interface. I've created a gist in the ScriptLab Add-in where I set 2 setting objects (queries and queryIDs) and then retrieve them (log them to console).
Gist: https://gist.github.com/VivianVenter/e5489628384f96f2d3bf9a50aace8728
If I run this gist on Excel Desktop, then I can create the settings and retrieve them successfully. If I save this workbook and open it in Excel Online and run the gist again then I cannot retrieve the settings, it returns null for both settings object.
According to my knowledge the ScriptLab Add-in is the same for the Desktop and Online version, am I missing something, or is it the intention of OfficeJS to not make the settings available/visible in the Online version if it was created and set in the Desktop version?
Settings desktop found:
The settings objects was found in Excel Desktop
Settings online null:
The settings objects was NOT found in Excel Online
Office add-in's setting is stored based on the add-in's id.
And once it is installed by side-loading, a new id is allocated to the add-in every time.
This means you can't sync settings on multiple platforms while developing.
Once you submitted the add-in to the AppSource, a static id from AppSource is allocated to the add-in and it is used while installing the add-in from AppSource.
So, you should submit the add-in to AppSource to test/implement this feature.
The issue was caused by a bug in office-js which has now been fixed upstream.
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.
Do any of you have advice on methods for deploying an office VSTO addin, especially Excel, that makes it easy to update and deploy the document as well as the addin.
I have a document level addin for Excel 2010 that I created using VSTO. I currently deploy it using click once. However, this has a few problems. The first problem is that I publish it to ftp then users install it from my website. Since the document and addin are downloaded from the internet, I obviously have trouble getting proper permission for the addin to run and the document to be trusted. Currently I just have users manually adjust permissions and grant access when the solution is installed. That part works and is fine, but if any of you have suggestions on how to automate this that would be great.
The second problem, the main one I am wanting help with in this post, is deploying updates. I generally like using clickonce because of its ease of installation and automatic update features. The solutions I develop are used in rapidly growing fast changing companies, which means I am often making updates. Click once makes it easy enough to update the "code" or addin itself. I just have it automatically check for updates when it is started, and if there are updates it will prompt the user to download them. But what about the document? My solution doesn't only include the code. It also includes the highly customized Excel workbook.
When the solution is initially installed a copy of the workbook is just downloaded to the local computer. But what about after it is deployed to dozens of computers? Does a document level change (adding a column for example) mean going to each computer and downloading the updated workbook manually?
Surely there is a better way to automatically deploy updated versions of the workbook. Any suggestions?
Here are a few ideas I thought of:
Use some installer other than clickonce. Any suggestion on one that allows easy automatic updates?
Somehow package the workbook as an application resource. I have actually done this in some situations, but not in cases where the document itself included a VSTO addin.
Related to the previous idea. Make a "wrapper" project that includes the workbook & VSTO addin. Then the addin would be launched by clicking on a regular icon on the desktop, which would download the workbook (if an update was needed) then open it in Excel. I would prefer that method of launch over simply opening the workbook anyway.
Note: No user data needs to be preserved in the Workbook when an update is done. The old version could simply be overwritten by the new one. The workbook gets all its data from an SQL server.
You could use a Visual Studio Setup Project which leverages Windows Installer. See this deployment walkthrough guide on using VSTO 4.0.
In Visual Studio 2012, support for Setup Projects is being deprecated in favor of InstallShield LE which is another alternative.