Visual Studio Code Wsl

Posted on by



The final useful component is Visual Studio Code and some helpful extensions. I recommend that you install Visual Studio Code in your windows environment. In order to get the maximum usefulness out of this setup, you need to install a couple of extensions: Remote - WSL. When the Remote WSL extension starts the VS Code server in WSL, it does not run any shell configuration scripts. This was done to avoid that custom configuration scripts can prevent the startup. If you need to configure the startup environment, you can use the environment setup script as described here. To get started with using WSL in VS Code, you'll need to download the Remote - WSL extension from the Extension Marketplace. You'll also need WSL and a Linux distribution installed. We recommend using WSL 2, which is the newest version of WSL, as you will benefit from significant performance advantages over WSL 1. Check out Remote - WSL in action.

It is a long time since I did the last post... I was kind of busy finalizing a book. Also, COVID19 and the remote only working periods steal my commuting writing time. Two hours on the train that I used to use to write blog posts and stuff. My book is finished and will be published soon and to make 2021 better than 2020, I force myself to write for my blog.

For a while, I have the WSL2 (Windows Subsystem for Linux) installed on my computer to play around with Linux and to work with Docker. We did a lot using Docker the last year at the YOO and id is pretty easy using Docker Desktop and the WSL. Recently I had to check a demo building and running on Linux. My first thought was using and running a Docker container to work with, but this seemed to be too much effort for a simple check.

So why not do this in the WSL directly?

If you don't have the WSL installed, you should follow this installation guide: https://docs.microsoft.com/en-us/windows/wsl/install-win10

If the WSL is installed, you will have a Ubuntu terminal to work with. It seems this hosts the wsl.exe that is the actual bash to work:

You can also start the wsl.exe directly, or host it in the Windows Terminal or in the cmder which is my favorite terminal:

Installing the .NET 5 SDK

The installation packages for the Linux distributions are a little bit hidden inside the docs. You can follow the links from https://dot.net or just look here for the Ubuntu packages: https://docs.microsoft.com/de-de/dotnet/core/install/linux#ubuntu

As you can see in the first screenshot, my WSL2 is based on Ubuntu 18.04 LTS. So, I should choose the link to the package for this specific version:

The link forwards me to the installation guide.

At first, I need to download and add the key to the Microsoft package repository. Otherwise, I won't be able to download and install the package:

After that, I can install the .NET 5 SDK:

This needs some time to finalize. If this is done, you can prove the installation by typing dotnet --info into the terminal:

That's it about the installation of the .NET 5 SDK. Now let's create a project

Creating a ASP.NET Core project inside the WSL

This doesn't really differ from creating a project on Windows, except it is on the Linux file system.

Create a Razor Pages project using the dotnet CLI

After changing into the project directory you can start it using the following command

You can now see the familiar output in your terminal:

The cool thing now is that you can call the running web with your local browser. The request gets directly forwarded into the WSL:

Terminal

That's it about creating and running an application inside the WSL. Let's see how you can use your local VSCode to develop inside the WSL

Developing inside WSL using Visual Studio Code

To remotely develop in the WSL using VSCode, you need to have the Remote - WSL extension installed

Visual Studio Code Wsl 2

This extension will be visible in the Remote Explorer in VS Code. It directly shows you the existing WSL Target on your computer:

Right-click the Ubuntu-18.08 item and connect, or click the small connect icon on the right of the WSL item to connect to the WSL. This opens a new instance of VSCode that doesn't have a folder open. If you now open a folder, you can directly select the project folder from inside the WSL:

Click OK or press Enter, if you selected the right folder. When you connect the first time, it installs the VSCode Server inside the WSL, which is the actual VSCode instance that does the actual work. You really work, code, and debug inside the WSL. Your local VSCode instance is a terminal session into the WSL. IntelliSense, code analysis, and all the good stuff act inside the WSL. This also means you might need to install VSCode Extensions again in the WSL, even if you already installed it on your machine. Even the VSCode terminal is connected to the WSL:

The Explorer shows you the current project:

To see that remote coding is working, I open the _Layout.cshtml in the Pages/Shared/ folder and change the app titles to make it a little more readable. I change all wsldemo to WSL Demo:

There is another occurrence at the end of the file.

What I didn't try until I write this line, is to press F5 in VS Code to start debugging the application. So I do now and voila: debugging starts and a browser opens and shows my changes:

That's it.

Conclusion

This was really easy and smoothly done. Microsoft did a lot to make remote development as easy as possible. Now I'm able to also test my applications on Linux or to develop for Linux.

Actually, I didn't expect that I can call a web that runs inside the WSL directly in a browser in Windows. This makes testing and front end debugging really easy.

To not mess up the WSL, I would avoid doing too much different things on it. Installing a .NET 5 runtime isn't a big thing, but if I also want to test a Nginx integration or other stuff, I would go with Docker Containers. Remote development inside a Docker container is also possible and I will write about it in one of the next posts.

-->

Git is the most commonly used version control system. With Git, you can track changes you make to files, so you have a record of what has been done, and have the ability to revert to earlier versions of the files if needed. Git also makes collaboration easier, allowing changes by multiple people to all be merged into one source.

Git can be installed on Windows AND on WSL

An important consideration: when you enable WSL and install a Linux distribution, you are installing a new file system, separated from the Windows NTFS C: drive on your machine. In Linux, drives are not given letters. They are given mount points. The root of your file system / is the mount point of your root partition, or folder, in the case of WSL. Not everything under / is the same drive. For example, on my laptop, I've installed two version of Ubuntu (20.04 and 18.04), as well as Debian. If I open those distributions, select the home directory with the command cd ~, and then enter the command explorer.exe ., Windows File Explorer will open and show me the directory path for that distribution.

Linux distroWindows Path to access home folder
Ubuntu 20.04wsl$Ubuntu-20.04homeusername
Ubuntu 18.04wsl$Ubuntu-18.04homeusername
Debianwsl$Debianhomeusername
Windows PowerShellC:Usersusername

Tip

If you are seeking to access the Windows file directory from your WSL distribution command line, instead of C:Usersusername, the directory would be accessed using /mnt/c/Users/username, because the Linux distribution views your Windows file system as a mounted drive.

You will need to install Git on each file system that you intend to use it with.

Installing Git

Git comes already installed with most of the Windows Subsystem for Linux distributions, however, you may want to update to the latest version. You also will need to set up your git config file.

To install Git, see the Git Download for Linux site. Each Linux distribution has their own package manager and install command.

For the latest stable Git version in Ubuntu/Debian, enter the command:

Note

You also may want to install Git for Windows if you haven't already.

Git config file setup

To set up your Git config file, open a command line for the distribution you're working in and set your name with this command (replacing 'Your Name' with your Git username):

Set your email with this command (replacing 'youremail@domain.com' with the email you use on your Git account):

Vs Code Wsl2

Tip

If you don't yet have a Git account, you can sign-up for one on GitHub. If you've never worked with Git before, GitHub Guides can help you get started. If you need to edit your git config, you can do so with a built-in text editor like nano: nano ~/.gitconfig.

We recommend that you secure your account with two-factor authentication (2FA).

Git Credential Manager setup

Git Credential Manager enables you to authenticate a remote Git server, even if you have a complex authentication pattern like two-factor authentication, Azure Active Directory, or using SSH remote URLs that require an SSH key password for every git push. Git Credential Manager integrates into the authentication flow for services like GitHub and, once you're authenticated to your hosting provider, requests a new authentication token. It then stores the token securely in the Windows Credential Manager. After the first time, you can use git to talk to your hosting provider without needing to re-authenticate. It will just access the token in the Windows Credential Manager.

To set up Git Credential Manager for use with a WSL distribution, open your distribution and enter this command:

Now any git operation you perform within your WSL distribution will use the credential manager. If you already have credentials cached for a host, it will access them from the credential manager. If not, you'll receive a dialog response requesting your credentials, even if you're in a Linux console.

Visual Studio Code Wsl Debug

Note

If you are using a GPG key for code signing security, you may need to associate your GPG key with your GitHub email.

Visual Studio Code Wsl Remote

Adding a Git Ignore file

We recommend adding a .gitignore file to your projects. GitHub offers a collection of useful .gitignore templates with recommended .gitignore file setups organized according to your use-case. For example, here is GitHub's default gitignore template for a Node.js project.

Visual Studio Code Wsl2

If you choose to create a new repo using the GitHub website, there are check boxes available to initialize your repo with a README file, .gitignore file set up for your specific project type, and options to add a license if you need one.

Develop Under Remote Wsl Or Remote Container

Git and VS Code

Visual Studio Code comes with built-in support for Git, including a source control tab that will show your changes and handle a variety of git commands for you. Learn more about VS Code's Git support.

Visual Studio Code Wsl

Git line endings

If you are working with the same repository folder between Windows, WSL, or a container, be sure to set up consistent line endings.

Since Windows and Linux use different default line endings, Git may report a large number of modified files that have no differences aside from their line endings. To prevent this from happening, you can disable line ending conversion using a .gitattributes file or globally on the Windows side. See this VS Code doc about resolving Git line ending issues.

Additional resources