VS Code not attaching with Office Running WebView2 Taskpanes

[aafvstam]

The launch event does not seem to attach (anymore?). I'm running 16.0.13012.2000 64-bit of Office. This does seem to run WebView2, could that be an issue? I think it is, as it also does not show the entry in Microsoft Edge Dev Tools but now you can use the 'attach debugger' in the Add-in Taskpane. This however now attaches to Edge Chromium.

I also tried setting the default browser to Edge (not chromium) or Chrome but to no effect. Can you provide a working scenarion using Office 16.0.13012.2000?

My efforts are recorded and can be reviewed at https://youtu.be/Pd8IqpiCacg (been messing around for hours with this, so you need to have patience watching this 😁)

[TCourtneyOwen]

Sorry to hear you are having troubles. If you are now running WebView2 with the latest version of Office then the debugger won't be able to attach. We are planning to add WebView2 support in the future. If you want to switch back to Edge WebView, which is presumably what you were running when you had success attaching the debugger extension, please try running the following command: npx office-addin-dev-settings webview edge.

Please let me know if that works for you.

Thanks,

Courtney

[aafvstam]

Tested this in my Live Coding session and was able to debug using the 'old' Edge by running the command: npx office-addin-dev-settings webview .\manifest.xml edge 😎👍

To restore Office letting it use WebView2 again you need to run the command: npx office-addin-dev-settings webview .\manifest.xml default

[TCourtneyOwen]

Awesome glad to hear it!

[aafvstam]

Debugging stopped working again even with the npx change to edge ...

I see that it is connecting (it actually connected, websocket is created), but the break is not happening anymore.

[TCourtneyOwen]

Are you running VS Code as admin? I assume you are in fact using Edge and not Edge Chromium? Has this been working for you up until today?

[aafvstam]

Yes, I have been trying all combinations, I do think it connected but just does not stop at the breakpoint. Tried with both JS and TS boilerplates, latest versions of yo office but to no avail 😔. It is all in my latest Live Coding session, but I won't bother to have you go through 3 hours of messing around 😉. I might record a small video showing that it actually looks like it connected...

[TCourtneyOwen]

I have seen similar behavior in the past and following a reboot of my machine, things started working again. Not ideal, of course, but you may want to give this a try.

Can you please send me the debug console output that you see when try to attach to the addin Edge process?

[TCourtneyOwen]

I am thinking there might be an issue with the webview switcher. I just tried switching my webview to edge via the following: "npx office-addin-dev-settings webview manifest.xml edge" However I notice that the taskpane add-in doesn't in fact appear to be using Edge webview. One of the clear indicators that the add-in is using Edge webview is the existence of a WWAHost.exe process running in Task Manager and I am not seeing that.

Looping in @arttarawork who did the webview switching work to see if he might know the problem

[TCourtneyOwen]

@aafvstam One other thing to keep an eye out for. Make sure you specify the host name in the launch.json config. For example, if Excel is your host, specify the following for the url property: https://localhost:3000/taskpane.html?_host_Info=**Excel**$Win32$16.01$en-US$$$$0"

[TCourtneyOwen]

@arttarawork I actually think the webview switcher issue I mentioned is a red herring. After trying the webview swticher again, I see the WWAHost process is in fact running and I am able to attach with the debugger extension

[aafvstam]

I did some further testing on this, and for some reason it started working again. Not sure what it is that magically repaired it ... As proof (and for me to be able to remind all the steps) I created a small YouTube video with all the steps from start to end.

Video: Debugging OfficeJs Add-ins using Visual Studio Code

Note 1: (as seen in the video) updating the code initially does not reflect in the Add-in only until the breakpoint is hit again. So I guess the taskpane is not hot-reloading, although you do see the Node server recompile after saving the changes in code. Note 2: (also in the video) as opposed to the demo on the MS 365 Developer channel only hitting the Attach to Office Add-ins does not kick in Excel before attaching the Debugger, this is done manually running npm start followed by Attach to Office-Add-ins

[AltitudeApps]

I have observed that failure to attach to the desired process sometimes results from processes left over from a previous debugging session. (Note: in my scenario I have only been debugging with legacy Edge, I haven't tried to switch webviews yet.)

I have had success restoring my ability to debug by using Sysinternals Process Explorer, and doing the following:

1. sorting the processes by name
2. find the first node.exe process
3. use keystroke "Control-T", to change from list view, to tree view.
4. if you see a number of chrome.exe instances as child processes of this node.exe instance, right click on node.exe and choose "Kill process tree".
5. (check each node.exe process one by one, until you find the one which has the chrome.exe child processes.)

This happens most often when I forget to click the little "disconnect" icon on the little vscode floating toolbar.

Caveat: This is only one scenario in which I have needed to kill zombie processes to restore my ability to debug. Sometimes it's something else in the mix of the multiple processes involved in the debugging arrangement. But, only once have I needed to give up and restart my system, thus restoring my ability to successfully debug. But, usually, I can just noodle around and figure out which processes I need to kill to get going again.

Something else that I've noticed is that I have the best luck if I already have the "Microsoft Edge Devtools Preview" app running, before I attempt to click the "Start Debugging" button, with my "attach to taskpane" launch item selected. I'm fuzzy on whether or not this is actually necessary, though.

I found this thread while I was looking for help in solving this problem, so I thought I'd add to the conversation in case anyone else is having the same problem and ends up here the same way I did.

[aafvstam]

I found that it was not working (again!) ... also found the cause of it to fail:

The instructions show the following example: "url": "https://localhost:3000/taskpane.html?_host_Info=Excel$Win32$16.01$en-US$$$$0" As you can see it ends with US$$$$0

My processes however had the following: "url": "https://localhost:3000/taskpane.html?_host_Info=Excel$Win32$16.01$en-US$$$$3" Note this ends with US$$$$3

After changing the config to US$$$$3 I got it to work again.

Question is, what defines the URL entry at runtime?

[TCourtneyOwen]

@aafvstam Wow, very interesting! Thanks for calling that out! Let me look into this and see if I can find anything out. I will get back to you.

-Courtney

[AltitudeApps]

@aafvstam you, sir, have an eagle eye !

I wonder if it is incrementing that value at the end of the dollar signs? Maybe it does so if you try to launch a debugging session, and "it" thinks that there is already an instance (or three) already running...

[TCourtneyOwen]

I just sent mail to some other folks on my team to try and get some answers. I will let you know what I hear.

-Courtney

[TCourtneyOwen]

I think ideally what we should do is remove the hard-coded url requirement, check to see the webview instances running before we attempt to connect the debugger and if we find an instance matching the general url pattern connect to that. We could basically just look to see if there is an instance running that matches something like "https://localhost:3000/taskpane.html?_host_Info=HOST$Win32$16.01" and if there is one connect to it

[TCourtneyOwen]

As I look at the extension code, I do think we could implement my suggestion above without too much difficulty

[TCourtneyOwen]

I have a PR out now that fixes this issue. Here's the bulk of the code:

private async getEdgeInstanceUrl(specifiedUrl: string): Promise<string> {
    const jsonResponse = await utils.getURL(`http://127.0.0.1:${this._adapterPort}/json`);
    const edgeInstances: any = JSON.parse(jsonResponse);
    for (let key in edgeInstances) {
        if (specifiedUrl !== undefined) {
            // see if we can match with the specified url
            if (edgeInstances[key].description = "WWAHost.exe" && edgeInstances[key].url === specifiedUrl) {
                return edgeInstances[key].url;
            } else {
                // see if we can match with other Edge webview instances running on localhost
                if (edgeInstances[key].description = "WWAHost.exe" && edgeInstances[key].url.includes("https://localhost")) {
                    return edgeInstances[key].url;
                }
            }
        } else {
            // see if we can match with other Edge webview instances running on localhost
            if (edgeInstances[key].description = "WWAHost.exe" && edgeInstances[key].url.includes("https://localhost")) {
                return edgeInstances[key].url;
            }
        }
    }
    const error: string = "No Edge instances found running on local machine";
    usageDataObject.sendUsageDataException("_launchAdapter", error);
    return utils.errP(error);
}

I should be able to get this published early next week.

-Courtney

[TCourtneyOwen]

I have published a new version of the extension that includes the above changes. The changes detect if Edge webview instances exist. If they don’t exist we will return an informative error message to the user. Also, these changes handle the case where the user-specified url doesn’t match exactly with the Edge instances returned by the debug adapater. If we see that in fact an Edge instances exists on localhost, we will attach to that even if it doesn’t match exactly with what the user specified

[ndeeH]

Please support WebView2 (Chromium Based Edge)

[Shujee]

Any update on this? I can't hit my breakpoints in VSCode. I'm running it against Word 2019 (home & business), which appears to be using Chromium based edge. I have followed steps provided here:

https://docs.microsoft.com/en-us/office/dev/add-ins/testing/debug-desktop-using-edge-chromium

Is there a way to force Word 2019 to use non-Chromium Edge, to enable debugging for the time being?

[akrantz]

The latest templates have launch configs for both Edge Chromium and Edge Legacy. https://github.com/OfficeDev/Office-Addin-TaskPane/blob/master/.vscode/launch.json#L29

You can update launch.json in your project based on this.

You can always run Yo Office to get an updated starting project, and you can then port changes into your project to update it.

[Shujee]

@akrantz Thanks. That was helfpful. I'm now able to debug the addin through VSCode and my breakpoints do get hit.

One small irritant that I faced: If I run the default project template (taskpane/javascript/word), it gives me the following error:

npm ERR! missing script: start:desktop -- --app word

I had to go to tasks.json and change the script command to simply "script": "start:desktop" to get it to work. Maybe it will help someone else.

[akrantz]

@TCourtneyOwen While the default port number for the Edge WebView would be 9222, when the Office runtime creates the webview, I believe that it sets the port to 9229 if there is not a registry setting to use a different value, so it is still compatible. That is why the launch.json configs also have an explicit port set to 9229.

@igor-ribeiiro Could you please also try Yo Office for the taskpane/js/word and see if the "start:desktop" script is missing from package.json. There was a bug with VS Code where the args after -- are lost, and I think we might need to change the launch.json config to use a different way to pass the command line. There's a VS Code issue for it, but I would need to search for it.

[Shujee]

@akrantz No, the script is there and works. I just had to remove the "-- --app word" part from the npm command to get it to work, so your diagnosis might be correct; it is about the arguments being passed to the script that break it.