Im Allgemeinen gibt es zwei Methoden zur Anwendungsaktualisierung: Eine besteht darin, den Benutzer zu benachrichtigen (z. B. durch Senden einer E-Mail) und ihn aufzufordern, das aktualisierte Programm von einer bestimmten Website-Adresse herunterzuladen. Die andere besteht darin, die Aktualisierungsverantwortung vom Benutzer auf die zu übertragen Anstatt dass der Benutzer ein Software-Update erhält und installiert, ist die Client-Anwendung selbst dafür verantwortlich, Updates von einem bekannten Server herunterzuladen und zu installieren. Der einzige Eingriff, den der Benutzer vornehmen muss, besteht darin, zu entscheiden, ob er jetzt neue Updates installieren möchte später. Offensichtlich ist Letzteres freundlicher als Ersteres. Sie können jetzt tatsächliche Produkte sehen, die dem letztgenannten Ansatz ähneln, z. B. Windows XP und Microsoft Money. Die in diesem Artikel vorgestellte .NET-Anwendungsaktualisierungskomponente kann ähnliche Funktionen bereitstellen.
1. Einführung in die .NET-Anwendungsaktualisierungskomponente
Die .NET-Anwendungsaktualisierungskomponente AppUpdater wird unter Verwendung des .NET-Frameworks entwickelt. Obwohl AppUpdater kein Microsoft-Produkt ist, können Sie die Komponente wie andere Komponenten per Drag & Drop aus der Symbolleiste in Ihre Anwendung ziehen, nachdem Sie sie zur VS.NET-Symbolleiste hinzugefügt haben und Häufigkeit des Bezugs von Updates usw.) kann Ihre Client-Anwendung über die automatische Update-Funktion verfügen.
2. Funktionsprinzip
Um das Funktionsprinzip der .NET-Clientanwendungsaktualisierungskomponente genau zu verstehen, müssen Sie sorgfältig studieren, was getan werden muss, um die Clientanwendungsaktualisierung zu implementieren. Der erste Schritt besteht darin, zu prüfen, ob ein Update vorhanden ist; wenn ein Update gefunden wird, starten Sie den zweiten Schritt – laden Sie das Update herunter, wenn der Update-Download abgeschlossen ist, fahren Sie mit dem letzten Schritt fort – implementieren Sie das Update.
(1) Nach Updates suchen
Als Entwickler müssen Sie der Anwendung zunächst mitteilen, wo sie nach Updates suchen soll. Wäre das nicht wie die Suche nach der Nadel im Heuhaufen? Zweitens legen Sie fest, wann nach Updates gesucht werden soll. Es ist für den Benutzer unmöglich, das Client-Programm jedes Mal auszuführen, und es sucht ständig im Hintergrund nach Updates. Was für eine Verschwendung von Ressourcen! Eine letzte wichtige Sache, die es zu klären gilt, ist die Suche nach Updates. Die .NET Application Update-Komponente verwendet HTTP für die Kommunikation, wodurch Clientanwendungen Aktualisierungen über Firewalls durchführen können. Und die für die Update-Prüfung erforderliche Adresse wird zu einer URL-Adresse eines bekannten Webservers, und das erste Problem ist erfolgreich gelöst.
Die .NET-Anwendungsaktualisierungskomponente generiert einen Thread basierend auf der Komponentengenerierung, der für die Aktualisierungsprüfung verantwortlich ist. Dieser Thread schläft die meiste Zeit, wacht jedoch in festgelegten Intervallen auf und führt eine Aktualisierungsprüfung durch. Die Häufigkeit, mit der eine Anwendung nach neuen Updates sucht, hängt von der Anwendung ab. Übliche Werte für das Intervall zwischen Update-Prüfungen liegen typischerweise zwischen einer Stunde und mehreren Tagen. Dieser grundlegende Umfrageansatz ist nicht für jede Situation geeignet. Microsoft Money sucht beispielsweise nur dann nach Updates, wenn der Benutzer dies verlangt. In diesem Fall kann der Update-Polling-Thread deaktiviert werden.
Die Update-Überprüfung wird durch den Aufruf der CheckForUpdate()-Methode der Update-Komponente mit einem Befehl implementiert.
Es gibt mehrere Methoden zur Durchführung von Aktualisierungsprüfungen:
Methode 1: Direkte Dateiprüfung – Verwenden Sie HTTP, um den Datums-/Zeitstempel der letzten Änderung der Server- und Clientanwendungen zu vergleichen, um festzustellen, ob sie konsistent sind. Wenn auf dem Server eine aktualisierte Datei vorhanden ist, weiß der Client, dass er sich selbst aktualisieren kann. Das Gleiche gilt für einen Webbrowser, der weiß, ob er eine HTML-Seite oder ein HTML-Bild erneut herunterladen muss oder ob er eine zuvor heruntergeladene Seite oder ein zuvor heruntergeladenes Bild wiederverwenden kann. Wenn eine neue Version der Anwendung verfügbar wird, kopiert der Administrator einfach die neuere Version über die ältere Version auf dem Webserver. Das Problem bei diesem Ansatz besteht darin, dass die Aktualisierung nicht automatisch erfolgt und daher die Gefahr eines Fehlers besteht. Wenn beispielsweise ein Administrator die Version einer Anwendung auf einem Webserver aktualisiert und ein Kunde eine Version vor dem Update herunterlädt, verfügt der Computer des Kunden über einige Dateien von vor dem Update sowie einige Dateien von der neuen Version Version nach dem Update-Dokument. Aus den oben genannten Gründen wird die direkte Dateiprüfung auf Updates für kritische Anwendungen nicht empfohlen.
Methode 2: Explizite Prüfung – Verwenden Sie eine explizite Konfigurationsdatei auf dem Server. Eine gültige explizite Serverdatei zur Verwendung mit .NET-Anwendungsaktualisierungskomponenten sieht etwa so aus: ..
<VersionConfig>
＜AvailableVersion＞1.0.0.0＜/AvailableVersion＞
＜ApplicationUrl＞ http://localhost/demos/selfupdate/V1/ ＜/
ApplicationUrl＞
</VersionConfig>
AvailableVersion gibt die Versionsnummer der neuesten verfügbaren Assembly an. Das ApplicationURL-Attribut gibt die URL-Adresse an, unter der sich diese Version der Anwendung befindet. Wenn Administratoren eine Clientanwendung aktualisieren möchten, kopieren sie die neue Version der Anwendung auf den Webserver und ändern die expliziten Serverdateien entsprechend. Der Client selbst erkennt, dass die explizite Datei des Servers geändert wurde, und lädt dann die explizite Datei herunter. Der Client vergleicht dann die in der expliziten Datei angegebene Assembly-Versionsnummer mit der Versionsnummer der EXE-Datei der Anwendung. Wenn in der expliziten Datei des Servers eine neuere Versionsnummer verfügbar ist, weiß die Anwendung, dass sie aktualisiert werden muss. Diese Methode wird für die meisten Anwendungen empfohlen.
Methode drei: XML-Webdienstprüfung – XML WebServices bietet eine erweiterte Methode zur Aktualisierungsprüfung. Angenommen, Sie möchten eine Reihe früher Benutzer aktualisieren, bevor Sie Ihre anderen Benutzer aktualisieren. Wenn die Clientanwendung einen XML-Webdienst aufruft, um zu prüfen, ob ein Update verfügbar ist, kann dieser XML-Webdienst auch die Datenbank nach diesem Update abfragen und bestimmen Sie, ob der Benutzer ein früher Benutzer ist. Wenn es sich um frühe Benutzer handelt, gibt der XML-Webdienst einen Wert zurück, der angibt, dass Updates verfügbar sind. Wenn nicht, gibt der Webdienst einen Wert zurück, der angibt, dass das Update nicht verfügbar ist. Die in diesem Artikel vorgestellte .NET-Anwendungsaktualisierungskomponente bietet jedoch keine direkte Unterstützung für XML-Webdienste.
Um den XML-Webdienst zum Durchführen von Aktualisierungsprüfungen zu verwenden, erstellen Sie zunächst einen XML-Webdienst und verknüpfen Sie ein OnCheckForUpdate-Ereignis. Dadurch können Sie Ihre eigenen benutzerdefinierten Prüfungen anstelle von Poller-Thread-Aktualisierungsprüfungen schreiben. Das OnCheckForUpdate-Ereignis verfügt über einen Rückgabewert, der angibt, ob ein Update erkannt wurde.
(2) Updates herunterladen
Wenn die .NET-Anwendungsupdatekomponente erkennt, dass ein neues Update verfügbar ist, startet sie automatisch einen weiteren Thread und startet den asynchronen Hintergrund-Download von Updates.
Der Download erfolgt über HTTP-DAV. DAV ist eine erweiterte Version von HTTP, die Funktionen wie Verzeichnis- und Dateiaufzählung bietet. Ein vollständiger Downloadvorgang beginnt mit der Angabe einer URL. Die zum Herunterladen verwendete URL hängt von der Methode ab, mit der die Update-Prüfung durchgeführt wird. Wenn Sie beispielsweise explizite Serverdateien verwenden, wird die zum Herunterladen von Updates verwendete URL über das ApplicationURL-Attribut in der expliziten Serverdatei angegeben.
Das Herunterladen von Updates erfordert offensichtlich eine gewisse Robustheit. Es ist nicht akzeptabel, eine Clientanwendung nach dem Herunterladen und Aktualisieren in einem instabilen Zustand zu belassen. Während des Download-Vorgangs können zahlreiche Probleme auftreten: Der Webserver, zu dem die Update-Datei gehört, ist möglicherweise ausgefallen, der Client-Rechner kann abstürzen oder der Benutzer schließt die Anwendung aus irgendeinem Grund einfach. Da die Anwendung gerade heruntergeladen wird, wird der Download gestoppt, wenn sie geschlossen wird. Eine alternative Designlösung besteht darin, separate Systemdienste für Anwendungsdownloads und -aktualisierungen zu verwenden. Mithilfe von Systemdiensten werden Update-Downloads auch dann fortgesetzt, wenn die Anwendung selbst nicht ausgeführt wird. Tatsächlich verfügt Windows XP über einen integrierten Download-Dienst namens BITS, der diesem Zweck dient. BITS wird von Windows XP verwendet, um Windows selbst herunterzuladen und zu aktualisieren. Weitere Informationen zu BITS finden Sie unter http://msdn.microsoft.com/library/en-us/dnwxp/html/WinXP_BITS.asp . Dieser Dienst wird in der .NET Application Update-Komponente nicht verwendet und kann daher in Windows 9x verwendet werden, das keine Systemdienste unterstützt.
(3) Implementieren von Updates
Die Update-Komponente der .NET-Anwendung gewinnt an Robustheit, indem die Download- und Update-Prozesse in zwei separate Phasen unterteilt werden. Wenn jede Phase abgeschlossen ist, wird sie in einer aktualisierten Manifestdatei aufgezeichnet, die sich im Clientanwendungsverzeichnis befindet. Wenn der Download- oder Aktualisierungsvorgang zu irgendeinem Zeitpunkt unterbrochen wird, wird beim nächsten Start der Anwendung die ursprüngliche Arbeit ab dem letzten abgeschlossenen Haltepunkt fortgesetzt. Jede Phase kann erneut ausgeführt werden. Wenn also mitten in einer Phase ein Fehler auftritt, ist die erneute Ausführung der Phase erfolgreich. Wenn ein Fehler auftritt, beispielsweise dass die Verbindung zum Server während des Downloads verloren geht, versucht die .NET-Update-Komponente es später erneut. Wenn zu viele Fehler gemeldet werden (z. B. wenn der Webserver nie wieder online geht), werden Downloads und Aktualisierungen abgebrochen und Fehler gemeldet.
Unser erster Ansatz besteht darin, einfach einen separaten Prozess zur Implementierung des Updates zu starten. Dieser separate Prozess beendet zunächst den Bewerbungsprozess, implementiert das Update (da es jetzt entsperrt ist), startet den Bewerbungsprozess neu und fährt sich dann selbst herunter, wenn er fertig ist. Daher gibt es bei diesem Design drei grundlegende Probleme:
In manchen Fällen funktioniert es nicht. Wenn eine Anwendung aktualisiert wird, schließt der Aktualisierungsprozess den ursprünglichen Anwendungsprozess und der Aktualisierungsprozess selbst wird ebenfalls geschlossen, sodass die Aktualisierung nicht implementiert wird.
Wir möchten in der Lage sein, den gesamten Code, der aktualisiert werden muss, automatisch zu aktualisieren. Wir möchten die Möglichkeit haben, Patches nicht nur für die Anwendung, sondern auch für die .NET Application Update-Komponente selbst automatisch zu installieren. In diesem Modus können wir den Prozess, der das Update implementiert, nicht aktualisieren.
Es ist unhöflich, den Benutzer zu zwingen, die Anwendung zu schließen und zu warten, während er sie verwendet.
Die letzte Methode zum Implementieren von Anwendungsaktualisierungen ist die Verwendung des parallelen Assemblymusters von .NET Framework. Als Alternative zum Versuch, die Anwendung selbst zu aktualisieren, können Sie eine neuere Version der Anwendung als die aktuell vorhandene Version generieren.
Neue Versionen können durch Zusammenführen des aktuell vorhandenen Anwendungskatalogs mit heruntergeladenen aktualisierten Versionen generiert werden. Wenn die neue Version fertig ist, verwendet der Benutzer automatisch die neue Version, wenn er die App das nächste Mal erneut öffnet. Die Kopie des Originalantrags kann dann entfernt werden. Die schwierige Sache besteht darin, herauszufinden, welche Version zu einem bestimmten Zeitpunkt geladen werden soll. Wir stellen eine Anwendung namens Appstart vor. Appstart ist der Einstiegspunkt in Ihre Anwendung. In diesem Modus sieht Ihr Anwendungsverzeichnis wie folgt aus: ..
--> Programme
--> MyApp
--> Appstart.exe
--> Appstart.config
- -> V1-Ordner
-- > MyApp.exe
--> V1.1-Ordner
--> MyApp.exe
Um Ihre Anwendung auszuführen, starten Sie normalerweise Appstart.exe. Wenn Sie eine Tastenkombination auf dem Desktop haben möchten, muss diese Tastenkombination auf Appstart und nicht direkt auf die Anwendung zeigen (beachten Sie, dass Sie AppStart.exe beliebig umbenennen können, z. B. YourApp.exe). Appstart.exe ist es ein sehr einfaches Programm, das die Datei Appstart.config liest und die angegebene Anwendung lädt. Eine gültige Appstart.config-Datei sieht folgendermaßen aus:
<Config>
＜AppFolderName＞V1 Folder＜/AppFolderName＞
＜AppExeName＞MyApp.exe＜/AppExeName＞
＜AppLaunchMode＞appdomain＜/AppLaunchMode＞
＜/Config＞
AppFolderName gibt den Unterordner an, der die Version der aktuell ausgeführten Anwendung enthält. AppExeName enthält den Namen der exe-Datei, die in diesen Ordner geladen werden soll. Wenn ein Anwendungsupdate abgeschlossen ist, besteht der letzte Schritt darin, den Wert von AppFolderName so zu ändern, dass er auf die neue Version der Anwendung verweist. Auf diese Weise wird die neue aktualisierte Version der Anwendung ausgeführt, wenn der Benutzer das nächste Mal die Anwendung ausführt. AppLaunchMode gibt an, wie die Anwendung geladen wird. Es gibt zwei Möglichkeiten, Anwendungen zu laden: Die erste Möglichkeit ist die Verwendung von AppDomains. AppDomains ist eine Funktion der Common Language Runtime des .NET Frameworks und außerdem eine unabhängige logische Einheit und ein Verwaltungsobjekt. Die Common Language Runtime ermöglicht mehrere Anwendungsdomänen pro Prozess. Auf diese Weise kann Appstart.exe Ihre Anwendung in eine separate AppDomain, aber im selben AppStart.exe-Prozess laden. Obwohl zwei verschiedene Exe-Programme ausgeführt werden (d. h. Appstart.exe und MyApp.exe), wird nur ein Prozess verwendet. AppDomains funktionieren für die meisten Anwendungen einwandfrei, obwohl es einige subtile Unterschiede zwischen der Ausführung in einer separaten AppDomain und der Ausführung in einem separaten Prozess gibt. In diesem Fall kann AppLaunchMode auf „process“ gesetzt werden, was dazu führt, dass die Anwendung in einem separaten Prozess geladen wird.
Sobald Appstart die Anwendung startet, geht es in den Ruhezustand und wartet darauf, dass die Anwendung beendet wird. Sobald die Anwendung beendet ist, wird auch Appstart geschlossen.
3. Exemplarische Vorgehensweise
Zuvor haben wir besprochen, wie das .NET-Anwendungsupdate funktioniert. Wenden wir es nun auf ein Beispiel an.
Schritt 1: Erstellen Sie eine zu aktualisierende Anwendung.
1. Verwenden Sie VS.NET, um ein neues Windows-Anwendungsprojekt mit dem Namen „SampleApp“ zu generieren.
2. Geben Sie dem Formular eine interessante Hintergrundfarbe Ihrer Wahl. Wir werden eine Hintergrundfarbe verwenden, um es von späteren aktualisierten Versionen zu unterscheiden.
3. Fügen wir dieser Anwendung nun eine subtile Funktion hinzu. Fügen Sie zunächst eine Schaltfläche zu Ihrem Formular hinzu. Die komprimierte Datei enthält eine Assembly mit einem einfachen Windows Form. Fügen Sie einen Verweis auf die Assembly „SamplesSampleAppSimpleForm“ in der komprimierten Datei hinzu. Fügen Sie dann Ihrem Button-Ereignishandler zwei Codezeilen hinzu:
..
SimpleForm.Form1 F = new SimpleForm.Form1();
F.Show();
4. Konvertieren Sie Ihr Build-Flag von Debug in RELEASE. Dadurch können wir später Probleme beim Sperren von PDB-Dateien vermeiden, wenn wir eine neue Version der Anwendung erstellen, während die Originalkopie ausgeführt wird. Erstellen und testen Sie Ihre Anwendung.
Schritt 2: Fügen Sie die .NET-Anwendungsaktualisierungskomponente hinzu.
1. Klicken Sie mit der rechten Maustaste auf die Registerkarte „Komponenten“ der VS.NET-Symbolleiste und wählen Sie „Symbolleiste anpassen“. Wählen Sie die Registerkarte „.NET Framework-Komponenten“. Klicken Sie auf „Durchsuchen“ und wählen Sie AppUpdater.dll aus, das sich unter dem AppUpdater-Projekt in der komprimierten Datei befindet, und klicken Sie auf „OK“.
2. Unten in der Komponentenliste der Symbolleiste sollte nun ein AppUpdater-Symbol erscheinen. Ziehen Sie die AppUpdater-Komponente per Drag & Drop auf das SampleApp-Formular. Unten im Formular wird eine Instanz der .NET Application Update-Komponente mit dem Namen appUpdater1 angezeigt.
Schritt 3: Einrichten der .NET-Anwendungsaktualisierungskomponente
In diesem Schritt richten wir die .NET-Anwendungsaktualisierungskomponente ein. Beachten Sie, dass Sie in diesem Beispiel nur die ersten vier Eigenschaften ändern müssen und den Rest auf ihren Standardwerten belassen müssen.
AppUpdater-Attribut: Dies ist der Kern der .NET-Anwendungsaktualisierung. Die folgenden Einstellungen müssen für dieses Programm vorgenommen werden:
(1) AutoFileLoad: Dies steuert die später beschriebenen Befehls-Download-Eigenschaften.
(2) ChangeDetectionMode: Diese Enumeration bestimmt, wie nach Updates gesucht wird. In diesem Beispiel verwenden wir eine explizite Serverprüfung. Setzen Sie diesen Wert daher auf „ServerManifestCheck“.
(3) ShowDefaultUI: Die .NET-Anwendungsaktualisierungskomponente verfügt über eine Reihe von Benutzeroberflächen, um Benutzer über bestimmte Ereignisse zu benachrichtigen, z. B. über die Verfügbarkeit eines neuen Updates oder über einen Fehler, der während des Updates auftritt. Diese Benutzeroberfläche kann deaktiviert werden, indem die Standardbenutzeroberfläche auf ungültig gesetzt und durch eine benutzerdefinierte anwendungsspezifische Benutzeroberfläche ersetzt wird, die in die entsprechenden Ereignisse eingebunden wird (z. B.
OnUpdateComplete) und öffnen Sie die benutzerdefinierte Benutzeroberfläche. Für dieses Beispiel verwenden wir die Standardbenutzeroberfläche. Setzen Sie diesen Wert daher auf „true“.
(4) UpdateUrl: UpdateUrl bestimmt, wo das Update-Programm nach Updates sucht. In diesem Beispiel verwenden wir eine explizite Serverdatei, um nach Updates zu suchen. Daher sollte diese Eigenschaft auf die URL der expliziten Serverdatei festgelegt werden.
Legen Sie in diesem Beispiel Folgendes fest: http://yourWebserver/SampleApp_ServerSetup/UpdateVersion.xml . Bitte ersetzen Sie „IhrWebserver“ durch den Namen Ihres Webservers.
Downloader-Eigenschaft: Die AppUpdater-Komponente verfügt über zwei Unterkomponenten. Die erste heißt Downloader und steuert die Download- und Poller-Eigenschaften der Komponente. Die zweite Unterkomponente von AppUpdater heißt Poller und steuert die Update-Überprüfung.
(1)AutoStart: Boolescher Wert, der steuert, ob der Poller mit der Abfrage beginnen soll, wenn die Anwendung gestartet wird, oder ob er warten soll, bis eine geplante Update-Abfrage startet.
(2) DownloadOnDetection: Boolescher Wert, steuert, ob Poller sofort mit dem Herunterladen von Updates beginnt, wenn ein neues Update erkannt wird, oder ob der explizite Download durch Aufrufen der DownloadUdpate()-Methode gestartet werden soll.
(3)InitialPollInterval: Die Anzahl der Sekunden, die gewartet werden soll, bevor nach dem Start der Anwendung die erste Update-Prüfung durchgeführt wird.
(4)PollInterval: Nach der ersten Aktualisierungsprüfung steuert PollInterval die Anzahl der Sekunden zwischen den einzelnen Aktualisierungsprüfungen. Hinweis: Die Standardeinstellung ist, dass Ihre Anwendung die Anzahl der Aktualisierungsprüfungen reduziert .
Nachdem dies alles erledigt ist, sollte Ihre Eigenschaftentabelle wie folgt aussehen:
Das Verzeichnis SamplesSampleAppSampleApp_Complete enthält eine korrekt installierte Version der Anwendung.
Installation:
(1)DownloadRetryAttempts: Wenn während des Downloads ein Fehler auftritt (z. B. wenn der Webserver ausgefallen ist), versucht der Downloader es später erneut. Diese Eigenschaft steuert, wie oft der Downloader eine Netzwerkanforderung wiederholt, bevor er sie als vollständigen Fehler bei der Anwendungsaktualisierung einstuft.
(2)SecondsBeteweenDownloadRety: Die Anzahl der Sekunden, die gewartet werden soll, bevor die Netzwerkanforderung erneut versucht wird.
(3)UpdateRetryAttempts: Wenn während der Aktualisierung ein schwerwiegender Fehler auftritt (z. B. wenn der Downloader die Anzahl der Wiederholungsversuche überschreitet), wird ein Anwendungsaktualisierungsfehler generiert. Standardmäßig werden Aktualisierungsversuche gestoppt. Beim nächsten Start der Anwendung wird jedoch versucht, die Wiederherstellung durchzuführen (z. B. kann die Aktualisierung des Webservers mehrere Tage lang ausfallen). Diese Eigenschaft steuert die Anzahl der Aktualisierungsversuche. Wenn dieser Wert überschritten wird, bricht der Updater das Update ab, setzt seinen Status zurück und kehrt zur Update-Prüfung zurück.
(4)ValidateAssemblies: Dieses Attribut steuert die Ebene, auf der heruntergeladene Assemblys effektiv abgeschlossen werden. Weitere Informationen finden Sie im Abschnitt „Sicherheit“ dieses Artikels.
Schritt 4: Generieren Sie die V1-Version der Anwendung und stellen Sie sie auf dem Client bereit.
Öffnen Sie im SampleApp-Projekt die Datei AssemblyInfo.cs. Ändern Sie den Wert von AssemblyVersion von „1.0“ in „1.0.0.0“. Dies führt dazu, dass beim Erstellen der Assembly ein Tag mit dem Wert „1.0.0.0“ abgerufen wird. Anstelle des Werts, den VS.NET normalerweise als Inkrement angibt.
1. Erstellen Sie die Anwendung.
2. Kopieren Sie das Verzeichnis SamplesSampleAppSampleApp_ClientSetup aus der komprimierten Datei auf Ihren lokalen Computer. Beachten Sie, dass dieses Verzeichnis bereits AppStart.exe enthält. AppStart.config wurde so eingestellt, dass es auf das Verzeichnis 1.0.0.0 verweist und SampleApp.exe startet.
Kopieren Sie SampleApp (Appupdater.dll, SimpleForm.dll und SampleApp.exe) aus dem Release-Verzeichnis von SampleApp
in das Client-Verzeichnis SampleApp_ClientSetup1.0.0.0. Zu diesem Zeitpunkt wurde eine voll funktionsfähige Version der Anwendung auf dem Client „installiert“ und kann durch Ausführen von AppStart.exe ausgeführt werden.
Schritt 5: Installieren des Webservers
In diesem Schritt installieren wir den Webserver, um die Update-Abfragefunktion bereitzustellen. Die .NET-Anwendungsaktualisierungskomponente verwendet HTTP-DAV zum Herunterladen von Anwendungsaktualisierungen und erfordert daher einen Webserver, der HTTP-DAV unterstützt. IIS5.0 unter Windows 2000 und neueren Betriebssystemen unterstützt HTTP-DAV.
1. Kopieren Sie das Verzeichnis Samples/SampleApp_ServerSetup in das wwwroot-Verzeichnis auf Ihrem Webserver.
2. Kopieren Sie die V1-Version von SampleApp in den Ordner 1.0.0.0 des Webservers.
3. Aktivieren Sie die „Directory Browse“-Berechtigung von IIS für das SampleApp_ServerSetup-Verzeichnis auf dem Webserver.
Schritt sechs: Anwendungen automatisch aktualisieren
OK, ... Jetzt ist es an der Zeit, die Ergebnisse all dieser harten Arbeit zu sehen, indem automatisch eine neue Version installiert wird.
1. Wenn die Version von SampleApp, die Sie auf dem Client bereitgestellt haben, nicht ausgeführt wird, laden Sie sie und lassen Sie sie ausführen. Denken Sie daran, AppStart.exe zu verwenden.
2. Gehen Sie zurück zu VS.NET und nehmen Sie einige auffällige Änderungen im SampleApp-Formular vor (z. B. das Ändern der Hintergrundfarbe).
3. Ändern Sie die Versionsinformationen von AssemblyInfo.cs in 2.0.0.0.
4. Regenerieren.
5. Kehren Sie zum Webserver zurück und erstellen Sie ein Verzeichnis 2.0.0.0, das dem Verzeichnis 1.0.0.0 entspricht. Kopieren Sie die neue Version der Anwendung aus dem Release-Generierungsverzeichnis in das neu erstellte Verzeichnis 2.0.0.0 auf dem Webserver.
6. Öffnen Sie UpdateVersion.xml und ändern Sie AvailableVersion in 2.0.0.0. Ändern Sie die ApplicationURL so, dass sie auf den neuen Pfad 2.0.0.0 verweist.
7. Speichern Sie die an UpdateVersion.xml vorgenommenen Änderungen.
Sobald Sie die neue UpdateVersion.xml innerhalb von 30 Sekunden speichern, erkennen ausgeführte Kopien von SampleApp die neue verfügbare Version.
4. On-Demand-Installation, Sicherheit, Skalierbarkeit und Debugging
(1) On-Demand-Installation
Die sogenannte On-Demand-Installation bedeutet, dass nur das ausführbare Hauptprogramm explizit auf dem Client-Computer installiert wird. Der Rest der Anwendung kann je nach Grundbedarf automatisch heruntergeladen und installiert werden.
Initiieren Sie die bedarfsgesteuerte Installation über die AutoFileLoad-Eigenschaft der .NET-Anwendungsaktualisierungskomponente. Sie müssen sorgfältig überlegen, wo innerhalb Ihrer Anwendung Assemblygrenzen liegen und welche Aktionen dazu führen, dass die Assembly heruntergeladen wird. Da das Herunterladen der Baugruppe eine Netzwerkeingabe und -ausgabe erfordert, ist die zum Herunterladen benötigte Zeit unterschiedlich. Während des Assembly-Downloads ist die Anwendung eingefroren und wartet auf den Abschluss des Assembly-Downloads.
(2) Bereitstellung
Die Möglichkeit, Anwendungsupdates automatisch und sicher zu installieren, hat viele Vorteile, birgt jedoch auch einige potenzielle Gefahren. Wenn Sie die Installation von Updates vereinfachen, können Sie auch die Installation von Schadcode vereinfachen, wenn Sie nicht vorsichtig sind. Es gibt zwei Gefahren: Die erste Gefahr besteht darin, dass jemand seinen eigenen Webserver nutzt, um den Webserver auszutricksen, der zum Bereitstellen von Updates verwendet wird. Sie können diesen Webserver verwenden, um einen Virus in Ihrem Anwendungspfad zu installieren. Der einfachste Weg, Spoofing oder andere unzulässige Eingriffe in das Netzwerk zu verhindern, ist die Verwendung von HTTPS. Um HTTPS mit der .NET Application Update-Komponente zu verwenden, ersetzen Sie einfach HTTP-URLs durch HTTPS-URLs. Natürlich ist HTTPS kein Allheilmittel. Bei der Verwendung von HTTPS gibt es zwei Probleme. Das erste ist die Skalierbarkeit. Die Verwendung von HTTPS erfordert, dass der Server alle vom Webserver heruntergeladenen Dateien verschlüsselt. Wenn die Aktualisierungsdateien einer Anwendung groß sind, können die Kosten für die Verschlüsselung der Aktualisierungsdateien den Server überlasten. Ein weiteres Problem bei der Verwendung von HTTPS besteht darin, dass es der zweiten Sicherheitsgefahr nicht zugute kommt. Die zweite Gefahr besteht darin, dass Hacker Ihren Server sowohl von innen als auch von außen angreifen können. Wenn der Angriff erfolgreich ist, kann es sein, dass auch Hunderte oder Tausende von Clients von automatischen Updates betroffen sind, was katastrophale Folgen hätte.
Um dieses Problem zu beheben, verwendet die .NET-Anwendungsaktualisierungskomponente die Funktion für starke Namen für .NET-Assemblys, um heruntergeladene Assemblys zu überprüfen. Wenn die .NET Application Update-Komponente beim Herunterladen erkennt, dass eine Assembly nicht mit Ihrem Schlüssel signiert ist, wird der Download abgebrochen. Das bedeutet, dass nur jemand mit dem privaten Schlüssel Ihrer Anwendung Updates erstellen kann, die automatisch bereitgestellt werden können.
Um zu überprüfen, ob die Assembly gültig ist, überprüft die .NET-Anwendungsaktualisierungskomponente, ob der öffentliche Schlüssel Ihrer aktuell installierten ausführbaren Anwendungsdatei und der öffentliche Schlüssel des heruntergeladenen Updates übereinstimmen. Wenn zwei Baugruppen mit demselben geheimen privaten Schlüssel signiert sind, ist der eingebettete öffentliche Schlüssel derselbe. Da die von der CLR geladene Assembly ihren öffentlichen Schlüssel überprüft, führt die CLR ihre normale Hash-Prüfung durch, um sicherzustellen, dass es sich bei der Assembly tatsächlich um eine echte Assembly und nicht um eine manipulierte Assembly handelt. Um die Validierung zum Zeitpunkt des Downloads zu aktivieren, fügen Sie allen Ihren Anwendungsassemblys starke Namen hinzu und legen Sie die ValidateAssemblies-Eigenschaft der .NET Application Update-Komponente auf „true“ fest.
Die Überprüfung der Assembly zum Zeitpunkt des Downloads hilft sehr, aber in der Praxis verfügen Anwendungen häufig über Komponenten, die mit unterschiedlichen privaten Schlüsseln signiert sind. Beispielsweise könnte Ihre Anwendung über zwei Dateien verfügen: eine ausführbare Assembly, die mit Ihrem privaten Schlüssel signiert ist, und eine weitere DLL-Assembly, die ein Diagrammsteuerelement eines Drittanbieters enthält, das Sie erworben und in Ihrer Anwendung verwendet haben. Assemblys von Drittanbietern können mit dem privaten Schlüssel des Drittanbieters anstelle Ihres eigenen signiert werden. Um die Situation noch weiter zu verkomplizieren, kann sich die Einstellung gültiger privater Schlüssel, die zum Signieren von Assemblys in Ihrer Anwendung verwendet werden, von Versionsnummer zu Versionsnummer ändern. Wie aktualisieren Sie diese Anwendungstypen automatisch? Um dieses Problem zu lösen, können Sie in Ihrer Anwendung eine Assembly generieren, die eine Liste gültiger öffentlicher Schlüssel enthält. Signieren Sie die Assembly mit dem privaten Hauptschlüssel der Anwendung (dem Schlüssel, der zum Signieren der Exe-Datei der Anwendung verwendet wird) und platzieren Sie die Assembly in einem Verzeichnis auf dem Webserver mit den Anwendungsaktualisierungsdateien. Bevor der Update-Downloadvorgang beginnt, sucht die .NET Application Update-Komponente nach einer Assembly mit dem Namen „AppUpdaterKeys.dll“ im Anwendungsupdateverzeichnis auf dem Webserver. Falls vorhanden, wird die Assembly heruntergeladen. Die Assembly wird anhand des öffentlichen Schlüssels der Hauptanwendung überprüft. Wenn die Signatur gültig ist, wird die Schlüsselliste extrahiert. Von nun an gilt jeder Schlüssel in dieser Liste als gültige Signatur für die aktualisierte Datei.
Der empfohlene Sicherheitsansatz besteht darin, HTTPS-URLs für Update-Prüfungen zu verwenden. Dies bietet die erste Stufe des Spoofing-Schutzes. Für Update-Downloads ist es am besten, keine HTTPS-RLs zu verwenden, um eine Überlastung Ihres Webservers zu vermeiden. Fügen Sie stattdessen den Assemblys Ihrer Anwendung starke Namen hinzu und verwenden Sie die Assemblyvalidierungsfunktion.
(3) Skalierbarkeit
In dem zuvor in diesem Artikel erwähnten Beispiel haben wir einfach eine Komponente per Drag & Drop in die Anwendung gezogen und einige Eigenschaften festgelegt, um eine automatische Bereitstellung zu erreichen.
Während dies in vielen Anwendungen gut funktioniert, erfordern einige Anwendungen ein hohes Maß an Kontrolle, das nur durch das Schreiben von Code erreicht werden kann. Wir können unseren eigenen Code schreiben, um den Standardprozess der .NET-Anwendungsaktualisierungskomponente zu ersetzen, indem wir die überschriebenen Methoden CheckForUpdate() und ApplyUpdate() verwenden, um das Prüf- und Aktualisierungsverhalten anzupassen.
(4) Debuggen
In diesem Abschnitt werden einige bevorzugte Debugging-Optionen vorgestellt und die häufigsten Probleme beschrieben, mit denen Benutzer dieser Komponente konfrontiert sind.
Der .NET Application Updater generiert eine versteckte Protokolldatei mit dem Namen AppUpdate.log im selben Verzeichnis wie AppStart.exe.
In diesem Protokoll werden alle Erfolgs- und Fehlerinformationen für Aktualisierungen aufgezeichnet. Die Protokolldatei ist besonders nützlich, wenn die Aktualisierung eines bestimmten Clients fehlschlägt.
Anhand der Protokolle können Sie feststellen, wann und wie Aktualisierungen fehlgeschlagen sind. Darüber hinaus verwendet die .NET Application Update-Komponente die Debug-Klasse des .NET Frameworks, um eine Fülle nützlicher Informationen auszugeben. Wenn Sie Ihre Anwendung im Debugger ausführen, werden diese Informationen im Ausgabefenster angezeigt. Sie können den Protokollen des .NET Application Updater folgen, um die Problembereiche hervorzuheben und zu finden.
Wenn Sie den .NET Application Updater aus irgendeinem Grund nicht zum Laufen bringen können, stellen Sie bitte Folgendes sicher, bevor Sie sich mit dem Debuggen befassen. Das Problem, auf das Sie stoßen, ist höchstwahrscheinlich eines der folgenden: ..
Haben Sie zum IIS navigiert? Verzeichnis geöffnet? Andernfalls lädt der Updater keine Dateien herunter und installiert sie nicht.
. Haben Sie alles richtig bereitgestellt und die URL richtig eingestellt?
. Wenn Ihre Anwendung im Programmdateiverzeichnis installiert ist, sind Sie sicher, dass Sie der Superadministrator oder Superuser des Computers sind? Wenn nicht, haben Sie keinen Schreibzugriff, um die Anwendung zu aktualisieren.
Generieren Sie das AppUpdater-Objekt im Haupt-UI-Thread der Anwendung? Andernfalls kann der Updater die Benutzeroberfläche nicht anzeigen und schlägt fehl, wenn er ein Ereignis zurück an die Benutzeroberfläche auslöst.
. Ist das Update erfolgreich, aber die Anwendung startet nicht automatisch mit dem neuen Update? Die .NET Application Update-Komponente versucht, die Anwendung durch Aufrufen der Application.Exit-Methode zu beenden. Diese Methode garantiert jedoch nicht, dass eine Anwendung geschlossen wird. Wenn Sie einen separaten Thread erzeugen und laufen lassen, kann diese Methode den Prozess nicht beenden. Die Lösung, um sicherzustellen, dass alle Threads beendet werden, besteht darin, das Application.OnExit-Ereignis aufzurufen oder sich in das OnUpdateComplete-Ereignis des .NET-Anwendungs-Updaters einzubinden und das Herunterfahren selbst durchzuführen.
5. Zusammenfassung
Die komfortable Bereitstellung von Clientanwendungen ist ein wichtiges Ziel der ersten Version des .NET Frameworks. Die Verwendung des .NET-Frameworks ist eine großartige Technik zum Erstellen von Clientanwendungen, die Bereitstellungsprobleme lösen. Die einfache Bereitstellung bleibt ein wichtiges Ziel für zukünftige neue Versionen des .NET Framework. Als Lösung stellt die hier beschriebene .NET-Anwendungsaktualisierungskomponente einige unserer Ideen dar, die wir in zukünftigen Versionen des .NET Frameworks direkt nutzen können. In der Zeit vor diesem Zeitpunkt kann die .NET-Anwendungsaktualisierungskomponente jedoch als eine wichtige Möglichkeit angesehen werden, mit der Erstellung automatischer Aktualisierungsanwendungen zu beginnen.
Von: csdn, ich habe es auf Tianji gesehen, ich habe es noch nicht sorgfältig studiert Ich werde es für später aufheben