Visual Studio Code
Visual Studio Code is a cross-platform, free and open-source (licensed under the MIT License) text editor developed by Microsoft and written in JavaScript and TypeScript. It is built on the Electron framework and is extensible using extensions, which can be browsed on the web or from within the text editor itself. While the project is open-source, a proprietary build (licensed under an End-User License Agreement) is also provided by Microsoft. For an explanation of the mixed licensing, see this GitHub comment.
Contents
- 1 Installation
- 2 Usage
- 3 Configuration
-
4 Troubleshooting
- 4.1 Global menu not working in KDE/Plasma
- 4.2 Unable to move items to trash
- 4.3 Unable to debug C#
- 4.4 Unable to open .csproj with OmniSharp server, invalid Microsoft.Common.props location
- 4.5 Error from OmniSharp that MSBuild cannot be located
- 4.6 Saving with "Retry as Sudo" does not work
- 4.7 Keyboard variants or keymappings do not map
- 4.8 Command 'remote-containers.openFolder' not found
Installation
The following packages provide VSCode:
- code (open-source release)
- visual-studio-code-binAUR (Microsoft-branded release)
- visual-studio-code-insidersAUR (Microsoft-branded release, updated daily)
- code-gitAUR (in-development open-source version)
- vscodium-binAUR (another open-source version with a community-driven default configuration)
The Microsoft ptvsd (Python Tools for Visual Studio Debug) server/module is available at python-ptvsdAUR.
Usage
Run code
to start the application (or code-git
when using code-gitAUR).
If for any reason you wish to launch multiple instances of Visual Studio Code, the -n
flag can be used.
Configuration
code stores settings in ~/.config/Code - OSS/User/settings.json
.
visual-studio-code-binAUR stores settings in ~/.config/Code/User/settings.json
.
Integrated Terminal
View > Integrated Terminal or Ctrl + `
opens up an integrated terminal.
By default, Bash is used with no additional arguments, although this can be changed.
terminal.integrated.shell.linux
sets the default shell to be used and
terminal.integrated.shellArgs.linux
sets the arguments to be passed to the shell.
Example:
~/.config/Code/User/settings.json
"terminal.integrated.shell.linux": "/usr/bin/fish", "terminal.integrated.shellArgs.linux": ["-l","-d 3"]
You might face weird prompts after setting the integrated shell arguments with external terminal, remove the line to solve the problem or use an external terminal.
External terminal
If you are using Terminator as default terminal for Arch and you have an error on Visual Studio Code: Unable to launch debugger worker process (vsdbg) through the terminal. spawn truecolor ENOENT
, you can change the terminal that will be used by Visual Studio to another terminal (e.g. gnome-terminal).
"terminal.external.linuxExec": "Your alternative terminal"
sets the default terminal to be used for exec debug.
Example:
~/.config/Code/User/settings.json
"terminal.external.linuxExec": "gnome-terminal"
Troubleshooting
Visual Studio Code uses DBus to pass the menu to Plasma, try installing libdbusmenu-glib
Unable to move items to trash
By default, Electron apps use gio
to delete files. Different trash implementations can be used by setting the ELECTRON_TRASH
environment variable.
For example, for deleting files under Plasma:
$ ELECTRON_TRASH=kioclient5 code
At the time of writing, Electron supports kioclient5
, kioclient
, trash-cli
, gio
(default) and gvfs-trash
(deprecated). More info is available at this documentation page.
Unable to debug C#
If you want to debug C#.NET (using the OmniSharp extension) then you need to install the Microsoft branded release (from the AUR). This is apparently because the .NET Core debugger is only licensed to be used with official Microsoft products - see https://github.com/OmniSharp/omnisharp-vscode/issues/1431#issuecomment-297578930
Using the the open-source package, debugging fails fairly quietly. The debug console will just show the initial message and nothing more:
You may only use the Microsoft .NET Core Debugger (vsdbg) with Visual Studio Code, Visual Studio or Visual Studio for Mac software to help you develop and test your applications.
But in another way, you can use netcoredbg,netcoredbgAUR
Unable to open .csproj with OmniSharp server, invalid Microsoft.Common.props location
You have to switch from mono to proper SDK version props.
/opt/dotnet/sdk/{VERSION}/Sdks/Microsoft.NET.Sdk/Sdk/Sdk.props
$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props
Modify import to look like this:
/opt/dotnet/sdk/{VERSION}/Sdks/Microsoft.NET.Sdk/Sdk/Sdk.props
/opt/dotnet/sdk/{VERSION}/Current/Microsoft.Common.props
Error from OmniSharp that MSBuild cannot be located
It is noted in the OmniSharp introduction that Arch Linux users should install the msbuild-stableAUR package. Without it, you might get an error like:
OmniSharp Log
[info]: OmniSharp.MSBuild.Discovery.MSBuildLocator Registered MSBuild instance: StandAlone 15.0 - "~/.vscode/extensions/ms-vscode.csharp-1.18.0/.omnisharp/1.32.11/omnisharp/msbuild/15.0/Bin" MSBuildExtensionsPath = /usr/lib/mono/xbuild BypassFrameworkInstallChecks = true CscToolPath = ~/.vscode/extensions/ms-vscode.csharp-1.18.0/.omnisharp/1.32.11/omnisharp/msbuild/15.0/Bin/Roslyn CscToolExe = csc.exe MSBuildToolsPath = ~/.vscode/extensions/ms-vscode.csharp-1.18.0/.omnisharp/1.32.11/omnisharp/msbuild/15.0/Bin TargetFrameworkRootPath = /usr/lib/mono/xbuild-frameworks System.TypeLoadException: Could not load type of field 'OmniSharp.MSBuild.ProjectManager:_queue' (13) due to: Could not load file or assembly 'System.Threading.Tasks.Dataflow, Version=4.5.24.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. ...
You might be able to build anyway (possibly depending whether you have mono installed too)
Saving with "Retry as Sudo" does not work
This feature does not work in the code package, because Microsoft does not support the way the Arch package is packaged (native instead of bundled Electron). See FS#61516 and the upstream bug report for more information.
The binary release visual-studio-code-binAUR does not have this issue, and the feature works there.
Keyboard variants or keymappings do not map
As per the wiki on github:
- Switching keyboard layouts under some Linux window managers does not result in a change in the low level X window APIs VS Code uses to read the current keyboard layout. This means that VS Code ends up sometimes reading one of the other configured keyboard layouts and not the current active one. PR welcome...
Per the wiki, there are two possible solutions:
- make sure setxkbmap -query returns as the first keyboard layout the one you want to work with in VS Code.
- use "keyboard.dispatch": "keyCode" in your settings and restart VS Code. This will prevent VS Code from trying to determine your keyboard layout whatsoever.
Command 'remote-containers.openFolder' not found
Open VS Code enabling remote-containers API as commented in Bugs
$ code-oss --enable-proposed-api ms-vscode-remote.remote-containers