If you already write Apps Script add-ons, you’ll know that debugging can be a little challenging, and although you can use the developer tools in chrome on a running add-on, breakpoints don’t persist between sessions and it can be hard to relate what you wrote with what you see in the tools.
Office is much better in that respect if you are running Office online. There’s a much closer correlation between what you can see in the tools and what you wrote. It makes sense, because your app is being served up directly, whereas in Apps Script it’s been constructed by HtmlService.
It’s quite an achievement that local versions of Office – which are native Apps – can run add-ins at all, but remarkably they can. It took me a while to figure out how to test an add-in locally. In the online mode, you insert your add-in then upload the manifest, which describes where your app is being hosted (amongst many other XML type complicated things).
If you are not too embedded in the Microsoft universe and don’t have Sharepoint, you can host your manifest file on a network share, and tell Excel (and other Office apps), that this network share hosts manifests.
First of all, copy your manifest file to this network share (I wasn’t able to point to it locally, I had to put it on a share)
In Excel Options, go to the trust center/Settings
Then when you go into Insert Add-in in the local version of Excel, you’ll see this new option ‘Shared Folder’
Select that and the add-in appears in a sidebar in your local Excel!
At this point I thought I was screwed, but then I came across this Windows 10 component – f12Chooser.exe
which magically brings up all the processes running in your machine like this
You pick the one you want to look at (in my case officeindex.html), and it magically brings up a debugger that’s connected to your running add-on. It’s not as good as the Chrome developer tools , but it’s perfectly fine to find out those little things that don’t work between the online and offline versions. It was a great surprise and very useful.