❔ How can I get Rider to debug an Office add-in?
I'm trying to get started debugging Office add-in with Rider. I have found guides all over without but only for VSCode so I'm asking here. I have gleaned that I am suppose to use the
office-addin-debugging npm script. This script is supposed to set up a debugging environment, run a dev server, and open Word and side load my add-in.
It does all this but in a way that I don't fully understand, or would rather it did it differently. My add-in is a React app and what happens when I manually run my start npm script is that office-addin-debugging does these things:
1. starts up a debugger. I don't know what this actually means.
2. starts the dev server with webpack in a detached process
3. then starts up Word and side loads the add-in
4. stops the debugger. I don't know why it does this. Maybe because either the webpack-dev-server process returns or because the Word.
Rider's Debug tool window shows "Process finished with exit code 0", and none of my TypeScript breakpoints get hit.
If I launch my start script as a Rider debug config then the process doesn't exit, and if I hit the pause button the debugger breaks somewhere random in my TypeScript. Yet none of my breakpoints get hit when I reload the add-in from Word.
I think the main problem here is that office-addin-debugging starts webpack in a detached process and not in the debugging process, which is probably node. I simply don't know. Having a web server and Word runnign at the same time complicates things.6 Replies
This is a fairly odd way to debug an office addin
There are specific debugging tools for this on the windows store
https://learn.microsoft.com/en-us/office/dev/add-ins/testing/debug-add-ins-overview#debug-on-windows
Debug Office Add-ins - Office Add-ins
Find the Office Add-in debugging guidance for your development environment.
This is what you're looking for
You can attach Rider to that process
If you really want
And set breakpoints from within Rider
Just be sure you have source maps
Thanks, it isn't an odd way at all, I've been following the docs and they end up using the
office-addin-debugging script in the end anyway. I'll explain how shortly, but first something I forgot to mention: I'm using the WebView2 runtime. The doc you linked to has a link that eventually leads to the doc for debugging on the Chromium WebView2 runtime doc.
I have followed the Chromium doc, which is very focused on VSCode, but it has proven a bit helpful. It says if my app wasn't created with Yo Office I must follow Appendix A first, but this appendix is out of date (raise in this issue: https://github.com/microsoft/vscode/issues/157587).GitHub
Issues · microsoft/vscode
Visual Studio Code. Contribute to microsoft/vscode development by creating an account on GitHub.
Anyway I didn't know whether my app was created with Yoeman or not, so I followed those instructions. They are for creating a VSCode launch profile, and that launch profile has a
preLaunchTask that runs the start:desktop npm script, which is basically the same as what I'm doing.
The start:desktop preLaunchTask makes this npm call: office-addin-debugging start manifest.xml desktop, which is the same as my start script.
I just don't know exactly what process I must attach to, or how to do that in a Rider debug config
The launch config that the docs build uses office-addin in its type property, but this is part of what's out of date. The intellisence for the type property tells me to use chrome instead, but I know I'm not using Chrome, the issue I linked to suggests using msedge for the type. The request property is to attach after running the preLaunch that starts up webpack and Word. Which is what I already have going
When I attach to the "node webpack" process, a breakpoint in my index.tsx doesn't get hit. This seems to be trying to debug node itselfWas this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.