Developing on Windows, the WSL life

The Windows developer experience has evolved quite allot in the last 5-10 years. I now spend most of my development life running Windows with WSL2 and using Windows Terminal and winget. So here are a few pointers from my experiences so far.

WSL (WSL2)

WSL2 is what you want! The first version of WSL was a step in a great direction, but had many cons, such as IO performance. It should be fairly easy to install and will provide you a full Linux Kernel accessible from within Windows.

WSL also has access to your Windows filesystem via a mount at /mnt/c. Generally if you are using Linux tooling, you’ll want your file access to remain in the Linux file system. For example, I have almost all of my git repositories checked out in my Linux file system. For the odd repository that I use mainly Windows tooling I leave in Windows land.

Packages

I use apt for Linux land and winget for Windows land. You can start to see the Windows ecosystem imitating some of the best parts of the loved Linux experience. For example, to install git in Linux, you have apt install git. And to install git in Windows you can now do winget install git.

Generally speaking packages installed on each side of the Windows / Linux line are only accessible from that side. And you probably only want to access the binaries for the appropriate side. Though you can always run the Windows binaries from a Linux shell by specifying git.exe for example. On the odd occasion it’s helpful to do something like explorer.exe . on the Linux side, to get a Windows experience.

Windows Terminal

There are many ways to install Windows Terminal. You’ll note one of the README suggestions is winget.

winget install --id=Microsoft.WindowsTerminal -e

This will give you easy command line access to both your installed Linux distro, and Windows Command Prompt / Powershell if you ever need it.

Docker

Docker for Windows, which is installable with winget install docker will run Linux containers on WSL2 behind the scenes. Although WSL2 still uses virtualization under the surface, its much faster than any virtualization from things such as Docker Toolbox etc.

When installed the docker CLI will give you and option to be available in select Linux distros. You should choose this option for your distro to have a mostly seamless experience.

SSH

I use KeePassXC in Windows land, that has the ability to load ssh keys into an SSH agent. One of the easy checkbox options is now called Use OpenSSH for Windows instead of Pageant, which you will want to enable.

With a small bit of “magic” I copied from a README on github you can fairly easily pipe the built in Windows SSH agent through to Linux. In my .bashrc it looks somehthing like this:

export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
export WINHOME=/mnt/c/Users/adam
ss -a | grep -q $SSH_AUTH_SOCK
if [ $? -ne 0   ]; then
    rm -f $SSH_AUTH_SOCK
    ( setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"$WINHOME/bin/npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork & ) >/dev/null 2>&1
fiCode language: JavaScript (javascript)

Note, I also had to download npiperelay.exe. which I saved to %USERPROFILE%/bin/npiperelay.exe, on the Windows side.

IDEs

Personally I use VSCode with its included WSL remote support. This provides a seamless experiences between both Windows and Linux file systems.

Every now and again I do still want to use one of the many JetBrains IDEs. For these cases I’ll install the IDE in the appropriate side, Linux or Windows, and run it there. Here you can make use of GUI support for Linux apps (If you are running any version of Windows 11 Build 22000 or higher).

Disclaimer

This post should act as a good overview of Windows development using WSL2.

It’s been quite some time since I set up some parts of this, such as the SSH Agent tunnel, so it could be slightly wrong.

Generally speaking I love this setup, and am happy to answer any questions on it etc.

Feel free to reach out to me in the comments, on Twitter or elsewhere.