{"id":20862,"date":"2026-02-04T10:00:13","date_gmt":"2026-02-04T18:00:13","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/?p=20862"},"modified":"2026-02-03T11:47:14","modified_gmt":"2026-02-03T19:47:14","slug":"winget-configuration-set-up-your-dev-machine-in-one-command","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/blog\/winget-configuration-set-up-your-dev-machine-in-one-command","title":{"rendered":"WinGet Configuration: Set up your dev machine in one command"},"content":{"rendered":"

I’ve set up a lot<\/em> of dev machines in my life. Traditionally, this takes a lot of time to get everything just right, but now there’s a faster way with WinGet Configuration<\/a> files. Let me show you how to go from a fresh Windows install to a fully configured dev environment with a single command and how GitHub Copilot CLI<\/a> can help you build these configs.<\/p>\n

\"winget<\/a><\/p>\n

What is WinGet Configuration?<\/h2>\n

WinGet Configuration lets you describe your ideal dev environment in a YAML file, then apply it with one command. Instead of running a bunch of winget install<\/code> commands manually, you declare what you want and let WinGet do the rest.<\/p>\n

Getting started<\/h2>\n

Before you can use winget configure<\/code>, you’ll need to install the WinGet DSC module. Open PowerShell as admin and run:<\/p>\n

Install-Module Microsoft.WinGet.DSC -Force<\/code><\/pre>\n
Once that’s installed, you can run configuration files with:<\/p>\n
winget configure -f configuration.winget<\/code><\/pre>\n
WinGet reads your file, installs all your tools, configures your settings, and gets you ready to code.<\/p>\n
The best part is that these configs are idempotent<\/strong>, which means you can run them multiple times and they’ll only change what needs changing. For example if you already have VS Code installed, it skips it and moves on.<\/p>\n
<\/div>\n
<\/i>Tip:<\/strong><\/p>Add --accept-configuration-agreements<\/code> to skip the confirmation prompts for automated scenarios.<\/div><\/div>\n
How is this different from WinGet import\/export?<\/h2>\n
If you’ve used WinGet before, you might be thinking “wait, can’t I already do this with winget export<\/code> and winget import<\/code>?” This is a great question and they’re designed to solve different problems.<\/p>\n
winget import\/export<\/code> creates a simple JSON list of installed packages:<\/p>\n
\n
# Export your installed packages\r\nwinget export -o packages.json\r\n# Import on another machine\r\nwinget import -i packages.json<\/code><\/pre>\n<\/div>\n
This works, but it only<\/em> handles package installation. It’s basically a batch install script.<\/p>\n
winget configure<\/code> is much more powerful:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Feature<\/strong><\/td>\nimport\/export<\/strong><\/td>\nconfigure<\/strong><\/td>\n<\/tr>\n
Install packages<\/td>\n\u2705<\/td>\n\u2705<\/td>\n<\/tr>\n
Configure Windows settings<\/td>\n\u274c<\/td>\n\u2705<\/td>\n<\/tr>\n
Enable Developer Mode<\/td>\n\u274c<\/td>\n\u2705<\/td>\n<\/tr>\n
Install VS workloads<\/td>\n\u274c<\/td>\n\u2705<\/td>\n<\/tr>\n
Set environment variables<\/td>\n\u274c<\/td>\n\u2705<\/td>\n<\/tr>\n
Define dependencies<\/td>\n\u274c<\/td>\n\u2705<\/td>\n<\/tr>\n
Check OS requirements<\/td>\n\u274c<\/td>\n\u2705<\/td>\n<\/tr>\n
Run PowerShell DSC resources<\/td>\n\u274c<\/td>\n\u2705<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Think of import\/export<\/code> as a grocery list and configure<\/code> as a complete recipe. The grocery list tells you what to buy, but the recipe tells you what to buy and<\/em> how to put it all together.<\/p>\n
For simple app installation scenarios, winget import<\/code> is great. But if you want a fully configured dev environment with Developer Mode enabled, VS workloads installed, and settings configured, use winget configure<\/code>.<\/p>\n
Your first configuration file<\/h2>\n
Let’s start simple. Create a file called dev-setup.winget<\/code>:<\/p>\n
# yaml-language-server: $schema=https:\/\/aka.ms\/configuration-dsc-schema\/0.2\r\nproperties:\r\n  configurationVersion: 0.2.0\r\n  resources:\r\n    - resource: Microsoft.WinGet.DSC\/WinGetPackage\r\n      directives:\r\n        description: Install Visual Studio Code Insiders\r\n        securityContext: elevated\r\n      settings:\r\n        id: Microsoft.VisualStudioCode.Insiders\r\n        source: winget\r\n\r\n    - resource: Microsoft.WinGet.DSC\/WinGetPackage\r\n      directives:\r\n        description: Install Git\r\n        securityContext: elevated\r\n      settings:\r\n        id: Git.Git\r\n        source: winget\r\n\r\n    - resource: Microsoft.WinGet.DSC\/WinGetPackage\r\n      directives:\r\n        description: Install Node.js LTS\r\n        securityContext: elevated\r\n      settings:\r\n        id: OpenJS.NodeJS.LTS\r\n        source: winget\r\n\r\n    - resource: Microsoft.WinGet.DSC\/WinGetPackage\r\n      directives:\r\n        description: Install Windows Terminal Preview\r\n      settings:\r\n        id: Microsoft.WindowsTerminal.Preview\r\n        source: winget<\/code><\/pre>\n
Run it with:<\/p>\n
winget configure -f dev-setup.winget<\/code><\/pre>\n
WinGet prompts you for admin approval once, then handles all the installations. Go grab a coffee and come back to a configured machine. \u2615<\/p>\n
Adding Windows settings<\/h2>\n
You can do more than install packages, you can configure Windows itself. Here’s how to enable Developer Mode and dark mode automatically:<\/p>\n
- resource: Microsoft.Windows.Settings\/WindowsSettings\r\n  directives:\r\n    description: Enable Developer Mode\r\n    allowPrerelease: true\r\n    securityContext: elevated\r\n  settings:\r\n    DeveloperMode: true\r\n\r\n- resource: Microsoft.Windows.Developer\/EnableDarkMode\r\n  directives:\r\n    description: Enable dark mode\r\n    allowPrerelease: true\r\n  settings:\r\n    Ensure: Present\r\n    RestartExplorer: true<\/code><\/pre>\n
Using assertions for requirements<\/h2>\n
Assertions let you check system requirements before running your config. For example, you can verify the machine meets a minimum OS version:<\/p>\n
properties:\r\n  configurationVersion: 0.2.0\r\n  \r\n  assertions:\r\n    - resource: Microsoft.Windows.Developer\/OsVersion\r\n      directives:\r\n        description: Require Windows 11 22H2 or later\r\n        allowPrerelease: true\r\n      settings:\r\n        MinVersion: '10.0.22621'\r\n  \r\n  resources:\r\n    # Install your tools...<\/code><\/pre>\n
If the OS version check fails, the config stops early with a clear message instead of crashing halfway through. This is useful when your tools require specific Windows features only available in newer versions.<\/p>\n
Dependencies between resources<\/h2>\n
Sometimes you need things installed in a specific order. Use dependsOn<\/code> to chain resources:<\/p>\n
- resource: Microsoft.WinGet.DSC\/WinGetPackage\r\n  id: vsPackage\r\n  directives:\r\n    description: Install Visual Studio 2026 Community\r\n    securityContext: elevated\r\n  settings:\r\n    id: Microsoft.VisualStudio.Community\r\n    source: winget\r\n\r\n- resource: Microsoft.VisualStudio.DSC\/VSComponents\r\n  dependsOn:\r\n    - vsPackage\r\n  directives:\r\n    description: Install .NET workload\r\n    allowPrerelease: true\r\n    securityContext: elevated\r\n  settings:\r\n    productId: Microsoft.VisualStudio.Product.Community\r\n    channelId: VisualStudio.18.Release\r\n    components:\r\n      - Microsoft.VisualStudio.Workload.ManagedDesktop<\/code><\/pre>\n
The vsPackage<\/code> installs first, then the workload gets added.<\/p>\n
Using GitHub Copilot CLI to generate configs<\/h2>\n
Here’s where it gets fun. First, let’s make sure Copilot CLI is part of our setup! You can bootstrap it right in your configuration file:<\/p>\n
- resource: Microsoft.WinGet.DSC\/WinGetPackage\r\n  id: copilotCli\r\n  directives:\r\n    description: Install GitHub Copilot CLI\r\n  settings:\r\n    id: GitHub.Copilot\r\n    source: winget<\/code><\/pre>\n
Now when you run your config on a fresh machine, Copilot CLI gets installed automatically. Once it’s installed, you can use it to generate more<\/em> configs.<\/p>\n
Instead of writing YAML by hand, I ask Copilot CLI to generate configs for me:<\/p>\n
copilot<\/code><\/pre>\n
Then I prompt:<\/p>\n
\n
“Create a winget configuration file for a Python data science developer. Include Python 3.12, VS Code, Git, and Anaconda.”<\/div>\n<\/blockquote>\n
Copilot generates a complete config that I can tweak and save. This is so much faster than looking up package IDs manually.<\/p>\n
Finding package IDs<\/h3>\n
Not sure what the exact package ID is? Ask Copilot:<\/p>\n
\n
“What’s the winget package ID for the latest Python?”<\/div>\n<\/blockquote>\n
It’ll tell you Python.Python.3.12<\/code> (or whichever version is current).<\/p>\n
Converting existing scripts<\/h3>\n
Have an old PowerShell script that installs your tools? Copilot can convert it:<\/p>\n
\n
“Convert this script to a winget configuration file:<\/div>\n
winget install Microsoft.VisualStudioCode<\/div>\n
winget install Git.Git<\/div>\n
winget install OpenJS.NodeJS.22″<\/div>\n<\/blockquote>\n
It creates the proper YAML structure with descriptions and everything.<\/p>\n
Explaining configs<\/h3>\n
Found a config file in a repo and not sure what it does? Paste it and ask:<\/p>\n
\n
“Explain what this winget configuration does and what will be installed”<\/div>\n<\/blockquote>\n
This is super helpful when you’re onboarding to a new project.<\/p>\n
\"Terminal<\/a><\/p>\n
The export command: Reverse-engineer your setup<\/h2>\n
One of my favorite features is winget configure export<\/code>. It captures your current machine state so you can recreate it later:<\/p>\n
# Export your entire package configuration\r\nwinget configure export -o my-machine.winget --all\r\n# Export just one package's config\r\nwinget configure export -o vscode.winget --package-id Microsoft.VisualStudioCode<\/code><\/pre>\n
This is great for:<\/p>\n