WinGet unter Windows: Programme per Kommandozeile installieren und verwalten

Wer einen Windows-Rechner neu einrichtet, installiert oft dieselben Programme: Browser, Editor, Git, Archivprogramm. Mit WinGet lässt sich das über die Kommandozeile erledigen. Der Paketmanager kann Anwendungen suchen, installieren, aktualisieren und deinstallieren. Er kann außerdem eine Paketliste für einen anderen Rechner exportieren oder eine Umgebung anhand einer Konfigurationsdatei einrichten.

Entscheidend ist, Pakete eindeutig auszuwählen. Ein Suchbegriff wie „Chrome“ kann mehrere Treffer liefern. Für wiederholbare Befehle verwende ich deshalb in den Beispielen die Paket-ID zusammen mit --exact und einer angegebenen Quelle.

Ist WinGet bereits installiert?

WinGet gehört zum App Installer. Es ist für Windows 11 und unterstützte Windows-10-Versionen verfügbar; Microsoft nennt Windows 10 ab Version 1809 als technische Untergrenze. Auch Windows Server 2025 wird unterstützt. Auf älteren Serverversionen solltest du nicht davon ausgehen, dass winget vorhanden ist.

Öffne PowerShell oder die Windows-Eingabeaufforderung und prüfe zuerst die Version:

winget --version

Wird der Befehl nicht gefunden, aktualisiere beziehungsweise installiere den App Installer über Microsoft. Nach der ersten Anmeldung eines neuen Benutzers kann es außerdem einen Moment dauern, bis der Befehl registriert ist. Die Microsoft-Dokumentation zur Einrichtung von WinGet beschreibt die unterstützten Wege.

Pakete suchen und eindeutig auswählen

Mit search findest du ein Paket. Für eine Installation solltest du anschließend die angezeigte ID und die Quelle prüfen:

winget search "Visual Studio Code"
winget show --id Microsoft.VisualStudioCode --exact --source winget

Die ID Microsoft.VisualStudioCode bezeichnet hier das Paket, winget die Quelle. --exact verhindert, dass WinGet die ID nur als Teil eines anderen Suchergebnisses interpretiert. Gerade in Skripten sind diese Angaben zuverlässiger als ein frei formulierter Programmname.

Installieren, auflisten, aktualisieren und deinstallieren

Visual Studio Code installierst du beispielsweise so:

winget install --id Microsoft.VisualStudioCode --exact --source winget

Einzelne Installationsprogramme können trotzdem eine Benutzerbestätigung oder erhöhte Rechte benötigen. --silent fordert eine unbeaufsichtigte Installation an, garantiert sie aber nicht für jedes Paket und jeden Installer.

winget install --id Git.Git --exact --source winget --silent

Installierte Anwendungen und verfügbare Aktualisierungen siehst du mit diesen Befehlen:

winget list
winget upgrade

Ein bestimmtes Paket aktualisierst du über seine ID:

winget upgrade --id Git.Git --exact --source winget

winget upgrade --all aktualisiert die von WinGet erkannten Pakete, für die ein passendes Update verfügbar ist. Das bedeutet nicht, dass damit ausnahmslos jedes Programm auf dem Rechner aktualisiert wird: Nicht eindeutig zugeordnete Anwendungen und angeheftete Pakete können außen vor bleiben. Prüfe die Liste mit winget upgrade, bevor du einen umfangreichen Update-Lauf startest.

Zum Deinstallieren:

winget uninstall --id Git.Git --exact

Eine Deinstallation entfernt nicht zwangsläufig Benutzerprofile, Einstellungen oder andere zurückgelassene Anwendungsdaten. Das Verhalten hängt vom jeweiligen Deinstallationsprogramm ab.

Mit export und import eine Paketliste übertragen

export schreibt die erkannten Anwendungen in eine JSON-Datei. Das ist praktisch, wenn du auf einem neuen Rechner viele derselben Programme installieren möchtest:

winget export --output .\pakete.json

Öffne die Datei nach dem Export und entferne Einträge, die du nicht übernehmen möchtest. WinGet meldet beim Export Anwendungen, die keiner verfügbaren Paketquelle zugeordnet werden konnten. Diese Programme fehlen möglicherweise in der Datei.

Auf dem Zielrechner importierst du die Liste mit:

winget import --import-file .\pakete.json

Ohne Versionsangaben verwendet der Import grundsätzlich die aktuell verfügbaren Paketversionen. Wenn du die installierten Versionen in die Datei schreiben möchtest, ergänze beim Export --include-versions. Eine bestimmte ältere Version lässt sich beim späteren Import allerdings nur installieren, wenn sie in der verwendeten Quelle noch verfügbar ist. Mit --ignore-versions ignoriert der Import gespeicherte Versionsangaben.

Export und Import sichern keine persönlichen Dateien, Lizenzschlüssel oder Programmeinstellungen. Die JSON-Datei ist eine Paketliste, kein vollständiges System-Backup. Weitere Optionen erläutern die Microsoft-Seiten zu export und import.

Updates mit Pinning steuern

Manchmal soll ein Paket nicht beim nächsten allgemeinen Update wechseln, etwa weil eine neue Version erst mit einer Fachanwendung getestet werden muss. Dafür gibt es winget pin.

winget pin add --id Microsoft.PowerToys --exact
winget pin list

Ein normaler Pin nimmt das Paket aus winget upgrade --all heraus. Ein gezieltes Upgrade bleibt möglich. Soll WinGet auch das gezielte Upgrade blockieren, verwende --blocking:

winget pin add --id Microsoft.PowerToys --exact --blocking

Für eine zulässige Versionsreihe gibt es einen sogenannten Gating Pin. Die folgende Versionsnummer dient nur als Beispiel; prüfe vor der Verwendung, welche Versionen für dein Paket tatsächlich angeboten werden:

winget pin add --id Microsoft.PowerToys --exact --version 0.70.*

Einen Pin entfernst du wieder mit:

winget pin remove --id Microsoft.PowerToys --exact

Ein Pin steuert Updates durch WinGet. Ein Programm mit eigener Update-Funktion oder eine Aktualisierung außerhalb von WinGet kann sich trotzdem ändern. Deshalb ersetzt Pinning keine zentrale Update-Richtlinie. Die Unterschiede zwischen normalem Pin, Blockierung und Versionsbereich sind in der Pinning-Dokumentation beschrieben.

WinGet-Konfiguration: mehr als eine Paketliste

Wenn du nur Anwendungen auf einen anderen Rechner übertragen willst, reichen export und import. Eine WinGet Configuration beschreibt dagegen einen gewünschten Zustand: Sie kann Pakete und weitere Systemeinstellungen festlegen und anschließend prüfen, ob der Rechner diesem Zustand entspricht.

Ein kleines Beispiel für eine Konfigurationsdatei namens configuration.winget:

$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor:
      identifier: dscv3
resources:
  - type: Microsoft.WinGet/Package
    name: VSCode
    properties:
      id: Microsoft.VisualStudioCode
      source: winget
      useLatest: true
  - type: Microsoft.WinGet/Package
    name: Git
    properties:
      id: Git.Git
      source: winget
      useLatest: true

Dieses Beispiel verwendet das aktuelle v3-Schema. Dafür sind WinGet 1.11 oder neuer und der zugehörige DSC-v3-Prozessor erforderlich. Prüfe die Voraussetzungen mit winget --version. Die Datei lässt sich anschließend validieren, anzeigen, testen und anwenden:

winget configure validate -f .\configuration.winget
winget configure show -f .\configuration.winget
winget configure test -f .\configuration.winget
winget configure -f .\configuration.winget

Lies eine Konfigurationsdatei vor dem Anwenden vollständig durch. Konfigurationsressourcen können Programme ausführen oder Systemeinstellungen ändern; Dateien aus fremden Quellen sollten deshalb nicht ungeprüft gestartet werden. Details zum Format stehen in der Microsoft-Referenz für v3-Konfigurationen.

Daneben gibt es winget settings. Dieser Befehl öffnet die Einstellungen des WinGet-Clients, etwa für Ausgabe oder Installationspräferenzen. Das ist etwas anderes als winget configure, das den Zustand eines Rechners anhand einer Konfigurationsdatei verwaltet.

WinGet in PowerShell automatisieren

Für wenige, festgelegte Programme ist ein PowerShell-Skript oft einfacher als eine Konfigurationsdatei. Dieses Beispiel installiert drei Pakete nacheinander. Es verwendet exakte IDs, legt die Quelle fest und bricht ab, wenn ein WinGet-Aufruf fehlschlägt:

# setup.ps1
$ErrorActionPreference = 'Stop'

Get-Command winget -ErrorAction Stop | Out-Null

$pakete = @(
    'Microsoft.VisualStudioCode'
    'Git.Git'
    '7zip.7zip'
)

foreach ($id in $pakete) {
    Write-Host "Installiere $id"

    & winget install `
        --id $id `
        --exact `
        --source winget `
        --silent `
        --accept-package-agreements `
        --accept-source-agreements `
        --disable-interactivity

    $exitCode = $LASTEXITCODE
    if ($exitCode -ne 0) {
        throw "Installation von $id fehlgeschlagen (Exitcode $exitCode)."
    }
}

Write-Host 'Alle WinGet-Aufrufe waren erfolgreich.'

Die Optionen für Paket- und Quellenvereinbarungen solltest du nur verwenden, wenn ihre automatische Annahme für deinen Einsatzzweck vorgesehen ist. --disable-interactivity verhindert Rückfragen durch WinGet; wenn ein Installer dennoch Eingaben oder Administratorrechte benötigt, kann der unbeaufsichtigte Lauf scheitern. Teste das Skript daher zuerst auf einem geeigneten Testrechner.

Für geplante Aufgaben und größere Rollouts ist außerdem wichtig, in welchem Benutzerkontext das Skript läuft. Verfügbarkeit von WinGet, Paketquellen, Benutzerinstallationen und erhöhte Rechte können sich zwischen einer interaktiven Sitzung und einem Dienstkonto unterscheiden. Ein erfolgreicher Test in deiner PowerShell ist deshalb noch kein Nachweis für denselben Ablauf in einer automatisierten Aufgabe.

Paketquellen bewusst verwenden

Die konfigurierten Quellen zeigt WinGet mit:

winget source list

Viele Befehle durchsuchen mehrere Quellen. --source winget macht im Installationsbefehl eindeutig, woher der Paketeintrag kommen soll. Prüfe vor der Installation dennoch Paket-ID, Herausgeber und gegebenenfalls die Details mit winget show. Zusätzliche Quellen solltest du nur einrichten, wenn du ihrem Betreiber und den bereitgestellten Paketen vertraust.

Fazit

Für einzelne Installationen genügen wenige Befehle: Paket suchen, ID prüfen und mit --id, --exact und --source installieren. export und import helfen beim Übertragen einer Programmauswahl. Pinning steuert WinGet-Updates für bestimmte Pakete. Wenn ein Rechner wiederholt nach denselben Vorgaben eingerichtet werden soll, bietet eine WinGet-Konfiguration mehr Möglichkeiten als eine reine Paketliste; für kleine Abläufe kann ein PowerShell-Skript die einfachere Lösung sein.