I'm trying to get debugging of Office Add-ins working through VS Code. I've installed the Microsoft Office Add-in Debugger extension as well as the Debugger for Chrome extension. I have a section in my launch.json file that has a preLaunchTask that uses start:web.
I'm confused about how this process works, currently it opens two chrome windows, which I didn't expect. It looks like only one of the windows will actually cause VS Code to break on my breakpoints.
I'd like to hard code my document URL while debugging, so I don't have to keep entering it with an inputs promptString. I guess I'm confused about how these two files work together to start debugging and where do I need to enter the URL to my Excel file in SharePoint.
launch.json
{
"name": "Office Online (Chrome)",
"type": "chrome",
"request": "launch",
"webRoot": "${workspaceFolder}",
"preLaunchTask": "Debug: Web",
"url": "https://UrlToMyTestExcelDocumentInSharePoint"
}
tasks.json
{
"label": "Debug: Web",
"type": "npm",
"script": "start:web -- --document https://UrlToMyTestExcelDocumentInSharePoint",
"presentation": {
"clear": true,
"panel": "shared",
"showReuseMessage": false
},
"problemMatcher": []
}
Related
In a Python project, how do you tell the built-in VSCode debugger to step into the code of functions from other libraries on execution?
I know it is possible for functions implemented in standard libraries by adding a
"debugOptions": ["DebugStdLib"]
to your configuration in launch.json as specified here, however it does not seem to be possible to force the debugger to step into the code of non-standard modules, such as the ones you have written yourself and imported into the current file.
In order to improve the accepted answer by John Smith, it is worth mentioning that now the option has been renamed again. The new option is
"justMyCode": false
and as per the documentation
When omitted or set to True (the default), restricts debugging to
user-written code only. Set to False to also enable debugging of
standard library functions.
This is done by customising your debugger.
If you haven't already, you need to initialise the debugger customisation. You can do this by opening the debugger section in the side bar and selecting create a launch.json file.
Once this is done, a launch.json file will be created in a .vscode folder in your workspace.
Edit this file. It will look something like this:
{
...,
"configurations": [
{
"name": "Python: Current File",
"type": "python",
"request": "launch",
"program": "${file}",
"console": "integratedTerminal"
}
]
}
Add "justMyCode": false to the "Python: Current File" configuration, like this:
{
...,
"configurations": [
{
"name": "Python: Current File",
"type": "python",
"request": "launch",
"program": "${file}",
"console": "integratedTerminal",
"justMyCode": false
}
]
}
True as of Visual Studio Code version 1.59.0.
Reference:
https://code.visualstudio.com/docs/python/debugging
A debugger configuration with
"debugOptions": ["DebugStdLib"]
added in launch.json in fact will step into user-defined and pip-installed modules, contrary to what's written in the main question.
Most of the time, I debug unit tests rather than the running application.
If that is also the case on your side and you use:
Visual Studio Code
pytest
The Python Test Explorer for Visual Studio Code (A test runner extension (adds a debug menu and provided debug buttons above tests directly in the IDE)) https://marketplace.visualstudio.com/items?itemName=LittleFoxTeam.vscode-python-test-adapter
Then use the following launch.json as mentionned in the plugin page:
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug test",
"type": "python",
"request": "attach",
"console": "externalTerminal",
"justMyCode": false,
"stopOnEntry": true,
"envFile": "${workspaceFolder}/.env.test",
"purpose": ["debug-test"]
}
]
}
For those using the standard VSCode Debugger, a little more clarification on how to configure this in VS Code might be needed
Create Your Debugger Configuration As Follows
Open up your .vscode/launch.json
Add a configuration {} to the configurations list:
"configurations": []
This one will be recognized by the built-in VSCode Debugger:
{
"name": "Python: Debug Tests",
"type": "python",
"request": "launch",
"program": "${file}",
"purpose": ["debug-test"],
"console": "integratedTerminal",
"justMyCode": false
}
Key points:
purpose should be set to ["debug-test"]
"justMyCode": should be set to false.
References: Official VSCode Docs
The configurations in launch.json file as follows work for me.
"configurations": [
{
"name": "Python: Current File",
"type": "python",
"request": "test",
"program": "${file}",
"console": "integratedTerminal",
"justMyCode": false,
"purpose": ["debug-in-terminal"]
}
]
I downloaded the "Debugger for Firefox" extension for VS Code. And it launches a new Firefox Developer Browser window in "remote control" mode.
This mode doesn't load any extensions or carry-over any settings, its like a brand new factory-reset browser without any settings or preferences.
I want to use both the Firefox React Extension in my browser, and the one in VS Code, but I can't get them to load together.
Any ideas?
Here is my launch.json file:
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch localhost",
"type": "firefox",
//"firefoxExecutable": "C:/Program Files/Firefox Developer Edition/firefox.exe",
//"firefoxArgs": ["-start-debugger-server","-no-remote"],
"request": "launch",
"reAttach": true,
"url": "http://localhost:3000",
"webRoot": "${workspaceFolder}/frontend/",
}
]
}
As you can see I tried adding some Args to the Launch but they don't help.
I wanna continue update dwm (Dynamic Window Manager) for myself. Previously I just built and ran dwm on another tty via startx. But this not provide debugging via IDE.
Can I satrt dwm from VSCode with debugging?
I tried to add simply launch.json:
{
"version": "0.2.0",
"configurations": [
{
"type": "lldb",
"request": "launch",
"name": "Debug",
"program": "${workspaceFolder}/dwm",
"args": [],
"cwd": "${workspaceFolder}"
}
]
}
But when I run it I get error:
dwm: another window manager is already running
Would like to set up VS Code to work with Cygwin/Cygwin64.
Already have these set up:
Installed Cygwin64 on windows
Installed gcc (Compiler) and gdb (Debugger) packages from Cygwin installer
GCC and GDB are NOT in windows path.
Installed Visual Studio Code
Posting this because it took me a couple of days from multiple different sources to set this up.
This is specifically for Windows with Cygwin/Cygwin64 installed.
DISCLAIMER: I've only tested this for building single files.
Instructions here are for setting up on VS Code
Install the extension C/C++ on VS Code
Name: C/C++
Id: ms-vscode.cpptools
Description: C/C++ IntelliSense, debugging, and code browsing.
Version: 0.23.1
Publisher: Microsoft
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools
If you have a workspace already, skip this step.
Create a folder and add this folder into VS Code. Then save workspace.
Set up launch.json
Go to "Debug > Open Configurations", this should open the launch.json file. Below is my configuration. If you're testing this and unsure of what you're doing, I suggest you save your original content somewhere before replacing things.
Note: "preLaunchTask": "gcc.exe build active file" runs the task labelled "gcc.exe build active file".
{
"version": "0.2.0",
"configurations": [
{
"name": "gcc.exe build and debug active file",
"type": "cppdbg",
"request": "launch",
"program": "${fileDirname}\\${fileBasenameNoExtension}.exe",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [
{
"name": "PATH",
"value": "%PATH%;z:\\cygwin64\\bin"
}
],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "C:\\cygwin64\\bin\\gdb.exe",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"logging": { "engineLogging": true }, //optional
"preLaunchTask": "gcc.exe build active file"
}
]
}
Set up task.json
Go to "Terminal > Configure Tasks..." and select "gcc.exe build active file"
The various "-W" flags in "args" are meant to make the compiler more strict. You can remove them if you'd like.
{
"tasks": [
{
"type": "shell",
"label": "gcc.exe build active file",
"command": "C:\\cygwin64\\bin\\gcc.exe",
"args": [
"-g",
"-o",
"${fileDirname}\\${fileBasenameNoExtension}.exe",
"-Werror", // Optional
"-Wall", // Optional
"-Wextra", // Optional
"-ansi", // Optional
"-pedantic", // Optional
"${file}"
],
"options": {
"cwd": "C:\\cygwin64\\bin"
},
"problemMatcher": [
"$gcc"
],
"group": {
"kind": "build",
"isDefault": true
}
},
],
"version": "2.0.0"
}
Build and Debug Active File
Go to the C file you want to build, press Ctrl+Shift+P for "Command Palette > C/C++ Build and Debug Active File > gcc.exe build active file" or if you only want to build then go to "Terminal > Run Build Task".
Cygwin64 is inefficient because it is using a medium memory model. This makes it use 64 bit absolute addresses instead of 32 bit relative addresses for static data.
I will recommend to use the Clang plugin for Visual Studio instead, unless you have a specific reason to use Cygwin64. See https://devblogs.microsoft.com/cppblog/clang-llvm-support-in-visual-studio/
You also get rid of the cygwin DLL when using the Clang plugin.
I cannot figure out how to setup debugging in VS Code so I can serve the app with node in WSL. I am using:
Debugger for Chrome
React app created with create-react-app
Starting server in bash (WSL) via npm start
This works in that is launches a new browser window and the app is served, but I cannot set any break points. They all report Unverified breakpoint.
This is my launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "React",
"type": "chrome",
"request": "launch",
"url": "http://localhost:3000",
"webRoot": "${workspaceRoot}/src"
}
]
}
The problem seems related to webpack, but I can't figure out what I need to do differently.
I have also struggled with this problem and found a solution:
My Setup
Visual Studio Code 1.43.2
Debugger for Chrome 4.12.6
Visual Studio Code Remote - WSL 0.42.4
React Application (create-react-app)
NPM 6.13.7 running in WSL (npm start)
LOCAL => WSL
Use the following configuration in your launch.json if you have started your vscode instance locally (not using WSL) and want to connect to a NPM instance running in WSL.
{
"name": "chrome-localhost-local-to-wsl",
"type": "chrome",
"request": "launch",
"url": "http://localhost:3000",
"webRoot": "${workspaceRoot}",
"sourceMapPathOverrides": {
"/mnt/c/*": "C:/*"
}
},
WSL => WSL
Use the following configuration in your launch.json if you have started your vscode instance via WSL (using the Visual Studio Code Remote - WSL extension) and want to connect to a NPM instance running in WSL.
{
"name": "chrome-localhost-wsl-to-wsl",
"type": "chrome",
"request": "launch",
"url": "http://localhost:3000",
"webRoot": "${workspaceRoot}",
"sourceMapPathOverrides": {
"/mnt/c/*": "/__vscode-remote-uri__/mnt/c/*",
},
}
You might have to adjust the drive in both configurations. I am running everything from C:/dev so /mnt/c/* is perfectly fine for me. If you have your code located for example at D:/dev/demo/src you will have to use /mnt/d/*.
What helped me a lot to debug what is going on was the .script command of the Debugger for Chrome extension.
Update: It seems that something has changed recently in the integration of WSL, Chrome and VSCode so the sourceMapPathOverrides are not required anymore. We successfully use the following configuration now for our WSL Setup:
{
"name": "chrome-localhost-wsl-to-wsl",
"type": "chrome",
"request": "launch",
"url": "http://localhost:3000",
"webRoot": "${workspaceRoot}",
}
You just need to add a sourceMapPathOverrides to your launch.json. It ends up looking something like this:
{
"version": "0.2.0",
"configurations": [
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://localhost:3000",
"webRoot": "${workspaceFolder}",
"sourceMapPathOverrides": { "/mnt/c/*": "C:/*" }
}
]
}
I'm about 99% sure this cannot be done: run react app under linux (wsl) and try to debug in VS Code under Windows. The problem is that the source map created when you run the app in linux is using linux file names, but VS Code needs windows paths. The clue was in looking at the sources in dev tools. When run under linux, there were linux file paths.
Initial workaround is to just run app under windows and I'm happily debugging now. Longer term is to try out what Sung Kim suggested and try to just do my editing in WSL also.