In a recent article, I wrote about my experience converting my Microsoft Word VSTO add-in to a Microsoft Word Office Web add-in. In this article and related video, I walk you through the pros, cons, and just plain differences between creating Windows and Web-centric add-ins.
What is an add-in?
Add-ins are applications you can create, purchase, or download for free. They extend Microsoft Office to help you accomplish things that are not currently possible or to reduce tedious activities. For example, Microsoft Word does not have the ability to save a document to eBook formats, so I sell an app that does just that.
In most cases, an add-in places at least one icon on the ribbon bar (or tabs as most people call them) and then provides some functionality the Office application does not offer out of the box. Here are some examples of add-ins you might find in various Microsoft Office products.
- Excel: Read sales data from a table of cells and place the information on an interactive Google or Bing map.
- PowerPoint: Search a catalog of premium images to add more life to your presentations.
- Outlook: The most popular one everyone is talking about is the Starbucks app that lets your send eGift cards or even schedule meetings at a local Starbucks.
- Word: Translate words from one language to another.
VSTO and Office Web add-ins
There are two common ways you can create Office add-ins, with the most popular being VSTO (or Visual Studio Tools for Office) and the other being the new(er) kid on the block, Web add-ins.
A VSTO add-in can be virtually any Windows app you can dream up. For the most part, there is no real distinction between a Windows app and a VSTO add-in other than the fact your app only runs within the host application (Word, PowerPoint, Excel, etc.).
A Web add-in is Microsoft’s approach to letting you run an app on any operating system. Unlike a VSTO add-in, Web add-ins do not rely on any particular operating system. A Web add-in runs in a side task pane that displays on the far-right of the application.
In most cases, a Web add-in can read from or write to the host application. For example, if the user types Hello World in Microsoft Word and clicks your app’s button, the app can read that text and replace it with the Spanish equivalent, Hola Mundo.
Reasons for using VSTO
If you are developing a highly sophisticated application that needs to use the local computer’s operating system to perform certain functions, then a VSTO app is the way to go. VSTO add-ins can only run on Windows, so you are limiting yourself to a smaller (yet quite large) audience.
Another reason for using VSTO is the faster development cycle. If you need to write an add-in quickly, then creating a single project that contains the user interface, business logic, and classes make life much easier. You will not feel like you are developing a modern, service-oriented, model-view-viewmodel solution, but you will get things done quickly.
Distribution channels for VSTO
To deploy a VSTO add-in, you usually distribute the app via a setup.exe or MSI file. If you are in IT and want to deploy the app centrally, you can push it out like any other Windows app. If you wish to sell the app (or give it away for free), then you need to supply the user with a setup file.
As of this writing, you cannot sell VSTO apps on Microsoft’s online Add-in Store, so you will need to sell it through an online store of your own.
Development skills required for VSTO
At a minimum, you will need the following skills to build a VSTO application:
- C# or Visual Basic (the best online examples and sample code tend to be in C#).
- Working knowledge of the Microsoft Office object model and document model.
Reasons for using Web add-ins
If you want your add-in to run on any operating system, like Windows, Android, iOS, and others, then you create a Web add-in. Web add-ins are not as feature-rich as a VSTO app, but it does provide other benefits. For example, since the app is web-based, it almost forces you to follow best practices in separating the user interface and business logic, along with code re-use by creating generic web services.
Distribution channels for Web add-ins
To the best of my knowledge, Microsoft only allows users to access your Web add-in through their online Add-ins store. There is a Store icon in Microsoft Office that allows a user to search for an app and use it immediately. Microsoft does have solutions for IT departments that need to deploy their apps to internal staff.
Development skills required for Web add-ins
Since a Web add-in can run on any operating system, Microsoft had to break with the tradition of creating C# or Visual Basic options. Therefore, you will need to write the app using web technologies, including:
- HTML (for your app’s user interface).
- CSS (to style your app).
- Working knowledge of the host’s document object model.
Technically, those are the only skills you need for your app, but if your app needs to talk to web services, then you will also need to know:
- Web services development. Here, you can use whatever programming language your backend system supports, like C#, VB, Node.js, etc. To build the web services, you are going to need a web server or maybe look into serverless computing options like Microsoft’s Azure Functions or Amazon’s Lambda.
- REST (to send requests to a web service).
- JSON or XML (to receive and parse the response from the web service).
The single most important thing you do before deciding on the add-in technology that is best for your app is to read the documentation carefully and create some very simple proof-of-concept designs. More importantly, when working with Web add-ins, do not fall into that trap of saying, “Oh, that’s just a Microsoft app, I can do that,” because your options are limited for Microsoft to support cross-platform functionality.