通过WSL从源代码启动VSCode

Question

I would like to build/launch the VSCode source code in the native Bash for Windows client. I have followed the steps outlined in the VSCode wiki on how to contribute, and everything is working as expected (All commands have been run on the WSL terminal following the Linux instructions)

After running yarn run watch , I try to launch VSCode by running DISPLAY=:0 ./scripts/code.sh from the source code directory, but nothing happens. I get two duplicate warnings:

[21496:1128/120229.392130:WARNING:audio_manager.cc(295)] Multiple instances of AudioManager detected

but I'm not sure if this is causing the problem. I have an X Server client running, and have used to to successfully launch native Windows applications through WSL (terminator, emacs, etc.)

Is what I'm trying to do possible? If so, how can I make it work?

Answer 1

Amazing that you asked this! I was attempting to do the exact same thing at (it seems) the exact same time . Here's my process.

1. Install XMing
2. Install the xfree apps
3. Set DISPLAY=:0
4. Run xeyes ==> Awesome googly eyes!
5. Attempt to build vscode from source. The build docs seem to be incomplete b/c I had to install a ton of libraries beyond those listed eg

yarn gulp gulp-cli pkg-config libx11-dev libxkbfile-dev libsecret-1-dev libgtk2.0-dev libxss-dev gnome-dev libgconf2-dev libnss3-dev libasound2-dev

Eventually get the yarn tasks to finish such that I could run code.sh

./scripts/code.sh [20474:1128/153959.035267:ERROR:bus.cc(427)] Failed to connect to the bus: F ailed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory [20474:1128/153959.081986:WARNING:audio_manager.cc(295)] Multiple instances of AudioManager detected [20474:1128/153959.082101:WARNING:audio_manager.cc(254)] Multiple instances of AudioManager detected

Looking at ps I see that the process was running.

Conjectures

It seems that building from source from WSL is not yet supported. Or maybe you can build the artifact, but you can't connect to the Windows display to show it. Based on the quality of the xeyes session, it looks like a very, very, very primitive experience eg still using WinXP-style minimize / maximize / close icons.

I was literally writing an Issue on their github page when I thought I'd do one last search and found this post. Much of vscode treats WSL as a second-class environment on Windows. Recent work seems to suggest that things are going to get better as driving to integration between Windows' two internal environments continues to improve (eg https://github.com/Microsoft/vscode/issues/39144 )

Update 2017-11-30

Based on some pursuit via Github, it seems that this issue has been reported to the WSL team: https://github.com/Microsoft/WSL/issues/2293 . It appears to be under active consideration by the WSL team. I've added some commentary about my use case there.