Rebuild a Windows Dev PC with WinGet Configuration Files in Windows 10/11

WinGet Configuration can rebuild a development PC by applying one reviewed YAML file that installs required tools and, when specified, configures Windows settings. Microsoft supports winget configure on Windows 10 version 1809 (build 17763) or later and Windows 11, provided WinGet 1.6.2631 or later is installed. The procedure below creates and applies a reusable configuration for Git, Visual Studio Code, PowerShell, and Node.js LTS.

Prerequisites and compatibility​

You need:

• An internet connection.
• A local administrator account or administrator credentials for the UAC prompt.
• Windows 10 version 1809 or later, or Windows 11.
• WinGet version 1.6.2631 or later.
• Enough free storage for the selected development tools.
• A trusted configuration file stored locally or in a repository you control.

WinGet Configuration files are declarative: they describe the desired result rather than a strict script sequence. Independent resources may run in parallel, and a failed resource does not necessarily stop unrelated resources.

Warning: A WinGet Configuration file can install software, download PowerShell DSC modules, run resources with administrator privileges, and change system settings. Never run a configuration merely because it came from a familiar repository. Read every resource, package identifier, module name, setting, and referenced file first.

1. Confirm the Windows version​

Press Windows key + R, enter:
winver
Select OK.
On Windows 10, confirm that the version is 1809 or later and the OS build is at least 17763. Any Windows 11 release meets the operating-system minimum for WinGet, although individual developer tools may require a newer build.
Install pending Windows updates before rebuilding the development environment:

Windows 11​

1. Open Settings.
2. Select Windows Update.
3. Select Check for updates.
4. Install available updates.
5. Select Restart now if Windows requests a restart.

Windows 10​

1. Open Settings.
2. Select Update & Security.
3. Select Windows Update.
4. Select Check for updates.
5. Install available updates.
6. Select Restart now if requested.

Do not proceed while Windows Update is waiting for a restart. A pending restart can interfere with installers and optional Windows components.

2. Verify WinGet and App Installer​

Open a normal, non-administrator PowerShell window:

1. Open Start.
2. Search for PowerShell.
3. Select Windows PowerShell or PowerShell. Do not select Run as administrator yet.

Run:
winget --version
The result must be version 1.6.2631 or later. A newer stable version is preferred.
Also check that the configuration command is available:
winget configure --help
Expected result: WinGet displays help for the configure command and its subcommands, including show, list, test, validate, and export.
If WinGet is installed but outdated, open Microsoft Store, search for App Installer, open its product page, and select Update if that button appears. App Installer contains the WinGet client. After updating, close every open terminal window, open a new PowerShell window, and repeat the version check.
If WinGet itself works, App Installer can also be updated with:
winget upgrade Microsoft.AppInstaller
Close and reopen PowerShell after the update.

3. Create a local configuration folder​

Create a dedicated folder rather than running the file from Downloads:
New-Item -ItemType Directory -Path C:\DevSetup -Force
Expected result: PowerShell displays the C:\DevSetup directory or returns without an error if it already exists.
Create the configuration file:
notepad C:\DevSetup\configuration.winget
If Notepad reports that the file does not exist, select Yes to create it.
Paste the following configuration:

properties:
  assertions: []
  resources:
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: git
      directives:
        description: Install Git for Windows
        securityContext: elevated
      settings:
        id: Git.Git
        source: winget

    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: vscode
      directives:
        description: Install Visual Studio Code
        securityContext: elevated
      settings:
        id: Microsoft.VisualStudioCode
        source: winget

    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: powershell
      directives:
        description: Install current stable PowerShell
        securityContext: elevated
      settings:
        id: Microsoft.PowerShell
        source: winget

    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: nodejs
      directives:
        description: Install the Node.js long-term support release
        securityContext: elevated
      settings:
        id: OpenJS.NodeJS.LTS
        source: winget

  configurationVersion: 0.2.0

In Notepad:

1. Select File > Save As.
2. Confirm the location is C:\DevSetup.
3. Set File name to configuration.winget.
4. Set Save as type to All files.
5. Set encoding to UTF-8.
6. Select Save.

Confirm that Notepad did not create configuration.winget.txt:
Get-ChildItem C:\DevSetup
Expected result: the listing includes configuration.winget.
This example installs packages only. It does not enable Developer Mode, edit the registry, change networking, modify boot configuration, repartition storage, or create accounts.

4. Review the configuration before applying it​

Display the exact file that WinGet will process:
Get-Content C:\DevSetup\configuration.winget
Check that:

• Every resource is expected.
• Package IDs match the intended applications.
• The source is winget.
• There are no script resources, registry changes, network settings, or unknown modules.
• No passwords, tokens, private keys, or other secrets are stored in the YAML.

Check the configured PowerShell repositories:
Get-PSRepository
WinGet Configuration may retrieve DSC resources through PowerShell repositories. Do not continue if an unexpected or untrusted repository has replaced the repository you normally use.
Because each package resource specifies securityContext: elevated, WinGet can request elevation for the configuration. Running from a normal terminal keeps the UAC transition visible instead of silently starting the whole process in an already elevated shell.

5. Validate and inspect the file​

Validate the YAML structure before installing anything:
winget configure validate -f "C:\DevSetup\configuration.winget"
Expected result: validation completes without reporting a syntax or schema error.
Next, ask WinGet to display the configuration details:
winget configure show -f "C:\DevSetup\configuration.winget"
Confirm that the displayed resources correspond to Git, Visual Studio Code, PowerShell, and Node.js LTS.
If either command reports an error, do not run the configuration. Correct the file and repeat both checks.

6. Apply the configuration​

Warning: The next command installs applications with elevated privileges. Close development tools and save open work. Although the listed packages normally do not require an immediate reboot, an installer can report that a restart is needed. Do not interrupt WinGet or power off the PC during installation.

From the normal PowerShell window, run:
winget configure -f "C:\DevSetup\configuration.winget"
WinGet displays the configuration and asks you to acknowledge the configuration warning. Read the prompt and accept only after confirming that the displayed file and resources are correct.
Approve the User Account Control prompt when it identifies a trusted Windows or App Installer process. Because the configuration contains elevated resources, one UAC approval may cover the elevated portion of the configuration.
During processing, WinGet will:

1. Parse the YAML file.
2. Obtain the required DSC resource module.
3. Test whether each package is already in the desired state.
4. Install missing packages.
5. Leave packages that already satisfy the requested state in place.
6. Display the result for each resource.

Do not assume that the entire configuration failed merely because one package failed. WinGet may continue applying independent resources. Review every result at the end.
If the output requests a restart, use Start > Power > Restart after WinGet finishes. Otherwise, close all terminal windows and open a new PowerShell window so newly added PATH entries are loaded.

Verification of success​

Test the machine against the configuration:
winget configure test -f "C:\DevSetup\configuration.winget"
The resources should report that the system is in the desired state. Any resource reported as not in the desired state needs further attention.
Confirm that WinGet recognizes each package:

winget list --id Git.Git
winget list --id Microsoft.VisualStudioCode
winget list --id Microsoft.PowerShell
winget list --id OpenJS.NodeJS.LTS

Then verify the command-line tools from a newly opened terminal:

git --version
code --version
pwsh --version
node --version
npm --version

Each command should return a version rather than a “not recognized” error. Visual Studio Code should also open from Start > All apps > Visual Studio Code.
You can safely rerun the same configuration later. WinGet tests the current state and should avoid reinstalling resources that already satisfy the file.

Alternate method: Export a configuration from the old PC​

If the original development PC is still available, WinGet can generate a configuration from its installed packages.
On the old PC, open PowerShell and run:
winget configure export --all -o "$env:USERPROFILE\Desktop\dev-pc.winget"
Use a new output filename. If the output file already exists, configuration export can append resources to it instead of replacing it.
Open the exported file and remove:

• Games, launchers, and unrelated personal applications.
• Hardware-specific utilities.
• VPN, security, or corporate management software that IT must deploy.
• Packages that were installed only for testing.
• Packages that contain machine-specific assumptions.

Copy the reviewed file to the rebuilt PC, save it in C:\DevSetup, and run the validation, inspection, application, and verification steps above.
An export is not a complete system backup. It does not preserve source code, Git credentials, SSH private keys, browser data, databases, WSL distributions, container images, application preferences, or files that are not represented by configuration resources.

Troubleshooting​

winget is not recognized​

WinGet may not be registered immediately after the first sign-in on a newly installed PC. Open PowerShell and run:
Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
Close PowerShell, open a new window, and run:
winget --version
If it remains unavailable, open Microsoft Store, search for App Installer, and select Get, Install, or Update, whichever is shown.

winget configure is not recognized​

The installed WinGet version is too old or App Installer has not finished updating. Confirm:
winget --version
Update App Installer and reopen the terminal. The minimum version for winget configure is 1.6.2631.
If WinGet reports that configuration components are disabled, run:
winget configure --enable
This operation requires Microsoft Store access. On a managed PC, organizational policy may disable WinGet Configuration; contact the administrator rather than attempting to bypass policy.

Validation reports a YAML error​

YAML uses spaces for indentation. Do not use tabs. Confirm that:

• properties: begins at the first column.
• Child entries use consistent two-space indentation.
• List entries begin with -.
• Package identifiers and descriptions have not been split across lines.
• The file is named configuration.winget, not configuration.winget.txt.

Restore the sample exactly, save it as UTF-8, and rerun:
winget configure validate -f "C:\DevSetup\configuration.winget"

A DSC resource requires administrator access​

Run the configuration from a normal terminal and approve the UAC prompt. Do not remove securityContext: elevated merely to suppress an elevation failure. If the account is not allowed to elevate, an administrator must run or approve the configuration.

A package or module cannot be downloaded​

First refresh the WinGet sources:
winget source update
Then retry with verbose logging:
winget configure -f "C:\DevSetup\configuration.winget" --verbose-logs
On a corporate network, the WinGet source, Microsoft Store services, PowerShell repository, or package publisher may be blocked by a proxy or firewall. If an approved proxy is required, use the --proxy option with the proxy address supplied by the network administrator.

Warning: Resetting WinGet sources removes source customizations and can disrupt private repositories. Record every custom source before using the following recovery command.

Only when the default sources are damaged and source update does not work, run:

winget source reset --force
winget source update

After recovery, re-add any approved private sources using the information recorded beforehand.

One resource fails but other packages install​

This is normal declarative behavior. WinGet attempts to bring as much of the machine as possible into the desired state. Run:
winget configure test -f "C:\DevSetup\configuration.winget"
Identify the resource that is not in the desired state, correct its package ID, connectivity, permissions, or installer problem, and rerun the configuration.

Packages appear installed but commands are not found​

Close all Command Prompt, PowerShell, and Windows Terminal windows, then open a new terminal. If commands are still missing, restart Windows and verify the package records with winget list.
For Visual Studio Code, also confirm that Code.exe can be opened from the Start menu. PATH registration can vary if a previous user-scope installation conflicts with a machine-scope installation.

Rollback and escalation​

WinGet Configuration does not provide a universal undo operation. To remove the packages installed by this example, run:

winget uninstall --id Git.Git
winget uninstall --id Microsoft.VisualStudioCode
winget uninstall --id Microsoft.PowerShell
winget uninstall --id OpenJS.NodeJS.LTS

Review each uninstall prompt. Back up repositories, unsaved editor data, Node.js global-package information, and application settings before removal.
The sample configuration does not change Windows settings, so no registry, networking, boot, storage, security, or account rollback is required. For a customized configuration that changes system state, document and test the reverse operation for every setting before applying it to a production PC.
If the failure remains unresolved, collect:

winget --info
winget --version
winget configure validate -f "C:\DevSetup\configuration.winget"
winget configure test -f "C:\DevSetup\configuration.winget"
winget --open-logs

Preserve the configuration file, the failed resource name, its error code, the WinGet information output, and the corresponding diagnostic log. Remove usernames, access tokens, private repository credentials, proxy credentials, and other secrets before providing the files to an administrator or filing a WinGet CLI issue.