Posted by on Nov 18, 2015 in #Office365Dev | 3 comments

Disclaimer: If you are building an Office add-in for Excel and Word only. I would recommend you to check out this post instead: http://simonjaeger.com/here-i-am-detecting-the-office-host-in-excel-and-word-add-ins/ – this approach is much more solid and reliable.

Usually we all want to share our code across different solutions as much as possible. If you are building Office add-ins using the Office.js library (https://msdn.microsoft.com/en-us/library/office/fp142185.aspx) – you have a great foundation for building a shared codebase. In example, calling the following function in the Office.js library works great in many Office applications (Excel, Project, PowerPoint and Word for instance).

If you are interested in creating different logic depending on the host application running your add-in, you will need to distinguish between them in your code.

Why is this useful? Say that you are inserting data into the Office context. In some cases it would make more sense to insert it as tables in Excel, but as paragraphs for Word. It’s a slight adjustment to make in a shared codebase.

When your Office add-in is launched, it is given host information in a query parameter named _host_Info from the host application itself. If you want to, you can grab it and parse it as you please. Another way is to grab it from the session storage when your Office add-in has been initialized – the Office.js library actually stores it there.

I created the following function to extract it from the session storage (an item named hostInfoValue) and parse it.

Included is a couple of different properties in the hostInfo object.

  • The type property is the Office application your add-in is being hosted within (i.e. Word or Excel)
  • The platform property is the space where the Office application is running (i.e. Win32 or Web)
  • The version property is the version of the Office application (i.e. 16 for Office 2016)
  • The culture  property is not always given (only in the Win32 version as of right now) – it gives a hint about the culture which the Office application using (i.e. en-US)

Once your initialize function has been called by the Office.js library – you can call the getHostInfo function and extract the information.

This is the log I received from running a mail add-in in Outlook 2016 for Windows desktop.

officehost

Like so you can create the host-specific code you need for the various flavors of Office application – yet still maintain a shared codebase. All good!

-Simon Jaeger