I have recently published an Outlook Add-in (simple one task pane firing an API call with inserting text received back).
Now I am interested in developing the same for the other Office products (Word, Excel , etc).
I was wondering if it is possible to have, let's say, a Word manifest, Excel manifest and Outlook manifest all pointing to the same web project but different folders in the project.
The standard way of having an add-in that works on multiple Office host applications is to have multiple <host> sections in a single manifest (one host for each Office application). That said, I think it is possible in principle to have separate manifest files (which means, in effect, separate add-ins) for each host application. The critical thing is to make sure that the various URL values in each manifest point to the appropriate place for that add-in. If you haven't already, be sure you are familiar with the documentation about the manifest XML.
#rick-kirkham I have managed to create multiple manifest files with one web project holding the different folders to which the manifests point. I currently have an Outlook, Word and Excel add-in using the same web project.
One thing I had to do is remove the reference in the manifest file project that points to the web folder.
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.
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
I have multiple Excel Web Parts in my SharePoint 2010 site. Each web part is connected to an Excel work book which is generated automatically by a scheduled task on a separate server. Given this, is there a way to automatically map a newly generated excel file to an existing excel web part instead of manually updating them?
I saw a tutorial but it uses the SharePoint dll and other dlls which are found from the SharePoint server itself and as far as I know, I can only execute these items if I have SharePoint installed locally. Is there any way to make it work without having to install SharePoint locally? By the way I was referring to this tutorial from MSDN.
Edit
I was able to create web parts programmatically using SharePoint.Client.WebParts but I'm having problems creating Excel Web Access Web Parts.
I was able to make it work by using the same concept found in this page.
All that I needed to do was properly escape quotation marks from the exported web part file in order to map the correct file.
I'm making a Word 2007 add-in with C# 4.0 in Visual Studio 2010. I need an Access 2007 database (a .accdb file) to be placed in the data directory by the clickonce installer. Unfortunately, the file is getting put elsewhere, so the application can't find it at runtime. I've seen various articles refer to using the Application Files dialog on the Publish tab of the project properties to mark the file as a data file, but I have no Application Files button for some reason.
Any idea how to make the Application Files dialog appear, or some other way to manually mark my .accdb file as a data file?
In the Solution Explorer, if you set the file's property to be Copy to Output Directory = Copy Always. Then when you go to Application Files they should default as a Data File.
However, since this is your database I would consider looking at make it safe across updates so you might consider this post.
See http://msdn.microsoft.com/en-us/library/dd465298.aspx
By the way, "Application Files" button should be on the project properties' Publish tab.
VSTO Applications do not have the Application Files button available, and you can't set the file types specifically. If your file is not being deployed to the data directory and you want it to be, rename it with a file extension that is marked by ClickOnce as data. This includes .xml, .mdb, and .mdf. Otherwise, the file is deployed with the VSTO application and will be in the same location as the rest of the files.
The location of the deployment files for a VSTO application can be discovered programmatically this way:
System.Reflection.Assembly.GetExecutingAssembly.CodeBase
You might want to move the database, though, because unless you deploy it as data, it will be lost when an update is performed. Or you can check out this article about where to put your data to keep it safe from ClickOnce updates.
I was able to get things to work by using the Mage tool as described here:
http://msdn.microsoft.com/en-us/library/6fehc36e.aspx
The trick with MageUI is it's open file dialog assumes you want to open a manifest associated with a .exe; a vsto project has a .dll, so the manifest doesn't appear in the files list by default, which was really tripping me up.
Basically, this process is a pain because you have to remember to do it manually. I don't know if there's a way to make this part of the build (maybe a post-build step? But this is really a post-publish step).
with the push to leverage visual studio and dotnet with office based solutions, especially excel, where is the best article or information on how having office sheet with additional binaries and assemblies is sharable.
Do this external code get packaged with the spreadsheet
what if people start emailing the spreadsheet around. Is there any overhead of this additional assemblies. Is there risk of the binaries getting detached from the spreadsheet
It seems like microsoft has been pushing VSTO for over 5 years now but you read lots of mixed reviews and issues. Are we at the point where companies that do large VBA excel solutions can fully migrate over to dotnet without any real worries?
First of all, I want to answer your question on whether or not VSTO is ready for larger implementations. The answer is YES! Especially if the alternative is VBA. You have the entire .Net framework available, you can use web services, ADO.Net (better still, with the enterprise library). You can still write code that looks a lot like VBA, but is much more powerful. You can get more information by reading Walkthrough: Creating Your First Document-Level Customization for Excel. This page will give you an idea of what VSTO features are available to you.
Now, to answer your question on deployment.
It depends on whether you are making an Add-In or a document level customization. If its an Add-In, then you must install it on each client, and any passing around of documents will not effect that (Add-Ins are at the application level, and not at the individual document level).
I assume that you are talking about a document level customization, so I will center my answer around that.
When you create a document level customization, the assemblies are not loaded into the excel file (as they are with VBA). Instead, a document property is added telling the application that this document contains a manifest file (and tells it of the manifest file's location). The manifest file contains links to the assembly that makes up your customization.
As with any .Net application, there are sometimes other (referenced) assemblies that also need to be deployed. Not always are these assemblies in the GAC, so they would have to be located in the same folder as your executing assembly (in this case, your customization assembly). You don't necessarily have to place your assemblies in the same location as your excel file, though.
There are a few ways you can deploy the customization.
You can store all of the assemblies and the excel file in a folder and run the application that way (if the excel file is passed around, the users must pass around the entire folder).
You can run an setup program that installs the assemblies to a specific folder on the users computer, and specifies the manifest at that location (if the excel file is passed around, the users must also pass around the setup program).
You can install the assemblies in a network location and specify in the document properties, that the manifest and the assemblies are all at that network location (if the excel file is passed around, nothing needs to be passed along with it - but there are security settings that need to be made. Read this page for more information).
Any way that you decide to do this, here is the page you need to read in order to understand the document properties that enable the customization.
You need to make sure all of your users have the prerequisites installed. The easiest way to do this is to give them all a setup program. If you create a setup project for your customization, you can setup the bootstrapper to automatically install the prerequisites. You can also do this if you use ClickOnce to install the customization. This page will give you all the information you need to know regarding deployment.
Here are some other helpful links you will need to see:
Application Manifests for Office Solutions (2007 System)
Deployment Manifests for Office Solutions (2007 System)
Application and Deployment Manifests in Office Solutions
I hope this helps. Once you read all of this information, I think you'll agree that VSTO is a much better choice than VBA. You just have to plan your deployment carefully.
I created a Excel add-on and deployed it to a server. Then I passed around two links, the setup.exe file and the link to the actual Workbook. The workbook file never changed - it's purpose was to open and load the add-on which was now in the user's Add/Remove Programs. The add-on itself would check for updates on startup.
So if they start emailing the workbook around, great! I believe in theory, the workbook would download the add-on if it was missing, but I don't have a fresh computer around to test that. If it doesn't, it's just a simply exe to install (which will update on launch anyhow, so outdated isn't an issue).
For document-level deployment, I recommend the following three links:
https://msdn.microsoft.com/en-us/library/ms268758(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/ff937654.aspx
How do you assign the Assembly Location of an Excel VSTO Installation?
Unlike application-level solution, document-level has 2 special properties: _AssemblyLocation and_AssemblyName, which indicate the *.vsto position. To set these properties by install path, a custom action project should be created to record the target path when installing, and packaged together with setup.exe. Then you could put your excel file anywhere (on local machine) and open it in the correct way.