Extend Your App with Office Add-in’s

What you will learn:

  • How to communicate between an Office Add-in and your App
  • Adopt the same style in your Add-in Windows as Office


About the Author
Manfred Jehle is CTO at Software Center of Excellence, dieInkasso AG, Switzerland and CEO at CeTris Ltd.
Manfred Jehle has over 30 years’ experience in computer science. Having served in different positions, he has a deep insight into various aspects of information technology. As the CTO at Software Center of Excellence, dieInkasso AG, Switzerland and CEO of CeTris Ltd., he is responsible for the system concepts of all Software Center of Excellence and CeTris® products. Through collaboration in realization and coding, he acquires repeatedly practical experiences which are incorporated into future concepts automatically. Manfred Jehle has many years of practical experience in conceiving, production and application of services from and within different environments. He has developed many practical solutions which are often neglected in theoretical views. For all his solutions, user-friendliness is a top priority. His appropriate technical solutions are oriented to the architectures which are factored in at an early stage to accommodate possible future change. He is the author of various white papers of CeTris Ltd. and various articles at SDJ and Object Spectrum.
Contact: [email protected]

Create the Office Add-in

To create an Office Add-in is not a big thing – but to communicate with the Add-in needs some more effort. Start with Visual Studio’s common Add-in creation processes and create the base for your next steps. Use the common “App.config” to add language resources to your project. Later on, you need the “App.config” for your communication channel declaration too. In case you need a window in your Add-in as an interface to your users, use common Forms-Windows or get the Office style you can add a WPF window. The best way to do so is to create a second project in your solution for the WPF part. In the Add-in project, refer to the WPF project and from that point on, you create from your Add-in part the WPF window. To have an exchange way between WPF and the Add-in, use a reference based on an interface. For that, add a project to your solution holding the interface with a simple interface method for “commands”. In both, your Add-in and the WPF project, add a reference to the interface project. You can inherit your Add-in from the interface and have to add the “command” method. In the WPF part, add a variable based on the interface and at creation time of the WPF window, add a reference to the Add-in itself “through” the interface.
So, the basic part is done. Let us take a look at the class and interface structure.


As shown in the picture above, an additional part is listed for the Ribbon. The Ribbon uses also a direct connection to the Add-in as “parent”. That allows you to concentrate all business logic on one part and having the visual parts separated freely from business logic.
Style your WPF windows similar to all Outlook Apps look and feel. That gives your Add-in user interfaces the same acceptance and set up at the common user experiences with Office.

Communicate with the Office Add-in

Imagine the potential of your App allowing communication with Outlook or any other Office App. An easy way to implement communication is to use a http connection. What is necessary for such a communication?
All we need already exist. You can use the WCF service host in your managed App. Define the “ServiceContract” interface and implement in your code a channel to exchange data. Use the simple windows credentials to have a basic security level implemented to avoid using the communication channel by other users especially in a Terminal Server environment. With this simple authentication together with a defined port per user, you are on the secure way.
In the following picture, you can see the transfer of the information of opened documents in a App with a HTTP communication to an Outlook Add-In.

The simplest way to exchange data is using REST based HTTP services. That means on the App side, you only have to create XML content regarding your open documents and their details and on the Add-in side, you have to pack your commands payload for the App in XML content.
The HTTP communication is based on a one-way push service which means on the App side, you have the server part, and on the Add-in side, you have the client part.

How to start the communication?

You can start the Office from your App with Office interop functions, and in a document based environment like Word, you have the option to initialize your Add-in through back content variables. Outlook doesn’t have such an option. Therefore, you need another solution to get in touch with your App. You can define in your “App.config” file a range of communication ports together with the base communication information. At Add-in startup, you can go through a port scanning process and find your App server. From that point on, you get and post information to and from your App.
In the following picture, you get an impression of how a document based communication with Word can be started to exchange the basic communication information.

I hope that this short description about the possibility of intercommunication between your App and Office Add-ins gives you an impression of what’s possible, and opens your mind to new ideas on the integration of Office in your App.

Manfred Jehle
CEO at VIP Office a group of CeTris Ltd.
Manfred Jehle

Latest posts by Manfred Jehle (see all)