Install Your First Developer Tools with WinGet

Search, inspect, install, list, and verify one approved Windows developer tool by exact WinGet package ID.

By Ian Fang Beginner 25 minutes

Time-sensitive details checked:

A student-centered editorial illustration representing Install Your First Developer Tools with WinGet.

Use WinGet as an inspectable installer, not a shortcut around course or device policy. Search for a tool, inspect the exact package ID, publisher, source, and version, install one approved package, then verify both WinGet’s record and the tool itself.

Check availability and constraints

In a standard PowerShell session:

winget --version
winget --help

WinGet availability depends on Windows, App Installer, organization policy, and device management. A school may block sources, installations, Store access, or administrator elevation. Do not bypass those controls. Ask institutional IT or the instructor when a required tool is unavailable.

Search, then identify

For an instructor-approved tool:

winget search --name "Tool Name"

Search can return several packages with similar names. Record the exact Id, source, and candidate version. Inspect:

winget show --id Vendor.Package --exact

Review publisher, installer information, license links, source, and version. Package metadata is evidence, not a guarantee that the package fits your course or that every external link is safe.

Microsoft’s WinGet search documentation and show documentation describe current command options.

Install one exact package

Close unrelated work and create a checkpoint in the working log. Then:

winget install --id Vendor.Package --exact

Read prompts and agreements. Do not add flags that silently accept agreements until you have reviewed them and the workflow explicitly requires noninteractive installation.

Some installers request elevation. Verify the package identity before approving an administrator prompt. Stop if the publisher, package, requested permissions, or destination differs from what you inspected.

Verify two ways

First inspect WinGet’s installed record:

winget list --id Vendor.Package --exact

Microsoft notes in its current winget list documentation that the list can include applications installed by WinGet and by other means.

Then verify the tool itself with its documented version command or application information page. Open a new terminal if the installer changed PATH. Run one harmless course-relevant operation.

Do not report success only because the installer exited. Record observed version and behavior.

Keep identity for reproduction

Record:

Package ID:
Source:
Requested version:
Installed version:
Install date:
Elevation requested:
Verification command:
Observed result:

Do not store account tokens, license keys, or private source credentials.

Common mistakes

  • Installing the first search match.
  • Using a display name when an exact ID is available.
  • Running the entire terminal as administrator.
  • Accepting agreements without reading them.
  • Assuming WinGet installation proves PATH is updated.
  • Installing tools not required by the course.

Do this now

Use an authorized practice machine or obtain approval. Search and show one package. If installation is allowed, install by exact ID, list it, verify its version, and run one harmless check. Otherwise, stop after inspection and record the policy constraint.

Log what you learned

Record only:

  • Result: What did the action produce?
  • Evidence: What observation, test, or source supports that result?
  • Next action or unresolved question: What should happen next?

Next, upgrade software intentionally rather than updating everything at once.