Vor drei Monaten saß ich bei einem Maschinenbauer in der Nähe von Augsburg. 180 Mitarbeitende, Fertigung plus Verwaltung. Die IT-Mannschaft: zwei Leute. Der eine hält die Infrastruktur am Laufen, der andere entwickelt nebenbei eine WPF-Anwendung, die Maschinendaten aus der Halle ins ERP schreibt. Keine große Sache, aber die Anwendung läuft auf 14 Workstations in der Produktion — und jedes Update ist ein kleines Projekt. Keine Automatisierung, kein Rollout-Tool, manchmal USB-Stick, manchmal RDP. Wenn ich solche Setups sehe, denke ich sofort: Hier ist Packaging das Problem. Nicht die Architektur, nicht die Sprache, nicht der Code.
Genau deshalb hat mich der neue Artikel vom .NET Blog interessiert.
Microsoft beschreibt mit dem WinApp CLI ein Werkzeug, das zwei konkrete Schmerzpunkte löst: Package Identity für lokale Entwicklung und das Erzeugen von MSIX-Paketen für die Distribution. Package Identity ist das Konzept, mit dem Windows eine Anwendung offiziell "kennt" — erst dann bekommt sie Zugang zu Features wie Push-Notifications, Background Tasks oder den neuen Windows AI APIs. Bisher war der Weg dahin für .NET-Entwickler mühsam: Manifeste von Hand schreiben, Zertifikate jonglieren, Build-Pipelines anpassen. Mit winapp init und winapp pack soll das auf wenige Befehle schrumpfen. Der Artikel ist technisch sauber, die Beispiele sind konkret, und das Feature ist real — Microsoft liefert hier etwas Nützliches.
Jetzt die KMU-Brille auf.
Was tatsächlich zählt: Hast du überhaupt das Problem?
Package Identity brauchst du, wenn deine Anwendung Windows-Features nutzt, die dahinter liegen. Push Notifications auf dem Desktop? Background Tasks? Windows AI APIs? Ich frage mich bei jedem Mandat zuerst: Welcher Anteil der 30-300 Mitarbeitenden-Betriebe hat eine .NET-Eigenentwicklung, die das wirklich braucht?
Meine Schätzung aus der Praxis: weniger als 20 Prozent. Die meisten Mittelständler mit Eigenentwicklungen bauen CRUD-Applikationen — Daten rein, Daten raus, vielleicht ein Report. Keine Windows-Integration, die Package Identity erfordert. Der Maschinenbauer aus Augsburg: Er braucht keine Push Notifications. Er braucht, dass das Update auf 14 Workstations ankommt, ohne dass der Entwickler persönlich vorbeifährt.
Das eigentliche Problem: Rollout, nicht Identity
MSIX ist hier tatsächlich interessant — aber aus einem anderen Grund als Microsoft ihn betont. MSIX-Pakete lassen sich mit dem Windows Package Manager (winget) ausrollen, mit Intune verteilen, oder — für alle ohne Microsoft 365 Business Premium — über ein einfaches Netzwerkfreigabe-Verfahren installieren. Das ist der echte Mehrwert für KMU: reproduzierbare, versionierte Installation ohne Setup-Exe-Chaos.
Nur: Genau diesen Teil streift der Artikel. winapp pack wird erklärt, aber was du dann mit dem MSIX machst — kein Wort darüber. Der Weg von "ich habe ein MSIX" zu "die 14 Workstations bekommen es automatisch" fehlt vollständig. Für einen Enterprise-Entwickler mit SCCM im Rücken kein Problem. Für den Zweipersonen-IT-Betrieb im Mittelstand ist das die entscheidende Lücke.
Zertifikate: Das Thema, das alle nervt
Der Artikel erwähnt winapp cert generate — ein Befehl zum Erzeugen eines selbstsignierten Zertifikats. Das ist gut für die Entwicklung und fürs interne Testen. Für die Produktion reicht es nicht. Selbstsignierte Zertifikate müssen auf jeder Zielmaschine als vertrauenswürdig eingetragen werden. In einer Domäne mit GPO: machbar. Ohne Domäne, mit lokalen Adminrechten auf 14 Workstations: ein Abend Arbeit.
Die Alternative — ein Code-Signing-Zertifikat von einer öffentlichen CA — kostet zwischen 300 und 500 Euro pro Jahr. Für eine interne Anwendung, die nie außerhalb der Firma landet, ist das eine Frage, die du intern beantworten musst: Ist uns das wert? Keine falsche Antwort, aber die Frage gehört gestellt, bevor der Entwickler zwei Tage in MSIX investiert.
Was sich lohnt — konkret
Wenn du in einem KMU bist und eine .NET-Desktop-Anwendung (WPF, WinForms, Console) betreibst, dann lohnt sich der WinApp CLI unter folgenden Bedingungen:
Erstens: Du willst weg vom Setup-Exe-Ansatz (InnoSetup, NSIS, MSI-Wizard aus den Nullerjahren). MSIX ist moderner, sauberer, und winget-kompatibel. Der Wechsel ist einmalig, der Nutzen ist dauerhaft.
Zweitens: Du hast Intune oder zumindest eine Domäne mit Gruppenrichtlinien. Dann ist der Rollout-Weg klar und der Overhead hält sich in Grenzen.
Drittens: Dein Entwickler kennt .NET und ist bereit, ein paar Stunden in die Manifeste und den Build-Prozess zu investieren. winapp init --use-defaults ist wirklich einfach — aber "einfach einrichten" und "langfristig pflegen" sind zwei verschiedene Dinge.
Was sich nicht lohnt: Den Aufwand einzugehen, nur um dann Package Identity zu haben, ohne eine konkrete Anforderung dafür. Ich habe schon Entwickler gesehen, die Wochen in MSIX investiert haben, weil es "modern" klingt — und am Ende war das Deployment genauso manuell wie vorher, nur komplizierter.
Meine Differenzierung für den Mittelstand
Wenn deine Anwendung intern bleibt und du keine Windows-Platform-APIs brauchst: Schau dir zuerst an, ob eine einfachere Lösung deinen Rollout-Schmerz löst. Ein PowerShell-Skript, das eine neue Version aus einer Netzwerkfreigabe zieht und neu startet, kostet drei Stunden und funktioniert auf jedem Windows-Rechner ohne Voraussetzungen. Nicht elegant, aber wartbar für ein Zweipersonenteam.
Wenn du wächst — Anwendung wird breiter eingesetzt, Update-Frequenz steigt, du willst Versionierung und Rollback — dann ist MSIX mit WinApp CLI der richtige nächste Schritt. Nicht vorher.
Und wenn du tatsächlich Windows AI APIs oder Notifications brauchst: Dann ist Package Identity keine Option, sondern Pflicht, und der WinApp CLI ist Stand heute der einfachste Weg dahin. Der Artikel beschreibt das korrekt und ich würde ihm da nicht widersprechen.
Der vollständige Original-Beitrag von .NET Blog (MS): Packaging and Package Identity for .NET apps with WinApp CLI on Windows
Du entwickelst oder betreust eine .NET-Desktop-Anwendung im Mittelstand und fragst dich, ob MSIX, ClickOnce, oder ein simples Skript der richtige Weg für dein spezifisches Setup ist? Lass uns das in 30 Minuten durchgehen — ohne Drumherum.
— Bernhard