Windows Developer Config

Opinionated setups for Windows dev boxes. Idempotent. CI-tested.

Windows Dev Config · WSL Comfort · Workloads · Troubleshooting

Your dev environment should help you ship, not become another project to debug. Try the new Windows developer configuration and spend less time setting up, more time building something awesome.

🎯 Pick your setup

Three developer setups live in this repo. Pick the one that matches what you want:

🖥️ Windows Dev Config

Turns a fresh Windows 11 box into a clean, distraction-free dev workstation in one shot.

A set of PowerShell scripts that installs dev tools, applies opinionated Windows settings, and sets up WSL + Ubuntu through the required reboot. Nothing to clone, nothing to install first. Idempotent, so it's safe to re-run on an existing machine.

Open any PowerShell window — elevated or not — and run:

Standard

irm https://aka.ms/devconfig/standard/setup.ps1 | iex

Full experience

irm https://aka.ms/devconfig/full/setup.ps1 | iex

⚠️ It will restart your machine, once. Enabling WSL needs a Windows optional feature that requires a restart. You get a 10-second warning, and a scheduled task resumes setup after you sign back in and accept the UAC prompt. Save your work before you start.

Full details — every setting it changes, how to undo them, and troubleshooting: windows-dev-config/README.md.

🐧 WSL Comfort

Also known as Comfort Shell. An interactive setup for a polished Windows + WSL shell environment.

WSL Comfort stands apart. It supports both interactive and non-interactive modes, and lets you pick and choose individual components. The Windows side handles WSL, the distro, the Cascadia Code Nerd Font, and a themed Windows Terminal profile. The Linux side runs inside the distro and configures the shell itself.

.\wsl-comfort\install.ps1

Interactive by default. Use -NonInteractive for unattended runs; the bootstrap also takes --minimal for a smaller setup. The Linux half is standalone, so you can copy comfort-shell-bootstrap.sh onto any Ubuntu host and run it directly.

Full details: wsl-comfort/readme.md.

🧪 Single-language workloads

Just want one toolchain? Pick a row. Each workload ships a configuration.winget file plus a matching install.ps1 shim that applies it and refreshes PATH in the current session.

Most of the single-language workloads use winget configure. If you've never used it before, enable it once:

winget configure --enable

[!IMPORTANT] If winget is being invoked from a non-elevated environment, the Microsoft Visual C++ Redistributable (aka.ms/vcredist) must also be installed — without it winget configure fails with an internal error. Install it once with the command for your machine's architecture:

# x64:
winget install Microsoft.VCRedist.2015+.x64

# ARM64:
winget install Microsoft.VCRedist.2015+.arm64

If that fails or winget configure is still not recognized, see Troubleshooting. Windows Dev Config doesn't use winget configure and needs none of this.

Want the PATH refresh in your current shell? Use the matching shim instead of calling winget configure directly:

.\Workloads\python\install.ps1

Heads up: WinForms and WinUI 3 pull down several gigabytes of Visual Studio components. Fine on a real workstation, painful on a small VM.

🩺 Troubleshooting

# x64:
winget install Microsoft.VCRedist.2015+.x64

# ARM64:
winget install Microsoft.VCRedist.2015+.arm64

🐛 Reporting issues

Hit a bug, a stale doc, or a setup that fails on your machine? Open an issue at github.com/microsoft/WindowsDeveloperConfig/issues. Include your Windows build (winver), the exact command you ran, and the failing output. This helps us triage faster.

❤️ Contributing

Contributions of all kinds are welcome: bug reports, doc fixes, new workloads, voice-and-tone tweaks. Start with CONTRIBUTING.md, then read src/docs/development.md for the CI matrix, the "how to add a language" walkthrough, and how the sign pipeline works.

Note on the repo layout: the src/ tree is the source of truth. The top-level windows-dev-config/, Workloads/, and wsl-comfort/ folders are Authenticode-signed release copies regenerated by the sign pipeline, so please don't edit them directly. Full details in src/docs/development.md.

The single source of truth for every flow (paths, build/run commands, ids, language metadata) is src/manifest.yml. The Command Palette extension, the CI harness, and the per-flow shims all read from it, so keep it in sync when you add or rename a flow.