VSCode 1.20.0 on Windows 10, with C# extension ms-vscode.csharp 1.14.0.
VSCode Terminal points to bash (Windows Subsystem for Linux)
VSCode is opened on a folder containing a .NET CORE 2.0 C# project
Everything is fine, intellisense works, project references are understood.
Whenever I switch focus to the VS Code terminal and type "dotnet build" or "dotnet test", VSCode gets confused. Red Squigglies underline every line of source code, intellisense stops working, and VSCode opens two info boxes that say
Info: There are unresolved dependencies from src\Project.csproj. Please execute the restore command to continue.
Info: There are unresolved dependencies from test\Project.Tests.csproj. Please execute the restore command to continue.
When I click the "Restore" button inside the info box, about 15 seconds later the project works again. But why, this happens all the time, I tend to dotnet build frequently. Can I configure VS Code differently to avoid this problem? It doesn't seem right that building code would break the editor functionality so I must be doing something wrong.
EDIT:
This problem seems to repro only if I dotnet build or dotnet test in WSL\bash (whether Internal or External Terminal). It doesn't seem to repro when I build or test in an external cmd.exe
EDIT:
cmd.exe dotnet --info
.NET Command Line Tools (2.1.4)
Product Information:
Version: 2.1.4
Commit SHA-1 hash: 5e8add2190
Runtime Environment:
OS Name: Windows
OS Version: 10.0.16299
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.4\
Microsoft .NET Core Shared Framework Host
Version : 2.0.5
Build : 17373eb129b3b05aa18ece963f8795d65ef8ea54
WSL\bash $ dotnet --info
.NET Command Line Tools (2.0.3)
Product Information:
Version: 2.0.3
Commit SHA-1 hash: eb1d5ee318
Runtime Environment:
OS Name: ubuntu
OS Version: 16.04
OS Platform: Linux
RID: ubuntu.16.04-x64
Base Path: /usr/share/dotnet/sdk/2.0.3/
Microsoft .NET Core Shared Framework Host
Version : 2.0.3
Build : a9190d4a75f4a982ae4b4fa8d1a24526566c69df
The reason this might be happening could be because VS Code is using Omnisharp running on Windows - when you build using Bash, you are building for linux, and therefore all the reference paths generated in files in the obj folder will be linux paths, not Windows paths.
When Omnisharp looks for the referenced dependencies for intellisense in VS Code, it can't find them, and so VS Code requests you to restore your project.
You could confirm by checking any of the files in the obj folder, and looking at the paths.
EDIT - 2019
Just an update on this - things are looking promising. We will soon be able to use the VS Code Remote Extension Pack to run extensions INSIDE the WSL environment (or Docker Containers or even over SSH sessions). This is pretty awesome - it should mean that not only does our code run in WSL, but the extensions will also - and therefore OmniSharp extension will be running in WSL, using the Linux binaries for intellisense etc.
I am personally pretty excited by the new tools Microsoft is releasing. Its a really god time to be developing on the Windows platform with tools like WSL, VS Code, Docker and Hyper V... and the upcoming WSL 2 is going to be incredible (FULL Linux Kernal baked into Windows!!!)
Related
In tutorial requirement is install vscode in windows and install Remote Development extension pack. Why not just install in wsl?
I've install vscode to wsl. When I run code in wsl I get message:
To use Visual Studio Code with the Windows Subsystem for Linux, please install Visual Studio Code in Windows and uninstall the Linux version in WSL. You can then use the `code` command in a WSL terminal just as you would in a normal command prompt.
Do you want to continue anyway? [y/N]
To no longer see this prompt, start Visual Studio Code with the environment variable DONT_PROMPT_WSL_INSTALL defined.
Which cons of run vscode in wsl as opposed to run it in Windows?
The WSL extension splits VS Code into a “client-server” architecture, with the client (the user interface) running on your Windows machine and the server (your code, Git, plugins, etc) running "remotely" in your WSL distribution.
When VS Code is started in WSL, no shell startup scripts are run.
The extension runs commands and other extensions directly in WSL so you can edit files located in WSL or the mounted Windows filesystem (for example /mnt/c) without worrying about pathing issues, binary compatibility, or other cross-OS challenges.
(source: MSFT DOCUMENTATION)
This is the architectural choice of Windows and - personally speaking - I feel like it's a choice to avoid conflicts and redundancies.
When running the WSL extension, selecting the 'Extensions' tab will display a list of extensions split between your local machine and your WSL distribution.
Installing a local extension, like a theme, only needs to be installed once.
Some extensions, like the Python extension or anything that handles things like linting or debugging, must be installed separately on each WSL distribution. VS Code will display a warning icon ⚠, along with a green "Install in WSL" button, if you have an extension locally installed that is not installed on your WSL distribution.
Recently I updated my Windows 10 Pro with May Update (version 1903, build 18362.116). Then for my existing distros: OpenSuse Leap 15 and Ubuntu (installed from MS Store), I wanted to open a linux directory by using Explorer and I'm getting this message:
[susedis#mypc ~]$ explorer.exe .
If 'explorer.exe' is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf explorer.exe
This problem happens also with VSC (code) and VSC-Insiders (code-insiders).
I've read this article and ...
OPTION 1: my current problem
OPTION 2: icon LINUX does not exist in tree view
OPTION 3: it works
Supposedly options 1 and 2 should exist and work, even more with the latest update. What's wrong? Thanks in advance.
PS1: I've found these articles Run Visual Studio Code for Linux from WSL and Using Visual Studio Code with Windows Subsystem for Linux, they talk about installing xserver and more stuff on side linux. But many other articles and videos don't talk about it, it's like it was a built-in feature of Windows. This is so dark.
I just found what is the root of my problem: the distro.
explorer, code, code-insiders commands ONLY work through UBUNTU and I was using OpenSuse.
This warning is lacking in every article on Web I read, including on VSC site (example: Developing in WSL). This is a disadvantage for other distros. Very bad.
PS1: The solution can be found here.
I cloned the WebPack Docks repository. Now, when I open that repository in Visual Studio Code, I want to run the NPM script build from that repository. Yet, that doesn't work because the build script uses sh.
So, I installed WSL and an Umbuntu distribution, hoping that's the right direction to go.
Now, how can I have VS Code (on Windows) utilize the Linux dist to run NPM scripts, without me being required to mirror all NPM development tools to the Linux OS which I already have installed on Windows.
I'm using Visual Studio 2017. Below is the output from a Visual Studio Developer command prompt indicating the C++ version.
C:\ProgramsNotInstalled\OpenDDS-3.13>cl /?
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27024.1 for x86
Following that, I see the following output when running the configure --java command.
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.3
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
C:\ProgramsNotInstalled\OpenDDS-3.13>configure
ERROR: Could not detect Visual C++ version, try running this script from the Visual Studio Command Prompt.
Stopped at configure line 421.
C:\ProgramsNotInstalled\OpenDDS-3.13>configure --java
ERROR: Could not detect Visual C++ version, try running this script from the Visual Studio Command Prompt.
Stopped at configure line 421.
C:\ProgramsNotInstalled\OpenDDS-3.13>
I saw a similar question posed for DDS 3.12 on stack overflow but that answer has to do with language. That is clearly not the problem in my case, and I am running the configure script from the correct type of command prompt. This question is not a duplicate.
How to install OpenDDS 3.12 on windows system
Evidently, the configure script cannot always detect the compiler version automatically. I'm not good at reading perl scripts because I don't know perl well, but I found an option to help the script.
First determine the exact version of the C++ compiler by running this line:
cl /?
Now using the output of that, add the --compiler option to the command line.
configure --compiler=19.16.27024.1 --java
The instructions within the INSTALL file and README were not clear on that point. I ran configure --help to look at the command line options and that is how I learned that the script will try to autodetect the compiler. My guess is that the script is looking for a specific C++ compiler version or it is using a regex that isn't working well.
This is a small issue in the configure script of OpenDDS 3.13 which is caused by a change in the compiler version which was not known at release time. When you would pull github master (see https://github.com/objectcomputing/OpenDDS) this should work again, or wait until OpenDDS 3.14.
I just started with VS Code today as I have to prepare to port some of my code to Linux and I noticed that in the Terminal section there is the option of having a WSL bash, so I thought I could use this to compile my projects with gcc right there. I already installed Ubuntu for Windows 10 from the MSFT Store some time ago an installed several packages there. The thing is that the Ubuntu bash doesn't seem to share to the Linux workspace with the bash I see in VS Code, since in the latter I am lacking all those packages I already installed; it seems to be a completely different installation. Also, I noticed that the bash in the VS Code terminal uses German language while the Ubuntu App's bash is in English. (I have no idea why this is since Windows as well as VS Code is English.)
I'm quite confused about these differences, how do ubuntu.exe and bash.exe relate to each other? Can anybody shed some light on this? Obviously, it would be preferrable to to have only ONE Linux workspace in WSL so I don't have to have duplicates (of my data and also the installed packages) at different places.
To use WSL bash in VS Code integrated terminal, you need to add/change setting:
"terminal.integrated.shell.windows": "C:\\Windows\\System32\\bash.exe",
Restart VS Code or integrated terminal.
If two or more WSL distro are installed, then you need to specify the path to the desired distro.
For example you can find it by running: where ubuntu, where ubuntu1604 or where ubuntu1804. And change the settings to the desired ones. For example:
"terminal.integrated.shell.windows": "C:\\Users\\USERNAME\\AppData\\Local\\Microsoft\\WindowsApps\\ubuntu1604.exe",