Winget ist weit mehr als ein Werkzeug, mit dem sich vorhandene Anwendungen unter Windows installieren und aktualisieren lassen. Der Windows Package Manager bietet auch die Möglichkeit, eigene Softwarepakete zu definieren, zu testen und für andere Benutzer bereitzustellen. Damit können Entwickler ihre Programme über Winget verteilen, während Administratoren eigene Installationspakete für standardisierte Windows-Umgebungen vorbereiten können.
Die Grundlage bilden sogenannte Paketmanifeste. Diese beschreiben in maschinenlesbarer Form, welche Anwendung installiert werden soll, wo sich die Installationsdateien befinden, welche Version angeboten wird und welche Parameter für die Installation erforderlich sind.
In diesem dreizehnten Teil unserer Winget-Serie beschäftigen wir uns ausführlich mit der Erstellung eigener Pakete. Wir betrachten die Struktur der YAML-Dateien, unterschiedliche Installertypen, Versionsverwaltung, Lizenzinformationen, Icons sowie die Validierung und praktische Prüfung eines Pakets.
Was ist ein eigenes Winget-Paket?
Ein Winget-Paket ist im Wesentlichen eine Beschreibung einer Anwendung und ihrer Installationsmöglichkeiten. Anders als bei klassischen Paketformaten enthält das Manifest normalerweise nicht die eigentliche Software.
Stattdessen verweist es auf einen Installer, der beispielsweise vom Hersteller über HTTPS bereitgestellt wird.
Ein Paket besteht damit aus zwei wesentlichen Bestandteilen:
- Paketmanifest: Beschreibt Anwendung, Version, Installationsdateien, Eigenschaften und Metadaten.
- Installer: Enthält die eigentliche Software und wird beim Installationsvorgang heruntergeladen und ausgeführt.
Winget liest die Paketinformationen, wählt einen geeigneten Installer aus, überprüft dessen Integrität und startet anschließend die Installation.
Warum eigene Pakete erstellen?
Die Erstellung eigener Pakete ist in verschiedenen Situationen sinnvoll.
Für Softwareentwickler: Eine selbst entwickelte Anwendung kann über Winget angeboten werden. Benutzer müssen dann keine Installationsdatei mehr manuell herunterladen.
Für Administratoren: Eigene Softwareprodukte oder Anwendungen von Drittanbietern lassen sich standardisiert installieren und aktualisieren.
Für Unternehmen und Behörden: Wiederkehrende Installationsvorgänge können dokumentiert und automatisiert werden. Für ausschließlich intern verfügbare Software sind dabei geeignete private Paketquellen beziehungsweise ergänzende Bereitstellungsmechanismen erforderlich.
Für Open-Source-Projekte: Winget bietet einen zusätzlichen Verteilungsweg, über den sich Anwendungen leichter auffinden und installieren lassen.
Ein wichtiger Unterschied: Das Erstellen eines Manifests bedeutet noch nicht, dass das Paket automatisch im offiziellen Winget-Repository veröffentlicht ist. Dafür ist ein gesonderter Einreichungs- und Prüfprozess notwendig.
Die Architektur eines Winget-Pakets
Winget verwendet YAML-Dateien, um Pakete zu beschreiben. YAML steht für YAML Ain't Markup Language und ist ein gut lesbares Format zur Darstellung strukturierter Daten.
Für ein vollständiges Paket können mehrere Manifestdateien verwendet werden.
Die typische Struktur eines modernen mehrteiligen Manifests umfasst:
- Ein Versionsmanifest
- Ein Installermanifest
- Ein Standardmanifest mit beschreibenden Informationen
- Optional ein Manifest mit Lokalisierungsinformationen
Die Trennung sorgt dafür, dass technische Installationsparameter und allgemeine Paketinformationen unabhängig voneinander gepflegt werden können.
Beispiel einer Verzeichnisstruktur
Angenommen, wir möchten eine Anwendung mit dem Namen „BeispielEditor“ des fiktiven Herstellers „BeispielSoftware“ bereitstellen.
Eine mögliche Struktur sieht folgendermaßen aus:
manifests/
└── b/
└── BeispielSoftware/
└── BeispielEditor/
└── 1.0.0/
├── BeispielSoftware.BeispielEditor.yaml
├── BeispielSoftware.BeispielEditor.installer.yaml
└── BeispielSoftware.BeispielEditor.locale.de-DE.yaml
Die Verzeichnisse folgen dabei dem Paketbezeichner und der Versionsnummer.
Für die offizielle Community-Paketquelle gelten zusätzlich feste Vorgaben hinsichtlich Namensgebung, Verzeichnisstruktur und Manifestformat.
Paketkennungen und Versionsnummern
Jedes Winget-Paket besitzt einen eindeutigen Paketbezeichner, die sogenannte PackageIdentifier.
Typischerweise folgt dieser dem Muster:
Hersteller.Anwendung
Für unser Beispiel verwenden wir:
PackageIdentifier: BeispielSoftware.BeispielEditor PackageVersion: 1.0.0
Die Paketkennung sollte möglichst dauerhaft unverändert bleiben. Sie wird unter anderem verwendet, um Anwendungen eindeutig zu identifizieren und Aktualisierungen zuzuordnen.
Die Versionsnummer bezeichnet die jeweilige Veröffentlichung der Anwendung.
Häufig wird ein Schema wie Semantic Versioning verwendet:
1.0.0 1.1.0 1.1.1 2.0.0
Winget verlangt allerdings nicht grundsätzlich, dass jede Anwendung Semantic Versioning verwendet. Entscheidend ist, dass die Versionsangaben konsistent zur tatsächlichen Softwareversion sind und für Aktualisierungen zuverlässig zugeordnet werden können.
Das Versionsmanifest erstellen
Das Versionsmanifest verbindet die übrigen Manifestdateien einer Paketversion miteinander.
Eine mögliche Datei lautet:
BeispielSoftware.BeispielEditor.yaml
PackageIdentifier: BeispielSoftware.BeispielEditor PackageVersion: 1.0.0 DefaultLocale: de-DE ManifestType: version ManifestVersion: 1.10.0
Die wichtigsten Eigenschaften:
PackageIdentifier: Eindeutiger Bezeichner des Pakets.
PackageVersion: Version der angebotenen Anwendung.
DefaultLocale: Sprache, in der die grundlegenden Paketinformationen bereitgestellt werden.
ManifestType: Kennzeichnet die Datei als Versionsmanifest.
ManifestVersion: Beschreibt die verwendete Version des Winget-Manifestschemas und nicht die Softwareversion.
Die hier gezeigte Schemaversion ist ein Beispiel. Bei der tatsächlichen Erstellung sollte eine von der eingesetzten Winget-Version und dem Zielrepository unterstützte Schemaversion verwendet werden.
Das Installermanifest
Das Installermanifest gehört zu den wichtigsten Bestandteilen eines Winget-Pakets.
Hier wird festgelegt, welche Installationsdatei heruntergeladen werden soll und wie Winget diese verarbeitet.
Ein Beispiel:
BeispielSoftware.BeispielEditor.installer.yaml
PackageIdentifier: BeispielSoftware.BeispielEditor
PackageVersion: 1.0.0
InstallerType: exe
Scope: machine
Installers:
- Architecture: x64
InstallerUrl: https://downloads.example.com/BeispielEditor-1.0.0-x64.exe
InstallerSha256: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ManifestType: installer
ManifestVersion: 1.10.0
Die URL ist hier lediglich ein Platzhalter. Auch der dargestellte SHA-256-Wert ist ein fiktiver Beispielwert.
Für ein tatsächlich funktionsfähiges Paket müssen beide Werte durch die korrekten Angaben ersetzt werden.
Wichtige Felder
InstallerType: Beschreibt das verwendete Installationsformat.
Architecture: Gibt an, für welche Prozessorarchitektur die Installationsdatei vorgesehen ist.
InstallerUrl: Enthält die Downloadadresse der Installationsdatei.
InstallerSha256: Enthält den SHA-256-Prüfwert der herunterzuladenden Datei.
Scope: Gibt an, ob der Installer eine benutzerbezogene oder systemweite Installation unterstützt. Diese Angabe muss zum tatsächlichen Verhalten des Installers passen.
Unterschiedliche Architekturen
Ein Paket kann mehrere Installationsvarianten anbieten.
Beispielsweise:
Installers:
- Architecture: x64
InstallerType: exe
InstallerUrl: https://downloads.example.com/app-x64.exe
InstallerSha256: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
- Architecture: arm64
InstallerType: exe
InstallerUrl: https://downloads.example.com/app-arm64.exe
InstallerSha256: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
Winget kann anhand der Manifestinformationen und der Zielumgebung einen passenden Installer auswählen.
Das ist insbesondere für Software interessant, die sowohl auf klassischen x64-Systemen als auch auf Windows-on-ARM-Geräten eingesetzt werden soll.
Unterstützte Installertypen
Winget unterstützt unterschiedliche Installationsformate. Die Wahl des richtigen Typs ist wichtig, damit Installation, Deinstallation und Aktualisierung zuverlässig funktionieren.
EXE-Installer
Klassische ausführbare Installationsprogramme verwenden häufig die Dateiendung .exe.
InstallerType: exe
Bei EXE-Installern müssen gegebenenfalls zusätzliche Installationsparameter definiert werden.
Beispielsweise:
InstallerSwitches: Silent: /S SilentWithProgress: /S
Diese Parameter sind nicht universell gültig. Welche Schalter unterstützt werden, hängt vom jeweiligen Installationsprogramm ab.
MSI-Installer
Windows-Installer-Pakete verwenden die Dateiendung .msi.
InstallerType: msi
MSI bietet standardisierte Installationsmechanismen und eignet sich deshalb besonders für die automatisierte Softwareverteilung.
MSIX und APPX
Moderne Windows-Anwendungen können als MSIX- oder APPX-Pakete bereitgestellt werden.
InstallerType: msix
Diese Formate unterstützen unter anderem paketbasierte Installation, definierte Anwendungsidentitäten und geregelte Aktualisierungsmechanismen.
Weitere Installertypen
Winget kennt außerdem spezifische Installationssysteme und Paketvarianten, darunter Inno Setup, Nullsoft Scriptable Install System (NSIS), Burn und portable Anwendungen.
Beispiele:
InstallerType: inno
InstallerType: nullsoft
InstallerType: portable
Der passende Typ sollte immer anhand des tatsächlich eingesetzten Installationssystems gewählt werden.
Silent Installation und Installationsparameter
Für automatisierte Installationen ist es entscheidend, dass Programme ohne Benutzerinteraktion installiert werden können.
Winget unterstützt hierfür unterschiedliche Installationsschalter.
Ein Beispiel:
InstallerSwitches: Silent: /VERYSILENT SilentWithProgress: /SILENT
Diese Parameter sind beispielsweise aus bestimmten Inno-Setup-Konfigurationen bekannt.
Andere Installationssysteme verwenden andere Optionen.
Für MSI-Installationen werden häufig standardisierte Windows-Installer-Parameter verwendet.
Ein Administrator kann anschließend beispielsweise ausführen:
winget install --id BeispielSoftware.BeispielEditor --exact --silent
Damit fordert er eine unbeaufsichtigte Installation an.
Allerdings funktioniert dies nur zuverlässig, wenn der Installer die entsprechenden Parameter tatsächlich unterstützt.
Wichtig: Ein fehlerhaft konfigurierter Silent-Modus kann dazu führen, dass Installationen hängen bleiben oder unerwartet Benutzereingaben verlangen.
Deshalb sollten unbeaufsichtigte Installationen grundsätzlich vor einer produktiven Veröffentlichung getestet werden.
Paketinformationen und Lizenzangaben
Neben den technischen Installationsinformationen benötigt ein Paket beschreibende Metadaten.
Diese werden bei einem mehrteiligen Manifest in einer separaten Locale-Datei hinterlegt.
Für unser Beispiel erstellen wir:
BeispielSoftware.BeispielEditor.locale.de-DE.yaml
PackageIdentifier: BeispielSoftware.BeispielEditor PackageVersion: 1.0.0 PackageLocale: de-DE Publisher: BeispielSoftware PublisherUrl: https://example.com PackageName: BeispielEditor PackageUrl: https://example.com/editor License: MIT LicenseUrl: https://example.com/license ShortDescription: Ein einfacher Texteditor für Windows. Description: | BeispielEditor ist ein fiktiver Texteditor für Windows. Er unterstützt die Bearbeitung von Textdateien und bietet eine übersichtliche Benutzeroberfläche. Tags: - editor - texteditor - windows - produktivitaet ManifestType: defaultLocale ManifestVersion: 1.10.0
Auch diese URLs und die Lizenzangabe sind lediglich Beispiele und müssen bei einem realen Paket angepasst werden.
Welche Metadaten sind wichtig?
Publisher: Name des Softwareherstellers.
PublisherUrl: Offizielle Website des Herstellers.
PackageName: Anzeigename der Anwendung.
PackageUrl: Website mit Informationen zur Anwendung.
License: Lizenzbezeichnung, beispielsweise MIT, Apache-2.0 oder eine proprietäre Lizenz.
LicenseUrl: Adresse, unter der die Lizenzbedingungen eingesehen werden können.
ShortDescription: Kurze Beschreibung der Anwendung.
Description: Ausführlichere Beschreibung der Funktionen.
Tags: Suchbegriffe, die das Auffinden des Pakets erleichtern.
Eine möglichst vollständige Beschreibung verbessert die Auffindbarkeit und erleichtert die administrative Bewertung einer Anwendung. Microsoft empfiehlt ausdrücklich, aussagekräftige Metadaten bereitzustellen.
Mehrsprachige Paketbeschreibungen
Winget unterstützt unterschiedliche Sprachvarianten für Paketinformationen.
Das ist insbesondere für Anwendungen interessant, die international angeboten werden.
Zusätzlich zur deutschen Standardbeschreibung könnte eine englische Lokalisierung angelegt werden:
BeispielSoftware.BeispielEditor.locale.en-US.yaml
PackageIdentifier: BeispielSoftware.BeispielEditor PackageVersion: 1.0.0 PackageLocale: en-US Publisher: BeispielSoftware PackageName: BeispielEditor ShortDescription: A simple text editor for Windows. Description: | BeispielEditor is a lightweight text editor for Windows with an intuitive interface. ManifestType: locale ManifestVersion: 1.10.0
Die wichtigste Unterscheidung besteht zwischen defaultLocale und locale.
Das Standardmanifest enthält die grundlegenden Paketinformationen. Zusätzliche Sprachdateien können übersetzte Informationen bereitstellen.
Fehlen in einer zusätzlichen Sprachdatei bestimmte Angaben, kann Winget auf Informationen der Standardsprache zurückgreifen.
Icons und grafische Paketinformationen
Zu einer professionellen Softwareveröffentlichung gehört häufig ein wiedererkennbares Anwendungssymbol.
Allerdings unterscheidet sich Winget in diesem Bereich von klassischen App-Stores.
Ein Winget-Manifest ist keine vollständige grafische Produktseite. Das öffentliche Manifestformat besitzt kein allgemein verwendbares Standardfeld IconUrl, über das sich beliebige Icons direkt als Paketmetadatum hinterlegen lassen.
Die Darstellung von Anwendungssymbolen hängt deshalb unter anderem vom Installationsformat, den Metadaten des Installers und der verwendeten Benutzeroberfläche ab.
Icons bei MSIX-Anwendungen
MSIX-Pakete können grafische Ressourcen enthalten, die durch das Paket selbst bereitgestellt werden.
Hierzu gehören beispielsweise:
- Anwendungssymbole
- Kachelgrafiken
- Grafiken für verschiedene Skalierungsstufen
- Ressourcen für Windows-Oberflächen
Icons bei klassischen EXE- und MSI-Installern
Bei klassischen Installationsprogrammen werden Anwendungssymbole üblicherweise durch den Installer beziehungsweise die Anwendung eingerichtet.
Dazu gehören Verknüpfungen im Startmenü und gegebenenfalls auf dem Desktop.
Empfehlungen
Für eine konsistente Darstellung sollte das Anwendungssymbol bereits im eigentlichen Softwarepaket korrekt integriert sein.
Außerdem empfiehlt es sich, eine einheitliche Produktbezeichnung, eindeutige Herstellerinformationen und passende Versionsinformationen zu verwenden.
So kann die Anwendung unabhängig von Winget in Windows möglichst eindeutig erkannt werden.
SHA-256-Prüfsummen erstellen
Ein besonders wichtiger Bestandteil jedes Installermanifests ist der SHA-256-Prüfwert.
Dieser dient dazu, die Integrität der heruntergeladenen Installationsdatei zu überprüfen.
Wird eine Datei verändert, stimmt ihr berechneter Hashwert normalerweise nicht mehr mit dem im Manifest hinterlegten Wert überein.
Winget kann dadurch erkennen, wenn die heruntergeladene Datei nicht den erwarteten Bytes entspricht.
Prüfsumme mit PowerShell berechnen
Unter Windows lässt sich der Hashwert mit PowerShell berechnen:
Get-FileHash ` -Path "C:\Pakete\BeispielEditor-1.0.0-x64.exe" ` -Algorithm SHA256
Die Ausgabe enthält den berechneten SHA-256-Wert.
Alternativ bietet Winget einen eigenen Befehl:
winget hash "C:\Pakete\BeispielEditor-1.0.0-x64.exe"
Der ermittelte Wert wird anschließend in das Installermanifest übernommen:
InstallerSha256: <SHA256-DER-DATEI>
Der Platzhalter muss durch den tatsächlichen 64-stelligen Hexadezimalwert ersetzt werden.
Warum ist das wichtig?
Eine Integritätsprüfung schützt beispielsweise vor unbemerkten Veränderungen einer Installationsdatei.
Allerdings ersetzt ein SHA-256-Hash weder die Überprüfung der Herkunft noch eine vertrauenswürdige digitale Signatur.
Wird bereits die ursprüngliche Datei oder die Quelle kompromittiert, kann ein Hashwert allein keine Aussage über die Vertrauenswürdigkeit des Programms treffen.
Für sicherheitskritische Umgebungen sollten daher zusätzlich Hersteller, Downloadquelle und gegebenenfalls die Authenticode-Signatur überprüft werden.
Eigene Pakete mit WinGetCreate erstellen
Die manuelle Erstellung von YAML-Dateien ist hilfreich, um die Funktionsweise von Winget zu verstehen.
Für den praktischen Einsatz bietet Microsoft allerdings auch ein eigenes Werkzeug: den Windows Package Manager Manifest Creator, kurz WinGetCreate.
Dieses Kommandozeilenprogramm unterstützt Entwickler beim Erstellen und Aktualisieren von Paketmanifesten.
WinGetCreate installieren
winget install --id Microsoft.WingetCreate --exact
Anschließend kann die installierte Version überprüft werden:
wingetcreate --version
Neues Paket erstellen
wingetcreate new
Der Assistent führt interaktiv durch die erforderlichen Angaben.
Dazu gehören beispielsweise der Paketbezeichner, die Downloadadresse des Installers, die Version und weitere Metadaten.
Das Werkzeug kann außerdem Installerinformationen auswerten und bei der Erstellung der benötigten Manifestdateien helfen.
Die generierten Ergebnisse sollten dennoch manuell kontrolliert werden.
Insbesondere Installationsparameter, unterstützte Architekturen und Erkennungsinformationen müssen korrekt sein.
WinGetCreate kann auch bei der späteren Einreichung eines Pakets unterstützen.
Manifestdateien validieren
Bevor ein Paket veröffentlicht oder produktiv verwendet wird, sollte seine Struktur überprüft werden.
Winget bietet dafür den Befehl validate.
Einzelnes Manifest prüfen
winget validate --manifest "C:\Winget\MeinPaket.yaml"
Mehrteiliges Manifest prüfen
Bei einem mehrteiligen Manifest wird der Ordner angegeben, der die zusammengehörigen YAML-Dateien enthält.
winget validate --manifest "C:\Winget\BeispielEditor\1.0.0"
Winget prüft unter anderem, ob die Manifestdateien mit dem verwendeten Schema vereinbar sind und ob erforderliche Informationen vorhanden sind.
Ausführliche Protokollierung
winget validate ` --manifest "C:\Winget\BeispielEditor\1.0.0" ` --verbose-logs
Bei Fehlern können beispielsweise folgende Probleme vorliegen:
- Fehlende Pflichtfelder
- Ungültige Manifesttypen
- Fehlerhafte YAML-Struktur
- Nicht unterstützte Eigenschaften
- Unterschiedliche Paketkennungen
- Inkonsistente Versionsangaben
- Fehlerhafte Hashformate
Wichtig: Eine erfolgreiche Manifestvalidierung bedeutet nicht automatisch, dass die Installation funktioniert. Der Befehl überprüft in erster Linie die Manifestdefinition und ersetzt keinen vollständigen Installationstest.
Eigene Pakete lokal testen
Nach der Validierung folgt die praktische Funktionsprüfung.
Dafür sollte möglichst eine separate Testumgebung verwendet werden.
Geeignet sind beispielsweise eine Windows-Test-VM, eine Windows-Sandbox oder ein eigens eingerichteter Testrechner.
Installation aus einem lokalen Manifest
Winget unterstützt die Installation aus einer lokalen Manifestdefinition:
winget install ` --manifest "C:\Winget\BeispielEditor\1.0.0"
Abhängig von der Winget-Version und den lokalen Richtlinien muss die Installation lokaler Manifestdateien zuvor als experimentelle beziehungsweise optionale Funktion freigeschaltet werden.
Die verfügbaren Funktionen lassen sich überprüfen mit:
winget features
Bei Bedarf können die entsprechenden Einstellungen über folgenden Befehl angepasst werden:
winget settings
Für den produktiven Einsatz sollten solche Funktionen nur gezielt und unter Berücksichtigung der jeweiligen Sicherheitsrichtlinien aktiviert werden.
Welche Tests sind sinnvoll?
Eine reine erfolgreiche Installation reicht für eine zuverlässige Paketbereitstellung nicht aus.
Auch das Verhalten nach der Installation muss geprüft werden.
Dazu gehören insbesondere die Erkennung der installierten Anwendung, die korrekte Versionsanzeige, die Deinstallation und die Aktualisierung.
Bei mehreren Installervarianten sollten außerdem die jeweiligen Architekturen getestet werden.
Automatisierte Tests mit Windows Sandbox
Microsoft stellt im Community-Repository Werkzeuge zur Verfügung, mit denen sich Paketmanifeste in einer isolierten Windows-Sandbox testen lassen.
Ein entsprechendes Skript heißt SandboxTest.ps1.
Nach dem Herunterladen des offiziellen Repositorys kann beispielsweise folgender Befehl verwendet werden:
.\Tools\SandboxTest.ps1 ` manifests\b\BeispielSoftware\BeispielEditor\1.0.0
Der Pfad muss selbstverständlich an das eigene Manifest angepasst werden.
Windows Sandbox benötigt eine unterstützte Windows-Edition und aktivierte Virtualisierungsfunktionen.
Der Vorteil einer solchen Testumgebung liegt darin, dass die Anwendung unter weitgehend sauberen Bedingungen installiert werden kann.
Dadurch lassen sich Probleme erkennen, die auf einem bereits eingerichteten Entwicklerrechner möglicherweise verborgen bleiben.
Microsoft beschreibt dieses Testverfahren auch in der Dokumentation zur Einreichung von Paketmanifesten.
Updates und neue Paketversionen
Sobald eine neue Version einer Anwendung erscheint, müssen die zugehörigen Paketinformationen aktualisiert werden.
Angenommen, BeispielEditor wird von Version 1.0.0 auf Version 1.1.0 aktualisiert.
Dann wird für die neue Version ein eigener Manifestordner angelegt:
BeispielEditor/
├── 1.0.0/
│ ├── BeispielSoftware.BeispielEditor.yaml
│ ├── BeispielSoftware.BeispielEditor.installer.yaml
│ └── BeispielSoftware.BeispielEditor.locale.de-DE.yaml
└── 1.1.0/
├── BeispielSoftware.BeispielEditor.yaml
├── BeispielSoftware.BeispielEditor.installer.yaml
└── BeispielSoftware.BeispielEditor.locale.de-DE.yaml
Die Paketkennung bleibt unverändert, während die Versionsnummer angepasst wird.
Zusätzlich müssen die neue Installeradresse und der passende SHA-256-Prüfwert eingetragen werden.
Gegebenenfalls ändern sich auch weitere Eigenschaften, beispielsweise die unterstützten Betriebssystemversionen oder die Installationsparameter.
Warum sollte die Paketkennung gleich bleiben?
Winget verwendet die Paketkennung, um Anwendungen über unterschiedliche Versionen hinweg zuzuordnen.
Würde sich die Kennung bei jeder Veröffentlichung ändern, könnte Winget die neue Version möglicherweise als eigenständiges Paket behandeln.
Deshalb sollte die Kennung möglichst stabil bleiben.
Updates testen
Ein sinnvoller Test besteht darin, zunächst die bisherige Version zu installieren und anschließend die neue Version darüber zu aktualisieren.
Dabei sollte überprüft werden, ob vorhandene Einstellungen erhalten bleiben, ob die neue Version korrekt erkannt wird und ob ein Neustart erforderlich ist.
Besonders bei unternehmensinternen Anwendungen sind diese Tests wichtig, weil ein fehlerhaftes Update viele Arbeitsplätze gleichzeitig betreffen könnte.
Typische Fehler bei eigenen Winget-Paketen
Bei der Erstellung eigener Pakete treten bestimmte Fehler besonders häufig auf.
Fehlerhafte Downloadadressen
Der Installer muss unter der angegebenen URL tatsächlich erreichbar sein.
Temporäre Downloadlinks oder URLs, die eine Anmeldung verlangen, sind für die öffentliche Paketverteilung in der Regel ungeeignet.
Falsche Prüfsummen
Wird eine Installationsdatei verändert, muss auch der SHA-256-Wert im Manifest aktualisiert werden.
Andernfalls schlägt die Integritätsprüfung fehl.
Falsche Installationsparameter
Nicht jeder Installer unterstützt dieselben Silent-Schalter.
Deshalb sollten Installationsparameter niemals ungeprüft von anderen Paketen übernommen werden.
Ungeeignete Paketkennung
Eine schlecht gewählte Paketkennung erschwert die langfristige Pflege.
Sie sollte eindeutig, verständlich und möglichst dauerhaft verwendbar sein.
Fehlende Erkennungsinformationen
Winget muss installierte Anwendungen möglichst zuverlässig identifizieren können.
Bei klassischen Installern können dazu beispielsweise die in Windows registrierten Produktinformationen beitragen.
Bei MSI-Paketen spielen Produktcodes eine wichtige Rolle.
Wenn diese Informationen nicht stimmen, kann Winget Probleme bei der Erkennung oder Aktualisierung einer Anwendung bekommen.
Unvollständige Tests
Ein Manifest kann formal korrekt sein, obwohl die eigentliche Installation scheitert.
Deshalb gehören Validierung und praktische Installationstests immer zusammen.
Best Practices für eigene Winget-Pakete
Wer regelmäßig Pakete erstellt oder pflegt, sollte einen standardisierten Ablauf etablieren.
Bewährt haben sich insbesondere folgende Vorgehensweisen:
- Eindeutige Paketkennungen verwenden: Kennungen sollten langfristig stabil bleiben.
- Installer aus vertrauenswürdigen Quellen beziehen: Downloadadressen und Herstellerinformationen müssen nachvollziehbar sein.
- SHA-256-Werte für jede Version neu berechnen: Alte Prüfsummen dürfen nicht ungeprüft übernommen werden.
- Silent-Installationen testen: Automatisierte Bereitstellungen dürfen keine unerwarteten Eingaben verlangen.
- Metadaten vollständig pflegen: Lizenz, Hersteller, Beschreibung und Versionsinformationen sollten korrekt sein.
- Pakete in isolierten Umgebungen prüfen: Eine Test-VM oder Windows Sandbox reduziert Risiken.
- Updates gesondert testen: Nicht nur Neuinstallationen, sondern auch Aktualisierungen müssen funktionieren.
- Manifestdateien versionieren: Git eignet sich hervorragend, um Änderungen nachvollziehbar zu dokumentieren.
- Digitale Signaturen berücksichtigen: Besonders in Unternehmensumgebungen sollten signierte Installer bevorzugt werden.
- Paketpflege langfristig einplanen: Veraltete Downloadlinks und nicht mehr unterstützte Installer müssen regelmäßig überprüft werden.
Eigene Pakete in Unternehmen und Behörden
Für Unternehmen und öffentliche Verwaltungen kann die Erstellung eigener Winget-Pakete einen erheblichen Mehrwert bieten.
Insbesondere wiederkehrende Installationen lassen sich dadurch vereinheitlichen.
Ein Beispiel wäre eine interne Fachanwendung, die regelmäßig auf neuen Arbeitsplätzen installiert werden muss.
Statt jedes Mal einen manuellen Installationsprozess durchzuführen, könnte ein passendes Paketmanifest erstellt werden.
Das ermöglicht eine reproduzierbare Bereitstellung und erleichtert die Integration in automatisierte Installationsprozesse.
Allerdings sind einige organisatorische und sicherheitstechnische Aspekte zu berücksichtigen.
Private Software nicht öffentlich veröffentlichen
Interne Fachanwendungen, vertrauliche Downloadadressen oder nicht öffentlich lizenzierte Software gehören nicht in das öffentliche Winget-Community-Repository.
Für solche Anwendungen können private Paketquellen oder andere interne Bereitstellungsmechanismen eingesetzt werden.
Dabei ist zu beachten, dass eine gewöhnliche Webadresse mit YAML-Dateien nicht automatisch eine kompatible Winget-Paketquelle darstellt.
Berechtigungen und Vertrauenswürdigkeit
Die Installation von Software kann weitreichende Auswirkungen auf die Sicherheit eines Windows-Systems haben.
Deshalb sollten eigene Pakete vor ihrer Freigabe geprüft werden.
Besonders wichtig sind:
- Kontrolle der Softwareherkunft
- Prüfung digitaler Signaturen
- Nachvollziehbare Versionsverwaltung
- Geregelte Freigabeprozesse
- Dokumentation von Änderungen
- Getrennte Test- und Produktivumgebungen
Winget ersetzt dabei keine zentrale Software-Governance und kein vollständiges Patch-Management.
Es kann jedoch ein wertvoller Baustein einer standardisierten Softwarebereitstellung sein.
Fazit: Winget als Werkzeug für die eigene Softwareverteilung
Mit eigenen Paketmanifesten wird Winget von einem einfachen Installationswerkzeug zu einem flexiblen Bestandteil moderner Softwarebereitstellung.
Die YAML-basierte Paketbeschreibung ermöglicht es, Installationen nachvollziehbar zu definieren und zu automatisieren.
Besonders wichtig sind dabei korrekt konfigurierte Installer, eindeutige Paketkennungen, verlässliche Versionsinformationen und überprüfte SHA-256-Prüfsummen.
Mit WinGetCreate steht zudem ein Werkzeug zur Verfügung, das die Erstellung und Pflege eigener Paketmanifeste erheblich erleichtern kann.
Für Entwickler bietet Winget einen zusätzlichen Weg, Software bereitzustellen. Administratoren profitieren von reproduzierbaren Installationen und besser dokumentierten Bereitstellungsprozessen.
Die eigentliche Stärke zeigt sich allerdings erst dann, wenn eigene Pakete nicht nur erstellt, sondern auch zuverlässig getestet, versioniert und kontinuierlich gepflegt werden.
