How to make Windows a proper development environment

Microsoft Windows has improved massively as a developer environment over the past few years. Windows Subsystem for Linux (WSL) lets you work seamlessly with Linux on Windows without the clunk and overhead of a VM. All of the popular software development tools that figure into common workflows exist in native Windows editions. And Microsoft has introduced a slew of developer amenities directly into the OS that still don’t get the billing they deserve.

None of this is automatic, though. If you want to take maximum advantage of Windows as a development system, you’ll need to do a little legwork. The work isn’t far out of line from the usual ways developers tweak their work environments, but the specific steps matter — and some of them aren’t obvious.

Here’s a walk through the five most important steps to take to configure a Windows system for software development work. Note that you’ll need admin rights on the system to accomplish many of tasks.

Step 1. Install Windows Subsystem for Linux

WSL gives Windows users an entire Linux system at the command line, with less overhead than a VM. The lion’s share of the world’s software development work happens on Linux, or a Unix-like system like macOS, so having an actual Linux system available in a terminal session is a huge boon.

To install WSL, open an admin-elevated console and enter:

wsl --install

Installation may take some time, as the system will need to download both the core bits for WSL and a Linux distribution to run with it.

The default Linux distribution in WSL is Ubuntu 26.04 LTS. As defaults go, Ubuntu will satisfy most of what a developer might need from a Linux distribution. However, other distributions are available and more are being added regularly. You can even build your own custom Linux distribution for WSL.

Once WSL is installed, you can enter wsl --list --online to see all of the available distributions. Enter wsl --install (use the names from the left-hand column) to install one.

Most of choices suit different tastes or a specific need. For instance, if you are most comfortable with Debian Linux, or you are developing a project that assumes Debian as the substrate, you’d want to install Debian. But Ubuntu should work for most use cases.

WSL distros are stored by default in your user’s AppData directory, under AppData\Local\Packages\. If you want to relocate the files to another directory or volume, you can use the command wsl --manage --move .

Microsoft recently introduced a major new feature for WSL, WSL container, that allows you to run Linux containers natively on Windows. WSL container is currently in public preview.

Step 2. Configure a Dev Drive volume for your projects

Most Windows users will simply default to using a directory on an NTFS volume to store their projects, whether in one’s user profile or on another path. This isn’t a bad default, but it leaves better options on the table. One of them is Dev Drive.

Dev Drive is a newer type of volume offered on Windows. Instead of NTFS, it uses a newer file system called ReFS (“Resilient File System”), which was originally developed for Windows Server. ReFS offers features that complement the kinds of workloads that come up in software development:

• Copy-on-write. Project directories can have thousands of files and dozens of directories. Making copies of those projects can be handled much faster with ReFS, because it makes copies of files only when they’re changed, not merely when they’re copied. Unchanged copies are on-disk links to the originals.
• Better control over antivirus behavior. Dev Drives, by default, minimize the interference caused by Windows’s native antivirus tools. It’s possible to manually exclude development directories from scanning, but the mere act of setting up a Dev Drive automates how scanning is managed on its contents.
• VHD or partition. Dev Drives can be set up as a virtual hard disk file or used directly on a formatted partition. The former is more flexible (easier to resize, for one); the latter may be slightly more performant.

Two things you should keep in mind about Dev Drives:

1. Dev Drives are for projects, not tools. Store your project repositories, build artifacts, and cached files on Dev Drives. Do not install language runtimes, compilers, or other toolchain utilities on them. Use regular NTFS volumes for that.
2. Low-level file system tools may not work as intended on Dev Drive volumes. Expert-level file system utilities that work by directly reading file table information may not behave as intended with Dev Drives (and ReFS volumes generally). For instance, the disk space management tool WizTree, which reads NTFS volume data directly for better performance, slows to a crawl when used on ReFS volumes.

Step 3. Use WinGet for package management

Until recently, Windows had nothing like a formal package management system, or a central package manager. The Microsoft Store wasn’t a solution. It only installed apps that conformed to the Universal Windows Platform packaging system, only provided apps specifically delivered through the Microsoft Store, and had no command-line interface.

More recently, Microsoft introduced a proper package management system for Windows: WinGet. WinGet installs any type of Windows app, and provides a full command-line interface for interaction and automation. Plus, it’s broadly supported by the Windows software ecosystem. Odds are that any Windows program you might want has a WinGet package. That makes WinGet an ideal way to grab all the tooling you will need in your development system. (More on this later.)

To search the WinGet repository for a package, enter:

winget search "Thing to search for"

The quotes are needed if the package you seek has spaces in the name, e.g., Adobe Acrobat Reader.

Installing a WinGet package is simple enough:

winget install 

where is the Id (not the name!) of the package to install. For Adobe Acrobat Reader, as per above, you would enter:

winget install Adobe.Acrobat.Reader.64-bit

If you want a nice GUI for your package management workflow, look into UniGetUI. UniGetUI manages packages for multiple package management sources — WinGet, Scoop, Chocolatey, npm, pip, Cargo, and many more.

Step 4. Set up PowerShell to allow scripts

This is a one-and-done tweak you’ll want to get out of the way before doing too much else. It’s a PowerShell incantation to allow local scripts to run.

Launch PowerShell as administrator and enter:

set-executionpolicy remotesigned

You only need to do this once for the lifetime of the system. Windows will still require any PowerShell scripts you download from the internet to be signed, but that’s essentially an edge case. Any scripts you create locally will work as-is.

Step 5. Install your must-have development tools

WinGet gives you fast access to all of the most common tools you’d want on a dev-centric Windows system. Chances are you already have your preferred tools, but here’s a rundown of the biggest things useful in Windows development, along with their WinGet Ids for easy installation.

• Git (Git.Git): Everyone’s favorite version control system. The Windows version is essentially identical to other platforms.
• Visual Studio BuildTools 2022 (Microsoft.VisualStudio.2022.BuildTools): The minimal command-line tooling needed to use Microsoft Visual Studio’s C/C++ compilation system.
• CMake (Kitware.Cmake): Cross-platform build solution for C/C++. Frequently needed for larger or more complex projects using those languages.

Note that the default BuildTools installation generally lacks the tools to perform minimal C/C++ build operations. Running this command should give you what you need:

winget install -e --id Microsoft.VisualStudio.2022.BuildTools --force --override "--passive --wait --add Microsoft.VisualStudio.Workload.VCTools;includeRecommended"

All of the popular editors are also available as native Windows apps:

• Microsoft Visual Studio Code (Microsoft.VisualStudioCode)
• GNU Emacs (GNU.Emacs)
• Neovim (Neovim.Neovim)

Some other tools for developing in Windows are optional, but useful:

• CoreUtils for Windows (Microsoft.Coreutils): A Microsoft-maintained open-source project that brings dozens of Linux command-line utilities to Windows, such as cp, grep, find, and ls.
• MSYS2 (MSYS2.MSYS2): A collection of tools for building Windows binaries using the GCC compiler. Basically, an alternative to the Visual Studio build stack based on the Cygwin environment.
• LLVM (LLVM.LLVM): The compiler framework that powers Clang, Rust, Swift, and many other projects. Note that if you are using LLVM as a dependency, you will need to install the specific version of LLVM that your project requires.
• Docker Desktop (XP8CBJ40XLBWKX): The Windows-native version of the Docker Desktop application.
• Microsoft PowerToys (Microsoft.PowerToys): A collection of 30-plus utilities that make tweaking Windows a good deal easier — a hosts file editor, a file unlocking tool (handy for identifying which processes are locking a given file), a window pinning tool, a text extractor tool (handy for reading text from anywhere, including parts of the screen that can’t be highlighted with the cursor), and many more.

A Windows development system in one step

Most developers like having complete control over the installations and configuration of their development system. But others may want an out-of-the-box, opinionated starter kit. For those who want the shortcut, Microsoft provides Windows Developer Config.

Windows Developer Config is a collection of PowerShell scripts that set up your system as a development environment. You can choose from a complete dev workstation setup, a “WSL Comfort” setup that focuses on command-line tooling, or one of several language-specific workload setups that give you the compiler/interpreter, additional tools, and VS Code extensions.