Setting up a dotnet dev environment with WSL and Ubuntu 24.04
Posted on
I just knew 2026 was going to start off this way... A complicated setup to do something that should be simple.
Ok, so you want to do some .NET dev work with WSL? Better not choose Ubuntu 24.04 as your distro. I guess this version doesn't ship with some important packages that are needed to make some interop work between Windows and Linux. Anyways, let's get to the steps!
Configure Git for authentication with Azure DevOps
Make sure you have installed Git For Windows on your host machine. Your git installed in Linux will need to use the credential manager in Windows.
Configure the credential helper: git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe"
Configure using HTTP: git config --global credential.https://dev.azure.com.useHttpPath true
Set environment variable in ~/.bashrc to force a dialog to popup for authentication so you don't end up using Device Flow (which some tenants, like mine, disallow)
Install packages that allow the browser to be opened from MSAL This part is crucial. When you run dotnet restore --interactive, MSAL will want to open your system's browser so you can use OAuth to sign in and provide credentials for your Azure DevOps instance. Install these packages, which no longer ship with Ubuntu:
apt update
apt install xdg-utils
apt install wslu
wslu is a discontinued project that consisted of utilities for WSL and xdg-open is a program that will open the system's browser.
Edit: If WSL interop stops working You may need to add a WSL interop config (source)
sudo vim /usr/lib/binfmt.d/WSLInterop.conf
Add this line:
:WSLInterop:M::MZ::/init:PF
“Vendoring” software is a technique where you copy the source of another project directly into your own project.
I love this idea, so many times you need to debug into your dependencies to figure out an issue or why things aren't working as you expected.
I mainly develop in C# and .NET and am fortunate to work at Microsoft, so I've done this many times in the past where I grab the source for a dependency, copy it into my code, update the references, and start debugging. This is always a temporary step. I don't actually check in the dependent code. I don't do it that often anymore, as you can enable debug options to disable "just my code" and if your dependencies publish symbols (most do in my experience), you can just F11 and step into library code from Nuget packages.
In the future, I may take up the vendoring approach for web frontends, where licenses allow. If nothing else, it gives me peace of mind that the dependency won't just disappear from the CDN.
