I have recently been using a combination of CMake and NMake from the Build Tools for Visual Studio 2022 package. I would like to integrate that with VSCode's task system but it appears to not be using the environment I have set up.
If I run cmake -B build in a Visual Studio 2022 Developer PowerShell instance in Windows Terminal it will generate an makefile designed to be used with NMake as I have set the environment variable needed to do that by default. I have changed VSCode's default instance of PowerShell to use the same arguments on start up so now if I run cmake -B build in the default VSCode terminal I also get a makefile designed to be used with NMake.
The problem occurs when I try to make a tasks.json task that calls cmake -B build for me, instead of generating an NMake makefile it defaults to a Visual Studio project. When I tried to add -G NMake Makefiles to the task arguments it failed stating it couldn't find NMake. I assumed this was because the tasks doesn't call the same startup parameters that a terminal does so replicated the same config I used for changing the VSCode's default terminal to the
Dev version but it didn't fix the issue.
My task:
"label": "cmake_setup_debug",
"type": "process",
"command": "cmake",
"args": [
"-G",
"NMake Makefiles",
"-B",
"${workspaceFolder}/bin/debug"
],
"problemMatcher": [],
"options": {
"shell": {
"executable": "powershell.exe",
"args": [
"-noexit",
"-command",
"&{Import-Module 'C:/Program Files (x86)/Microsoft Visual Studio/2022/BuildTools/Common7/Tools/Microsoft.VisualStudio.DevShell.dll'; Enter-VsDevShell 0d22feab -SkipAutomaticLocation -DevCmdArguments -arch=x64}"
],
}
}
Is it possible to force a task to use a specific instance of powershell with all the needed start up parameters?
Related
I am running into the error Failed to install .NET runtime v5.0. when using bicep in visual studio code on a windows machine.
I'm not sure why it's not able to find it automatically, but manually specifying the dotnet path in settings.json resolved the problem.
"dotnetAcquisitionExtension.existingDotnetPath": [
{
"extensionId": "ms-azuretools.vscode-bicep",
"path": "C:\\Program Files\\dotnet\\dotnet.exe"
}
]
I normally use git-bash.exe on Windows 10 but visual studio code seems to use bash.exe. bash.exe seems very limited :(
I am trying to either get bash.exe to be more useful or get git-bash.exe to run in the terminal at the bottom of the screen.
Any suggestions?
// this opens the terminal window at the bottom of code
// but as I said, seems limited.
{
"shell": "C:\\Program Files\\Git\\bin\\bash.exe",
"label": "Git bash"
}
// the problem with this is it opens a new window when
// run and I would prefer it be at the bottom.
{
"shell": "C:\\Program Files\\Git\\git-bash.exe",
"label": "Git bash"
},
I'm trying to compile some C code in visual studio with gcc using WSL.
I've got a super simple configuration that executes on an F5 Press
"version": "0.2.0",
"configurations": [
{
"name": "Build And Run",
"type": "cppvsdbg",
"request": "launch",
"program": "${workspaceFolder}/.vscode/BuildAndRun.bat",
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"externalConsole": true,
"environment": [],
},]
Which then should execute the batch file that contains a simple call to wsl and gcc
#echo off
wsl gcc main.c
pause
When I run this bat file by clicking on it, it works and everything compiles. however when I press F5 I get an error that 'wsl' is not recognized as an internal or external command.
I've tried adding it to Path and that didnt help.
I should also add that when I run the command inside the vs terminal it works, which just confuses me even more.
https://code.visualstudio.com/docs/cpp/launch-json-reference
program (required)
Specifies the full path to the executable the debugger will launch or attach to.
The debugger requires this location in order to load debug symbols
program is the executable for debugger to attach, not compile your code. Compile your C program via preLaunchTask in launch.json and config that command in tasks.json. See https://code.visualstudio.com/docs/cpp/config-mingw for reference.
Also, you may need WSL-Remote plugin and work directly in WSL, See also https://code.visualstudio.com/docs/cpp/config-wsl
I have a build task in tasks.json of C# .net-core project under VS Code 1.32.3. If I run the task within tasks.json, it fails with MSBUILD : error MSB1001: Unknown switch.
Switch: --run-time linux-arm
Executing task: C:\Program Files\dotnet\dotnet.exe publish --runtime linux-arm --configuration Debug --self-contained false M:\ProjectsGit\HelloWorldVSCode/HelloWorldVSCode.csproj <
Microsoft (R) Build Engine version 16.0.385-preview+g966cdf2ac6 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
MSBUILD : error MSB1001: Unknown switch.
Switch: --runtime linux-arm
If I copy and paste the same command to VS Code terminal it works! Where is the error in the --runtime switch?
PS M:\ProjectsGit\HelloWorldVSCode> dotnet.exe publish --runtime linux-arm --configuration Debug --self-contained false M:\ProjectsGit\HelloWorldVSCode/HelloWorldVSCode.csprojMicrosoft (R) Build Engine version 16.0.385-preview+g966cdf2ac6 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restore completed in 25.18 ms for M:\ProjectsGit\HelloWorldVSCode\HelloWorldVSCode.csproj.
C:\Program Files\dotnet\sdk\3.0.100-preview-010184\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(151,5): message NETSDK1057: You are using a preview version of .NET Core. See: https://aka.ms/dotnet-core-preview [M:\ProjectsGit\HelloWorldVSCode\HelloWorldVSCode.csproj]
HelloWorldVSCode -> M:\ProjectsGit\HelloWorldVSCode\bin\Debug\netcoreapp3.0\linux-arm\HelloWorldVSCode.dll
HelloWorldVSCode -> M:\ProjectsGit\HelloWorldVSCode\bin\Debug\netcoreapp3.0\linux-arm\publish\
PS M:\ProjectsGit\HelloWorldVSCode>
Make sure to separate your arguments at spaces. Instead of:
"args": [
"publish",
"${workspaceFolder}/HelloWorldVSCode/HelloWorldVSCode.csproj",
"--runtime linux-arm",
"--configuration Debug",
"--self-contained",
],
Try something like this instead:
"args": [
"publish",
"${workspaceFolder}/HelloWorldVSCode/HelloWorldVSCode.csproj",
"--runtime",
"linux-arm",
"--configuration",
"Debug",
"--self-contained",
"false",
],
The args list here doesn't take well to spaces. Alternatively, you can make use of the fact that the dotnet CLI tolerates using = as well, so the following should also work:
"args": [
"publish",
"${workspaceFolder}/HelloWorldVSCode/HelloWorldVSCode.csproj",
"--runtime=linux-arm",
"--configuration=Debug",
"--self-contained=false",
],
I am in the process of switching a project from Gulp 3.9.1 (npm install gulp) to Gulp 4.0 (npm install gulp-4.0.build), but when I do this, Visual Studio Code is no longer able to auto-detect the tasks in my gulpfile.js. In both cases, gulp is installed locally.
My .vscode/tasks.json looks like:
{
"version": "0.1.0",
"command": "gulp",
"isShellCommand": true,
"showOutput": "always"
}
Looking at the Tasks output, I see the following message:
Running gulp --tasks-simple didn't list any tasks. Did you run npm install?
Can you use Gulp 4.0 with VS Code and have it autodetect the tasks? If so, what steps do I need to follow to get it setup?
Yes, you can use vscode and gulp4.0. I would look at how to upgrade to gulp4.0.
Did you uninstall gulp3.9.1 first?
You should also install gulp4.0 both locally and globally!
Then run
gulp -v
to make sure it worked. vsCode should detect both tasks in your tasks.json file and from your gulpfile.js. You are using the older tasks.json version 0.1.0. Here is an example of a tasks.json file which allows me to type "gulp sync" in the command line from anywhere in the workspaceRoot and run that task:
{
"version": "2.0.0",
"tasks": [
{
"label": "Start server and process files",
"command": "gulp",
"args": [
"sync"
],
"type": "shell",
"options": {
"cwd": "${workspaceRoot}"
}
}
]
}
It runs the "sync" task I defined in my gulpfile.js. In fact you can assign a hotkey combo to that such as:
{ "key": "shift+escape",
"command": "workbench.action.tasks.runTask",
"args": "Start server and process files"
},
in your keybindings.json.