I want to know whether my add-in is running in Word, Excel or Powerpoint. I need a solution that works in the desktop version of the applications (but preferably for the online version as well).
Is this somehow possible?
The reason I'm asking is twofold:
I want to style the add-in app in the colors of the host application.
I submit the document to a webservice. I want to provide a filename as well and need to know if I should postfix with .docx, .xlsx or .pptx.
There isn't a straightforward way to determine the current host. I would also discourage going down the "single manifest, multiple hosts" path in the first place. As the APIs have matured, more and more functionality has become host specific. The most obvious examples being ExcelAPI and WordAPI.
This isn't to say you should build multiple web apps, just that you should maintain multiple manifests. Each manifest can specify a distinct "landing page" where you can make some session level settings that tell the rest of the App which host it's talking too.
The other benefit of this approach is you can be more selective about which Add-in Commands you declare and where in the ribbon they show up. In some cases you might have functions available in Excel that don't show up at all in Word or PowerPoint.
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'm not even sure if it's possible at all. Earlier, I've been designing addons to Outlook and Excel (using VSTO and VBA). Now, my company got into this Office 365 thinking and we have all our environment online, no local software at all, strictly and only web client approach.
It's got its advantages. But the downside is that out support have no clue how it works (except to tell us to click the settings and look for options, sigh). So, I wonder if it's possible to develop and somehow upload my own customizations (NB we have no servers in the cloud - everything is provided on SAS basis).
Suppose I'd like to:
mark all emails from a certain sender with yellow background in the list in Outlook, or
highlight every occurrence of the word "donkey" in the text mass in Word.
Is it doable at all?
I've googled for it but all I can see is that there's an API and that we need to runt the stuff on our own servers. Am I just confusing myself here?
First of all, if you have O365 subscription, you actually still have the ability to download all desktop version of Office. So your existing customizations should still work on Desktop version of Office.
Second,check out Office Add-in on dev.office.com. Office Add-ins extend the functionality of Office with a web app that lives within Office applications. They work similar to traditional VBA add-ons and we have a rich set of API that helps you interact with Office. This is basically a web app with JavaScript, HTML and CSS. You can build it with any tools you are familiar with and host it anywhere. It is really easy to build and let us know if you have more questions.
Thanks,
Sky
Your best bet for highlighting messages from specific senders would be to use the Outlook REST APIs to access the messages and either stamp a specific category color on the messages, or a flag to highlight the message in the list view. That approach would work across both Web, Outlook, and even Mobile (if you use flags). The new Outlook add-in model is powerful and works for Outlook on the Web, as well as Outlook on Windows, but doesn't allow you to update the colors of the list view add-ins.
This SO question shows a programmatic way for highlighting text in a word document. I am looking to do the same thing but for a document opened inside Sharepoint 2010.
From this link I understand that a document can be opened inside sharepoint itself using the office webapp (a bit of a hack in 2010, better in 2013) or in the local user instance of word/excel/...
I would need programmatic, read-only control over that preview. Mainly to highlight particular text fragments. I would think it should be possible to do this for the webapp instance but not for the locally started instance. Though I have't found any example code or pointers how to approach this. Commercial solutions are not an option.
Edit:
Related question
There seems to be some kind of an api
for the Excel web app but not for word
As far as I can see this is not possible, but happy to be proven wrong. The only solution I see is to do the highlighting on the server side up front (e.g., using com or openxml libs) in a separate copy of the document or on the fly (e.g., like here). Then serve the processed document to the client.
I have an Excel file which uses VSTO to retrieve and update data. This is deployed to various environments (Development, Staging, Production,...).
I want to make sure that a user who downloads a sheet from Staging isn't sending data to Production, because the sheet is using the (locally installed) VSTO which came from Production.
Is there a way to prevent this?
The whole concept of prod/staging/test is a definition thing that software won't magically understand so really the only way to deal with this is to code whatever logic you use into your vsto add-in.
The way we deal with this is that the add-in will check each sheet for a custom property named like: MYADDIN_ISTEST. If this property is found then the add-in will connect to the test database (for that sheet) and if not it will connect to the production database. You can think of all sort of variations to this theme depending on what makes sense for your environment but the reason for us to do it this way is that renaming or moving a file (with testdata) can be easily done by anyone without him/her realising the consequences. Going into the document's custom properties and removing that test property is something you will only do on purpose.
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.