C++ with Visual Studio and WSL2
Our team released native support for C++ with the Windows Subsystem for Linux (WSL) in Visual Studio in 2019. “Native support” means that all commands are executed locally instead of over a SSH connection. Since then, WSL2 has been announced and we’ve received questions about our support for WSL2 in Visual Studio. The purpose of this blog post is to:
- Clarify our existing support for WSL1 and WSL2,
- Introduce our plans to add native support for WSL2,
- Gather feedback from customers who have used our native support for WSL1 in Visual Studio through this two-question survey. Update 1/22/2021: This survey is now closed.
Current support for WSL1 and WSL2
Our native support for WSL currently works best with WSL1. Our support executes all commands locally through wsl.exe and relies on Windows drives mounted under the /mnt folder (e.g. /mnt/c/Users…) to access local source files from WSL. These commands are slower with WSL2 because file performance across the Windows and Linux operating systems is faster with WSL1 than WSL2. You can learn more about the differences between WSL1 and WSL2 here.
To avoid these slowdowns, you can install and run SSH on your local WSL2 installation and add a new SSH connection to WSL2 in the Visual Studio Connection Manager. Learn how to install and configure SSH on your WSL installation here.
Native support for WSL2
We are working to add native support for WSL2 in Visual Studio. This will allow you to seamlessly build and debug on WSL2 without adding a SSH connection or observing the slowdowns described above.
How it will work
Behind the scenes, Visual Studio will execute a local rsync copy to copy files from the Windows file system to the WSL2 file system. We’re not able to continue accessing the mounted Windows drives from WSL (as we do with WSL1) because file performance across the Windows and Linux operating systems is slower in WSL2. This local rsync copy will occur automatically when Visual Studio detects that you are using WSL2 and will require no user intervention. You will no longer need to establish a SSH connection to avoid the slowdowns described above, and there will be no change in your ability to build and debug locally on WSL2.
Provide feedback on our support for WSL2
If you have used our native support for WSL1 in Visual Studio, then we would love your feedback on our plans for WSL2. Please submit this short, two-question survey to help us build the best features for your C++ development needs. Update 1/22/2021: This survey is now closed.
Re: How it will work
This feels very inelegant, and disheartening to hear that there’s so much effort going into working around this fundamental problem, rather than the problem just being fixed in the first place. Also reveals that the WSL2 /mnt/ slowdown will not be fixed any time soon. :/
I second Riley L, the ability to access (possibly huge) resources on Windows drives without having to copy them is crucial for my development work.