Visual Studio Wsl



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. You need Visual Studio Code installed. Install the extension. The Remote - WSL extension enables you to run Visual Studio Code within the Windows Subsystem for Linux (WSL). Install the Remote - WSL extension. Prerequisite check. With the Remote - WSL extension installed, you will see a new Status bar item at the far left.

Visual Studio Wsl Cmake

When using a remote connection, Visual Studio builds C Linux projects on the remote machine. It doesn't matter if it's a physical machine, a VM in the cloud, or WSL. To build the project, Visual Studio copies the source code to your remote Linux computer. Then, the code gets compiled based on.

Now included in Visual Studio 2019!

This extension is now available as an optional feature in Visual Studio 2019 v16.9 Preview 1 and will no longer be updated on the marketplace. To download the preview goto https://aka.ms/vspreview

The .NET Core Debugging with WSL 2 – Preview extension lets you run and debug your .NET Core console and web applications in WSL 2 from Visual Studio. This allows Windows developers targeting Linux production environments to have a higher fidelity local debugging experience.

Get started with .NET Core Debugging with WSL 2

  1. Open an ASP.NET Core web app or .NET Core console App
  2. Change the Launch Profile to “WSL 2”
  3. Press F5
    Note: If you want to verify that your code is running in WSL 2, you can check the value of Environment.OSVersion

Prerequisites

  • Visual Studio 2019 v16.6:https://aka.ms/vs
  • .NET Core Tools:https://get.dot.net
  • WSL 2:https://aka.ms/wsl
  • WSL 2 distribution:https://aka.ms/wslstore

Prerequisites for distributions other than Debian and Ubuntu

Only Debian and Ubuntu are tested and supported, but other distributions should work as long as you have installed:

  • .NET Core runtimehttps://aka.ms/WslDotNet
  • Curl:https://curl.haxx.se/

Configuring your WSL 2 debugging experience:

Example launch Profile:

Supported Launch Profile Settings:

SettingUseDefault
commandNameMust be WSL2WSL2
distributionNameName of the distribution to run in, or ' to use the default distribution.'
executablePathPath to rundotnet
commandLineArgsArguments to pass to executablePathThe projects output assembly.
workingDirectoryThe directory in which to start executablePathFor ASP.NET Core web apps, the project folder; for .NET Core console Apps, the output folder.
environmentVariablesList of environment variables to set for executablePath.null
launchBrowserWhether or not to launch a browser.false
launchUrlUrl to use for launching a browser.null

What's new in 0.2

  • Support for choosing the distribution to use.
  • Support for custom values of automount:root.
  • Removed the dependency on Debian's dpkg command.
  • Some smaller bug fixes.

Known Issues

  • [Only on Visual Studio 2019 v16.9 Preview 1] If a preview version of .NET 5.0 has been installed in the WSL distribution you will not be prompted to install the released version. To fix this you will need to manually install .NET 5.0 using the instructions here
  • Applications running in WSL 2 cannot access networking apps running on Windows through localhost (see https://docs.microsoft.com/en-us/windows/wsl/compare-versions#accessing-windows-networking-apps-from-linux-host-ip for mitigations).
  • Authenticating to Azure services using the credentials from VS is not supported. The easiest way to authenticate with Azure in your app in WSL 2 is to use Azure.Identity (1.2.0-preview.1 or newer), install the Azure CLI in your WSL 2 distribution and run az login.
  • ASP.Net Core development certificates are not trusted within WSL 2. Any service to service calls over HTTPS will need to handle allowing the untrusted development certificate when running locally.
  • Blazor Web Assembly Debugging is not currently supported.
  • The enabled key of the automount section in the wsl configuration file must be left at its default value of true.

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?

Wsl

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.

Studio

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:

Wsl2

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

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.

Visual Studio Wsl Setup

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.

Visual Studio WslVisual studio wallpaper

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.