I like to do my dev work in a virtual machine so that I can keep my host system as clean as possible.
Developers tend to install lots and lots of alpha and beta level libraries, frameworks, SDKs, and just about anything else we can get our grubby little mits on.
That inevetably leads to system destabilization and a death spiral which inexorably degrades into the collapse of civillization as we know it. Well maybe not that bad, but pretty darned bad.
The only true fix is to start anew with a fresh install of the OS. A pain with your host system, a bit less painful with a VM.
For a while I've been using a Windows 11 VM hosted in Hyper-V. Fun fact the Windows 11 installer says it can't run on my desktop hardware. Yet it happily runs in a VM on that same hardware.
The main draw for me sticking with Windows is gaming, I'm not going to lie. The other day I tried to fire up Cyberpunk 2077 and couldn't because of a lack of RAM. Yada, yada, yada, my dev VM had to be shut down.
What Ever Shall I Do?
My first thought was to switch to Linux. See Developing with dotnet on Fedora for more of my thoughts on dotnet and Linux.
Then it hit me. WSL 2 is a Linux VM.
OK, so it is a hosting system for Linux VMs, but you get the idea.
This is on the list of things I knew but didn't really think about much. I've used WSL and WSL 2 for years, but didn't really think of it as a VM in its own right.
Part of that might be the fact that WSL 1 was not a VM in its own right.
Visual Studio Code Rocks on
I've been a fan of Visual Studio Code for a long, long time First Look at Visual Studio Code.
It continues to blow me away with what it has become and how it continues to evolve.
I had read that work had been done to connect Visual Studio Code on Windows with Linux running in WSL 2, but hadn't played with it yet.
So the holiday break seemed like a grand time to tinker.
What About Terminal?
OK, you really do want to use the new-ish Windows Terminal.
In one of the following sets of documentation, they say it is optional, but trust me, it isn't optional.
Lack of a good terminal has been a pain in Windows forever, but now we have one we can love. I still have love for ConEmu, but it is so easy to get Terminal now that it is my default choice.
Setting Up
There really aren't a bunch of things you need to do to set up VS Code and WSL 2.
Not covered here will be setting up WSL 2 and Ubuntu. Let me know if you want to know more about that topic.
I picked Ubuntu because frankly it has the most support from Microsoft. Path of least resistance and all that.
Install dotnet
The exact steps depend on the version of Ubuntu you are running, but more or less you:
- Tell the APT system about Microsoft's repositories
- Update APT to pull the entries you'll need
- Tell APT to get the version of dotnet SDK you want
It's going to look something like this:
wget https://packages.microsoft.com/config/ubuntu/22.10/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-7.0
Personally I like to break that last one up into two steps instead of running them together, but that's just me.
Once you do that you should be able to run dotnet --version and see that it is installed.
Configure VS Code
Next you'll want to set up VS Code to talk to WSL 2.
The key bit here is the Visual Studio Code Remote Development Extension Pack.
This extension will actually let you reach into containers, WSL 2, or even remote machines and run the head end of Visual Studio on your local machine.
In addition to debugging in WSL, I could even connect to my actual server VM via SSH and debug directly there. I wouldn't recommend doing that, but you could.
The only other step here is really to install wget and update your certs.
sudo apt-get update
sudo apt-get install wget ca-certificates
Again if you aren't on Ubuntu (or another Debian based distro), you may need to adjust to a different package manager instead of APT.
At this point you can cd yourself into a directory with a dotnet app and just enter code . to load that directory in VS Code running in the host Windows system.
Debugging
Opening and editing a project is awesome, but what about running and debugging?
You could just dotnet run in the terminal and run the app, but you really want to debug it in VS Code, right?
Unofficial But Awesome Instructions.
The above Kontext post by Raymond Tang provides an excellent tutorial on setting up Visual Studio Code to debug (with hot reload!) apps running in WSL.
I won't repeat his content here, but long story short you just need to create or modify your launch.json file.
You may need to modify your tasks.json file as well depending on what you are doing.
What's Next?
So now that I can debug ASP apps like GatorSmileCMS in WSL 2, I want to add some automation.
Since most of the steps above are at the command line, I should be able to put them into a script that I can run whenever I want to set up a new Linux instance in WSL.
I'll check that into my private GitHub repo and then I'll be able to start with a new Linux VM without too much pain.
I've used Visual Studio for decades at this point, but I've always loved lighter, more nimble experiences.
VS Code provides an excellent alternative, provided you don't load it up with too many extensions. 😉