As explained in a previous blog post, the so-called web add-ins are actually web applications. However when it comes to development, especially with Office Desktop host applications, things are not so simple. In this blog post, we propose to describe and compare the available debugging solutions.
Using your favorite web browser devtools.
When running in Office Online, an add-in is just a plain old iFrame. Most modern browser (Chrome, Edge, Firefox) let you debug iFrames without any difficulty.
For example, with Chrome you just have to hit F12 to open dev tools and select the add-in iFrame (named with something like {"baseFrameName" : _xmd_0}...). You need to perform add-in “side loading”, i.e. inserting the manifest manually in Office Online and start your web server independently (see how here).
Pros:
- You work with top notch dev tools from modern browsers.
Cons:
- Works only with Office Online.
This technique is our recommended solution for developing most of your add-ins features. But if you have something specific to Office Desktop (Mac or Windows) then you cannot use such a technique. Let us investigate the alternatives.
The F12.exe tools
Windows comes with F12Chooser.exe which enables you to debug any IE process. Remind that the underlying browser running your web addins is IE. Depending on the bitness of your Office Desktop, you start F12Chooser.exe (located in C:\Windows\System32\F12\ for 32-bit version and C:\Windows\SysWOW64\F12\ for 64-bit) and select the proper IE process. You have now IE 11 dev tools (which is not so bad) attached to your add-in.
More documentation available here.
Pros:
- The most flexible way to inspect the DOM and debug javascript of an add-in in Outlook Desktop on Windows.
Cons:
- Works only with Office Desktop on Windows.
- Not adapted to debug javascript functions in Office Commands, see Office Commands for Outlook and for other Office products.
- Not very handy: when the add-in pane closes so does the dev tools, you have to repeat the choosing procedure which is annoying.
Visual Studio debugger
When creating an add-in using Visual Studio project template available in Office developer tools, you can start directly this project (F5-Run). If you choose Office Desktop client, you will have Visual Studio debugger attached to all IE processes running the add-in.
Of course you can attach directly Visual Studio debugger (no need for the add-in project template). In VS 2015, when add-in is opened Debug > Attach To Process, select the appropriate iexplorer.exe process (Make sure that you select Script in Attach To: menu). That’s it you are attached! You may need to reload the add-in in javascript console: window.location.reload(). It looks like remote debugging is also possible (on Windows machine) see this article.
Pros:
- You can debug easily add-ins commands.
- A DOM explorer and a javascript console is available.
Cons:
- Office Desktop Windows only.
- We think this is an heavy solution for only web development tasks.
- You need to use Visual Studio.
- Remote debugging between your host OS and VM running inside it is not so simple to configure….
Vorlon.js
Vorlon.js is a remote debugger, it is open source and very promising. You can check this documentation to know more. Here is also a blog post explaining how to use Vorlon.js to debug Office add-ins. Vorlon.js is really powerful: after inserting a script to your add-in web page, you can identify and debug your clients running anywhere on your Vorlon.js server located on your machine.
Pros:
- It is the only way to debug on Mac or iOS devices.
- Remote debugging allows you to debug any device on any platform without installing anything.
Cons:
- Cannot be really used for everyday development, this is mostly for one shot bug fix.
- Project is still young. We tested it last spring and it was still unstable and a little bit slow.
- You need to modify your code to insert Vorlon.js scripts.
