Veröffentlichen und Bereitstellen eines .NET WPF-Dienstprogramms

Veröffentlichen aus Visual Studio

[1:03 - 1:25] Tim beginnt, indem er mit der rechten Maustaste auf das Projekt in Visual Studio klickt und Publizieren auswählt. Der Assistent bietet verschiedene Ziele an (Azure, Docker, ClickOnce), aber er überspringt sie alle und wählt Ordner. Für ein persönliches Dienstprogramm, das auf Ihren eigenen Rechnern lebt, ist ein Ordnerveröffentlichung der direkteste Weg: Es erzeugt Dateien, die Sie überall dort kopieren können, wo Sie sie benötigen, ohne dass eine Bereitstellungsinfrastruktur erforderlich ist.

Nach Auswahl des Ordnerziels springt Tim direkt zur Einstellungsseite, anstatt die Veröffentlichung sofort durchzuführen. Die Standardeinstellungen benötigen Anpassungen, bevor die Ausgabe dem entspricht, was er will.

Framework-abhängig vs. selbstenthalten

[1:25 - 2:32] Die erste Einstellung ist der Bereitstellungsmodus. Ein frameworkabhängiges Build geht davon aus, dass das .NET SDK oder Laufzeitumgebung bereits auf dem Zielrechner installiert ist. Die Ausgabe ist klein, etwa 200 Kilobyte für diese Anwendung, da sie von der auf Ihrem System vorhandenen gemeinsamen Laufzeit abhängt.

Ein selbstenthaltenes Build bündelt die gesamte .NET-Laufzeit in die Ausgabe. Dadurch wird das Paket portierbar auf Rechnern ohne installiertes .NET, erhöht aber die Größe auf etwa 140 Megabyte. Tim entscheidet sich für frameworkabhängig, weil jeder von ihm genutzte Rechner bereits .NET installiert hat. Wenn Sie ein Tool an Kollegen oder Kunden verteilen, die möglicherweise nicht über die Laufzeit verfügen, ist selbstenthalten die sicherere Wahl, aber für persönliche Dienstprogramme macht der Kompromiss selten Sinn.

Warum WPF und nicht MAUI

[2:50 - 4:10] Tim reagiert auf Feedback, das er erhalten hat, indem er WPF anstelle von MAUI für dieses Projekt verwendet hat. Seine Gründe sind praktisch und nicht ideologisch. Der Bildbetrachter muss nur unter Windows laufen. Das Einführen von MAUI und seiner plattformübergreifenden Schicht fügt einen Overhead hinzu, ohne einen Nutzen für ein einzelnes Plattform-Tool zu bieten.

Über das architektonische Argument hinaus gibt es noch einen Wartungsaspekt. Tims ursprünglicher Quellcode hat rund sieben Jahre über vier oder fünf Rechner hinweg mit minimalen Änderungen überlebt. Die einzigen Updates waren Framework-Upgrades (vom .NET Framework auf .NET 8 und jetzt auf .NET 10). Wenn das Dienstprogramm auf einem Framework aufgebaut gewesen wäre, das bei jedem Apple- oder Google-OS-Update Aufmerksamkeit erfordert, wären diese sieben Jahre des reibungslosen Betriebs ohne Eingriffe nicht möglich gewesen. Ein Dienstprogramm, das mehr Wartungszeit benötigt als es einspart, spart Ihnen nichts mehr.

Einzelpublikation Datei und PDB-Dateien

[4:59 - 6:32] Mit dem festgelegten Bereitstellungsmodus aktiviert Tim "Einzeldatei erstellen" und zielt auf Windows x64. Der Veröffentlichungsprozess wird abgeschlossen und das Ausgabeverzeichnis geöffnet, das zwei Dateien enthält: die .exe und eine .pdb.

Diese zweite Datei ist eine Programmdatenbankdatei und ihre Rolle ist es, zu verstehen. Wenn Sie im Freigabemodus kompilieren, optimiert und benennt der Compiler interne Symbole zur Performance um. Das PDB-Dokument ordnet diese optimierten Namen Ihrer tatsächlichen Codebasis zu, sodass Sie einen Debugger an das laufende ausführbare Programm anhängen und Haltepunkte setzen können, als ob Sie im Debugmodus arbeiten würden. Für eine Produktionsanwendung für Kunden sollten Sie PDB-Dateien sicher neben jeder Veröffentlichung speichern, damit Sie Probleme nach der Bereitstellung diagnostizieren können.

Für ein Tool, das Sie für sich selbst gebaut haben, merkt Tim an, dass das PDB für das Anwendungslauf nicht erforderlich ist. Er löscht es der Einfachheit halber, warnt die Zuschauer jedoch, diese Gewohnheit nicht für alles zu übernehmen, was an Benutzer geliefert wird. Die einzelne .exe läuft eigenständig ohne das PDB.

Ein Lapsus erwähnenswert: Wenn Sie von frameworkabhängig zu selbstenthalten wechseln und "einzelne Datei" aktiviert lassen, ist die Ausgabe keine einzelne Datei mehr. Zusätzliche Laufzeitsdateien erscheinen neben der ausführbaren Datei. Die Option für eine einzelne Datei erzeugt nur dann eine echte einzelne Datei, wenn sie mit einem frameworkabhängigen Build kombiniert wird.

Platzierung des Dienstprogramms auf Ihrem Computer

[7:17 - 7:52] Mit der ausführbaren Datei in der Hand, bewegt Tim sie an einen dauerhaften Ort. Er nutzt einen dedizierten C:\Apps\SimpleImageViewer Ordner, eine Konvention, die persönliche Werkzeuge von den Programmdateien trennt und einfach auffindbar macht. Die ausführbare Datei von 2024 läuft noch identisch auf seinem aktuellen Rechner, was den früheren Punkt über die Langlebigkeit verstärkt: Ein gut ausgelegtes Dienstprogramm mit einer einfachen Projektstruktur kann Hardwareänderungen und Betriebssystem-Upgrades ohne Modifikationen überstehen.

Hinzufügen des Werkzeugs zum Rechtsklickmenü

[7:52 - 10:21] Der letzte Schritt verdrahtet das Dienstprogramm in das Kontextmenü des Windows Explorers. Tim ändert die Windows-Registrierung, um Einträge an zwei Stellen hinzuzufügen: ein Eintrag zum Rechtsklicken auf einen Ordner (so dass Sie ein Verzeichnis von Bildern öffnen können) und einen zum Rechtsklicken auf einen weißen Bereich innerhalb eines Ordners (um den Betrachter im aktuellen Verzeichnis zu starten).

Jeder Registrierungseintrag erstellt einen Shellbefehl, der den ausgewählten Pfad als Befehlszeilenargument an die ausführbare Datei übergibt. Hier erhält der args Parameter im Einstiegspunkt der Anwendung seinen Wert.

Tim stellt eine .reg Datei bereit, benennt sie jedoch in .txt um, bevor er sie teilt. Diese Vorsichtsmaßnahme ist wichtig: Ein Doppelklick auf eine .reg Datei führt sofort dazu, dass Werte in die Registrierung geschrieben werden, und das Ausführen einer nicht vertrauenswürdigen Registrierungsdatei kann ernsthafte Systemprobleme verursachen. Sein Ansatz erfordert, dass Sie die Datei öffnen, die Pfade überprüfen, sie aktualisieren, um mit Ihrer Maschine übereinzustimmen, die Erweiterung wieder auf .reg umbenennen und sie dann erst ausführen. Wenn Ihnen irgendetwas davon unbekannt erscheint, ist Tims Rat direkt: Ändern Sie nicht die Registrierung.

Für Entwickler, die mit der Registrierung vertraut sind, sind die beiden Einträge unkompliziert. Jede erstellt einen benannten Shell-Befehl unter dem entsprechenden Schlüssel, der auf den vollständigen Pfad Ihrer ausführbaren Datei mit einem %V oder %1 Platzhalter verweist, der das Zielverzeichnis oder den Dateipfad zur Laufzeit übergibt. Ein Neustart kann erforderlich sein, bevor die neuen Kontextmenüeinträge erscheinen.

Abschließen: Einmal bereitstellen, für immer nutzen

[10:21 - 10:30] Der gesamte Bereitstellungsprozess besteht aus zwei Schritten: in einen Ordner veröffentlichen und dann die ausführbare Datei im Rechtsklickmenü registrieren. Kein Installer, kein Aktualisierungsmechanismus, kein Cloud-Dienst. Für ein reines Hilfsprogramm auf Ihrem eigenen Computer ist diese Einfachheit der Punkt.

Abschluss

[10:30 - 10:40] Zusammengefasst: dotnet publish mit framework-abhängigen und Einzeldatei-Einstellungen erzeugt ein leichtgewichtiges ausführbares Programm, das Sie überallhin verschieben können. Ein Paar Registrierungseinträge verwandelt es in eine Kontextmenüaktion, die überall im Windows Explorer verfügbar ist.

Die Lektion, die sich durch das gesamte Video zieht, ist Zurückhaltung. Gleichen Sie Ihren Bereitstellungsansatz dem Umfang Ihrer Anwendung an. Ein für den persönlichen Gebrauch erstelltes Dienstprogramm benötigt nicht die gleiche Infrastruktur wie ein Produkt, das an Tausende von Kunden ausgeliefert wird. Eine solche Behandlung führt nur zu Wartungsarbeiten, die die Zeit aufzehren, die das Tool ursprünglich einsparen sollte.

Beispiel-Tipp: Bewahren Sie Ihre PDB-Dateien auch für persönliche Projekte auf. Speichern Sie sie im gleichen Ordner wie die ausführbare Datei oder in einem nahegelegenen Archiv. Sollte das Dienstprogramm sich Monate später unerwartet verhalten, können Sie mit der PDB Visual Studio anhängen und den Release-Build ohne Neukompilierung aus dem Quellcode debuggen.

Sehen Sie sich das vollständige Video auf seinem YouTube Kanal an, um weitere Einblicke in die Bereitstellung von .NET-Desktop-Anwendungen zu erhalten.