ECONNREFUSED 127.0.0.1:9222 when trying to run Microsoft Office Add-In Debugger - visual-studio-code

When attempting to run the debugger for the Microsoft Office Add-In Debugger extension for VS Code, I get this error when clicking the 'Play' button:
I have seen this question asked multiple times before for Chrome, but nothing specifically for Microsoft Office Add-Ins.
I have tried:
Restarting VS Code and restarting my machine
Running netstat -an | find /i "listening" to view which ports are listening on my machine, and tried replacing port 9222 with each of these ports for the "port" value in launch.json
Tried updating the port key to target port 4200, (the port which my application is hosted on, https://localhost:4200)
Verifying that the webRoot is the correct path.
Removing the port key in launch.json entirely
For reference, I am running this web add-in in Outlook native on Windows 10 version 1903.
From what I can tell, my launch.json seems okay:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Launch index.html",
"type": "office-addin",
"request": "launch",
"file": "${workspaceRoot}/index.html",
"browserTarget": "Edge"
},
{
"name": "Launch localhost with sourcemaps",
"type": "office-addin",
"request": "launch",
"url": "http://localhost/mypage.html",
"sourceMaps": true,
"webRoot": "wwwroot",
"webviewTarget": "Edge"
},
{
"type": "office-addin",
"request": "attach",
"name": "Attach to Office Add-ins",
"port": 53483,
"trace": "verbose",
"url": "https://localhost:4200/index.html?_host_Info=Outlook$Win32$16.01$en-US$$$$0",
"webRoot": "${workspaceFolder}/app",
"timeout": 45000
}
]
}
I've walked through the documentation here several times but no luck. Does anyone have any idea on how to get around this so that I can run the debugger for my Outlook web Add-In?

If you worked this out, please come back here and post an explanation so you can help us, as well as us helping you.
Note: you need to tag your office-js questions with office-js (that's what the Office JS Microsoft employees listen to and reply on)
Meanwhile - this workaround seems useful to me:
Put this into your taskpane.html:
<textarea id="out" rows=10 cols=46>debug info here</textarea>
And then instead of using console.log() you can use something like this:-
document.getElementById("out").value += "Ready...\n";
Also - it looks like you can install DevTools and the old EdgeHTML engine (by installing JavascriptBrowser) as per my comments here: Can someone from Microsoft please write a working instruction for how to debug Microsoft-365 Apps now-days (post-August-2021)

Related

Debug Flutter web app in VS Code without creating a Microsoft Edge new instance

everything is set up and working but when I start debugging flutter in vs code using microsoft edge it starts a new instance , meaning the browser data, password, settings .... are all reset, so i need to enter passwords and change settings every time i start debugging or i need to open two browser instances which is both resources intensive and clingy.
is there like vs code configuration for flutter that works as "attach" to an existing browser instance instead of "launch" a new instance ?
you have to run with following command,
flutter run -d web-server --web-port 8080 --web-hostname 0.0.0.0
then access http://<your-ip> or localhost:8080
with this you can open your flutter web-app in regular browser and also you can open it in other devices in network(with your ip)
** also you should ensure that your port(8080) is open.
Normally, if Microsoft Edge is already running when you start debugging with a launch config, then the new instance won't start in remote debugging mode.
So by default, the extension launches Microsoft Edge with a separate user profile in a temp folder. Use userDataDir to set a different path to use, or set to false to launch with your default user profile.
A simple example:
{
"configurations": [
{
"name": "Launch Microsoft Edge",
"request": "launch",
"type": "edge",
"url": "...\\Index.html", // Provide your project's url to finish configuring
"userDataDir": false // You could also add ${local_app_data}\Edge\Profile, such as C:\Users\<Current-user>\AppData\Local\Microsoft\Edge\Profile
}
]
}
I don't have a perfect solution, as this one requires you to install the Dart Debug Extension, but you can create a launch.json and paste this command:
{
"version": "0.2.0",
"configurations": [
{
"name": "Flutter Web Project",
"type": "dart",
"request": "launch",
"program": "lib/main.dart",
"args": [
"-d",
"web-server"
]
}
]
}

Can we run BotiumCLI-WebdriverIO in a headful mode and (or) Selenium Grid? If yes, can how can we modify the Botium.json to achieve this?

I am using Botium-CLI and WebdriverIO connector. I am unable to find any documentation which explains how to run the driver in headful mode (its headless by default) and also how can we modify the botium.json to trigger execution in Selenium Grid. I tried use this, didn't work :
"WEBDRIVERIO_OPTIONS": {
"capabilities": {
"browserName": "chrome"
}
"protocol": "http",
"host": "localhost",
"port": "4444",
"path": "/wd/hub"
}
Please note, I am looking for solutions for Botium CLI, not Botium Box.
With Botium Webdriver Connector, there are basically 4 ways to use Selenium.
As noticed in the question a headless Chrome can be used, see Github docs.
Botium can make use of Selenium Standalone to launch a local Selenium service on test execution, see Github docs. It requires some preparation to install the browser-specific webdrivers.
Botium can connect to your local Selenium server. You can launch your own with the help of Docker - there are instructions available for Botium Box in the Botium Box Wiki, but most of it applies to Botium CLI as well - you you have to configure the Selenium endpoint in the botium.json:
"WEBDRIVERIO_OPTIONS": {
"capabilities": {
"browserName": "chrome"
}
"protocol": "http",
"host": "my-selenium-server",
"port": "4444",
"path": "/wd/hub"
}
Finally, you can also connect to a cloud device service like Saucelabs - every provider with a public Selenium endpoint should work. Parameters are to be given in the botium.json:
"WEBDRIVERIO_OPTIONS": {
"capabilities": {
"deviceName": "Samsung Galaxy S6 GoogleAPI Emulator",
"platformName": "Android",
"platformVersion": "7.0",
"browserName": "Chrome",
"__browserName": "chrome",
"name": "Banking Chatbot Tests",
"tags": "botium, chatbot",
"username": "xxx",
"accessKey": "xxxxx"
},
"protocol": "https",
"hostname": "ondemand.saucelabs.com",
"port": 443
}

How to run Xdebug 3 on Vagrant / Homestead with VSCode (on Big Sur Mac)

Suddenly, with a new installation of Vagrant/Homestead running a freshly installed Big Sur (macOS), my (old) Xdebug configuration for some reason didn't want to work with my VSCode.
I spent a good few hours trying to figure it out, trying many different setups but with no luck. Xdebug didn't want to work.
So how to set it up correctly to make it work?
The main reason that it didn't work correctly anymore is that suddenly with the newest version of Homestead we have a Xdebug in version 3 which changes many options of Xdebug 2. It mostly simplifies the thing but also breaks previous setups. You can read more about the changes done to configuration variables in Xdebug 3 on their page.
For Xdebug to work on Homestead / Vagrant / macOS (Big Sur) these are the steps needed.
You have to find xdebug.ini location which is easily done displaying phpinfo() and checking the path, which in my case is: /etc/php/7.3/fpm/conf.d/20-xdebug.ini
Open it and edit: sudo vi /etc/php/7.3/fpm/conf.d/20-xdebug.ini:
My configuration looks like:
zend_extension=xdebug.so
xdebug.client_port = 9003
xdebug.max_nesting_level = 512
xdebug.mode=debug
xdebug.start_upon_error = true
xdebug.idekey = VSCODE
; The MacOS way
xdebug.discover_client_host = false
xdebug.client_host = 10.254.254.254
Things that has changed:
the port - now it is 9003,
for debugging setup - many options are now set using this one simple option: xdebug.mode=debug
You have to save the file and restart php-fpm by: sudo service php7.3-fpm reload
For macOS (on my Windows machine this wasn't needed) you have to:
Ensure you have created an Host address alias on MacOS and
10.254.254.254 is aliased to your localhost.
By doing: sudo ifconfig lo0 alias 10.254.254.254.
Which is in more detail also explained here.
Install VSCode PHP Debug (vscode-php-debug) extension.
Configure VSCode by clicking the debug icon from the left menu and then edit JSON file containing debugger configuration.
Paste this:
{
"version": "0.2.0",
"configurations": [
{
"name": "My XDebug on Homestead",
"type": "php",
"request": "launch",
"pathMappings": {
"/home/vagrant/code/myproject": "${workspaceFolder}"
},
"port": 9003
}
]
}
Finally install Chrome Xdebug Helper extension and turn on the (green bug) debug mode when you want to do the debugging.
One extra thing. If you want to enable/disable Xdebug, lets say for performance reasons there is a very easy and fast way to do this.
enable:
sudo phpenmod xdebug
sudo service php7.3-fpm reload
disable:
sudo phpdismod xdebug
sudo service php7.3-fpm reload
As you can see a lot of different things in different places must be set correctly to make it work. It takes a lot of googling and patience so I thought it would be useful to put it here for you and for my future installations. :)
First of all, make sure about which version of PHP-FPM your site is running (change laravel.test to the name of your configured site). Remember that you can choose the PHP version to use for each site in the Homested.yaml file.
$ cat /etc/nginx/sites-available/laravel.test | grep fastcgi_pass
fastcgi_pass unix:/var/run/php/php8.0-fpm.sock;
This will tell you which configuration file to edit in the Homestead virtual machine (NB: change 8.0 to your version of PHP, if different).
$ sudo nano /etc/php/8.0/fpm/conf.d/20-xdebug.ini
Here, you can remove all lines starting with xdebug.* and instead add these lines:
xdebug.mode=debug
xdebug.client_host=192.168.10.1
xdebug.client_port=9003
xdebug.max_nesting_level = 512
NB: 192.168.10.1 is by default the IP address of the host machine in VirtualBox, it is supposed to be different than your actual IP address in your LAN. Note that max_nesting_level is not necessary, it's a default by Homestead so I left it there.
Now in Visual Studio Code on your host machine you can set your launch.json file to the following:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Listen for Xdebug",
"type": "php",
"request": "launch",
// "stopOnEntry": true,
"pathMappings": {
"/home/vagrant/laravel.test": "${workspaceFolder}"
},
"port": 9003
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}",
"port": 9003
}
]
}
PS. I keep "stopOnEntry": true commented so that I can simply uncomment it when needed, otherwise I simply use breakpoints in vscode.
for Xdebug Version 3.0.3
set IDE to use a debugging port - 9003
modify the /etc/php/7.x/fpm/conf.d/20-xdebug.ini
zend_extension = xdebug.so
xdebug.remote_port = 9003
xdebug.max_nesting_level = 512
xdebug.mode = debug
xdebug.client_host = 192.168.10.1
If Homestead.yaml contains a different subnet for the IP address, this IP address may be different...
BTW, after editing 20-xdebug.ini, restart you FPM like so
$ sudo service php7.4-fpm restart
and restart your browser and IDE
PS
Tested on NetBeans and Vagrant (Laravel homestead) with php 7.4, host - WIN-10

How to show source code when debugging node against a remote process

I have a nodejs app running in docker container in Linux. I am using VSCode in Windows 10 to remotely debug it. I successfully connect to the container and VSCode accurately displays remote logs in Debug Console. If I manually add a 'debugger' statement in the node code (in published docker image) I get the correct break in VSCode. Then, and only then, can I add dynamic breakpoints to ONLY that js file.
The "LOADED Scripts" does not show/stream any other programs to my VSCode session. The only thing I see are VMxxxxx scripts which are compressed, unreadable and unusable for adding breakpoints.
How do I get the code to stream down? I understand it is read-only and that's all I care about.
My launch.json file contains the following config:
{
"type": "node",
"request": "attach",
"name": "Attach to Remote QA",
"port": 9229,
"address": "11.222.333.444",
"localRoot": "${workspaceFolder}",
"remoteRoot": "/opt/myApp",
"protocol": "inspector",
"sourceMaps": true
}
Thanks in advance for any assistance.
Rob
The config MUST include:
{
"type": "node",
"request": "attach",
"name": "Attach to Remote QA",
"port": 9229,
"address": "11.222.333.444",
"localRoot": "${workspaceFolder}",
"remoteRoot": "//opt//myApp//",
"protocol": "inspector",
"sourceMaps": false,
"init": "what-you-need-here-to-watch"
}

VSCode failed to attach to process

I am using VSCode on Windows to debug a process on remote Linux host. I have added launch configuration that look like this:
{
"type": "gdb",
"request": "attach",
"name": "Attach to PID",
"target": "3441",
"cwd": "${workspaceRoot}"
},
But when I am trying to launch debugged I get this output in Debug console:
Attaching to process 3441
[New LWP 3442]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
47 ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory.
Not implemented stop reason (assuming exception): undefined
The last line looks suspicious as if the debugger was not able to stop the process for some reason. At the same time a message box with the following text is displayed:
Failed to attach: Cannot change this setting while the inferior is running. (from gdb-set target-async on)
I tried running gdb on the machine through ssh and attach to the process and it works ok.
So the question is: how do I get this running? I also tried enabling logging by adding this to launch.json:
"logging": {
"engineLogging": false
}
But vscode editor claims Property logging is not allowed and it doesn't seem to make any difference.
Any ideas?