Il existe généralement deux méthodes de mise à jour de l'application : l'une consiste à informer l'utilisateur (par exemple en envoyant un e-mail) et à lui demander de télécharger le programme mis à jour à partir d'une adresse de site Web désignée, l'autre consiste à transférer la responsabilité de la mise à jour de l'utilisateur à l'utilisateur ; l'application elle-même. Au lieu que l'utilisateur obtienne et installe une mise à jour logicielle, l'application client elle-même est responsable du téléchargement et de l'installation des mises à jour à partir d'un serveur connu. La seule intervention que l'utilisateur doit effectuer est de décider s'il souhaite installer de nouvelles mises à jour maintenant ou. plus tard. Évidemment, ce dernier est plus convivial que le premier. Vous pouvez désormais voir des produits réels qui ressemblent à cette dernière approche, tels que Windows XP et Microsoft Money. Le composant de mise à jour de l'application .NET présenté dans cet article peut fournir des fonctionnalités similaires.
1. Introduction au composant de mise à jour d'application .NET
Le composant de mise à jour d'application .NET AppUpdater est développé à l'aide du framework .NET. Bien qu'AppUpdater ne soit pas un produit Microsoft, tant que vous ajoutez le composant à la barre d'outils VS.NET, vous pouvez faire glisser et déposer le composant de la barre d'outils vers votre application, tout comme si vous utilisiez d'autres composants après avoir défini certaines propriétés (telles que l'emplacement). et fréquence d'obtention des mises à jour, etc.), votre application client peut disposer de la fonction de mise à jour automatique.
2. Principe de fonctionnement
Pour comprendre en profondeur le principe de fonctionnement du composant de mise à jour de l'application client .NET, vous devez étudier attentivement ce qui doit être fait pour implémenter la mise à jour de l'application client. La première étape consiste à vérifier s'il existe une mise à jour ; lorsqu'une mise à jour est trouvée, démarrez la deuxième étape : téléchargez la mise à jour lorsque le téléchargement de la mise à jour est terminé, passez à la dernière étape : implémentez la mise à jour.
(1) Vérifiez les mises à jour.
En tant que développeur, vous devez d’abord indiquer à l’application où rechercher les mises à jour. Sinon, ne serait-ce pas comme chercher une aiguille dans une botte de foin ? Deuxièmement, déterminez quand rechercher les mises à jour. Il est impossible pour l'utilisateur d'exécuter le programme client à chaque fois et il vérifie constamment les mises à jour en arrière-plan. Quel gaspillage de ressources ! Une dernière chose importante à aborder est de savoir comment vérifier les mises à jour. Le composant .NET Application Update utilise HTTP pour la communication, ce qui permet aux applications clientes d'effectuer des mises à jour via des pare-feu. Et l'adresse requise pour la vérification des mises à jour devient l'adresse URL d'un serveur Web connu, et le premier problème est résolu avec succès.
Le composant de mise à jour de l'application .NET génère un thread basé sur la génération du composant, qui est responsable de la vérification des mises à jour. Ce fil dort la plupart du temps, mais se réveille à intervalles définis et effectue une vérification des mises à jour. La fréquence à laquelle une application recherche de nouvelles mises à jour dépend de l'application. Les valeurs courantes pour l'intervalle entre les vérifications de mise à jour varient généralement d'une heure à plusieurs jours. Cette approche basique du sondage ne convient pas à toutes les situations. Par exemple, Microsoft Money ne recherche les mises à jour que lorsque l'utilisateur le demande. Dans ce cas, le fil d’interrogation de mise à jour peut être désactivé.
La vérification des mises à jour est implémentée en appelant la méthode CheckForUpdate() du composant de mise à jour avec une commande.
Il existe plusieurs méthodes pour effectuer des vérifications de mise à jour :
Méthode 1 : vérification directe des fichiers - Utilisez HTTP pour comparer la date/l'heure de la dernière modification des applications serveur et client afin de voir si elles sont cohérentes. S'il existe un fichier mis à jour sur le serveur, le client sait qu'il peut se mettre à jour. Il en va de même pour un navigateur Web, qui sait s'il doit retélécharger une page ou une image html ou s'il peut réutiliser une page précédemment téléchargée. Lorsqu'une nouvelle version de l'application devient disponible, l'administrateur copie simplement la version la plus récente sur l'ancienne version sur le serveur Web. Le problème avec cette approche est que la mise à jour n’est pas automatique, il existe donc un risque d’échec. Par exemple, si un administrateur met à jour la version d'une application sur un serveur Web et qu'un client télécharge une version antérieure à la mise à jour, l'ordinateur du client contiendra certains fichiers d'avant la mise à jour, ainsi que certains fichiers de la nouvelle version. version après le document de mise à jour. Pour les raisons ci-dessus, la vérification directe des mises à jour des fichiers n'est pas recommandée pour les applications critiques.
Méthode 2 : vérification explicite - utilisez un fichier de configuration explicite sur le serveur. Un fichier explicite de serveur valide à utiliser avec les composants de mise à jour d'application .NET ressemble à ceci : ..
<VersionConfig>
＜Version disponible＞1.0.0.0＜/Version disponible＞
＜ApplicationUrl＞ http://localhost/demos/selfupdate/V1/ ＜/
URL de l'application >
</VersionConfig>
AvailableVersion spécifie le numéro de version du dernier assembly disponible. L'attribut ApplicationURL spécifie l'adresse URL où se trouve cette version de l'application. Lorsque les administrateurs souhaitent mettre à jour une application client, ils copient la nouvelle version de l'application sur le serveur Web et modifient les fichiers explicites du serveur en conséquence. Le client détectera lui-même que le fichier explicite du serveur a été modifié, puis téléchargera le fichier explicite. Le client compare ensuite le numéro de version de l'assembly spécifié dans le fichier explicite avec le numéro de version du fichier EXE de l'application. Si un numéro de version plus récent est disponible dans le fichier explicite du serveur, l'application sait qu'elle doit être mise à jour. Cette méthode est recommandée pour la plupart des applications.
Troisième méthode : vérification du service Web XML - XML WebServices fournit une méthode de vérification des mises à jour plus avancée. Par exemple, supposons que vous souhaitiez mettre à jour un ensemble d'utilisateurs antérieurs avant de mettre à jour vos autres utilisateurs. Si l'application cliente appelle un service Web XML pour vérifier si une mise à jour est disponible, ce service Web XML peut également interroger la base de données pour cet utilisateur de mise à jour. et déterminer si l'utilisateur est un utilisateur précoce. S'il s'agit des premiers utilisateurs, le service Web XML renvoie une valeur indiquant que des mises à jour sont disponibles. Dans le cas contraire, le Web Service renvoie une valeur indiquant que la mise à jour n'est pas disponible. Toutefois, le composant de mise à jour de l'application .NET présenté dans cet article ne fournit pas de prise en charge directe du service Web XML.
Pour utiliser le service Web XML pour effectuer des vérifications de mise à jour, créez d'abord un service Web XML et connectez un événement OnCheckForUpdate. Cela vous permet d'écrire vos propres vérifications personnalisées à la place des vérifications de mise à jour du fil d'interrogation. L'événement OnCheckForUpdate a une valeur de retour qui indique si une mise à jour a été détectée.
(2) Télécharger les mises à jour
Lorsque le composant de mise à jour de l'application .NET détecte qu'une nouvelle mise à jour est disponible, il démarre automatiquement un autre thread et démarre le téléchargement en arrière-plan asynchrone des mises à jour.
Le téléchargement s'effectue via HTTP-DAV. DAV est une version étendue de HTTP, qui fournit des fonctionnalités telles que l'énumération de répertoires et de fichiers. Un processus de téléchargement complet commence par la spécification d'une URL. L'URL utilisée pour le téléchargement dépend de la méthode utilisée pour effectuer la vérification de la mise à jour. Par exemple, si vous utilisez des fichiers explicites du serveur, l'URL utilisée pour télécharger les mises à jour est spécifiée via l'attribut ApplicationURL dans le fichier explicite du serveur.
Le téléchargement des mises à jour nécessite évidemment une certaine robustesse. Il est inacceptable de laisser une application client dans un état instable après le téléchargement et la mise à jour. Un certain nombre de problèmes peuvent survenir pendant le processus de téléchargement : le serveur Web auquel appartient le fichier de mise à jour peut être en panne, la machine client peut planter ou l'utilisateur peut simplement fermer l'application pour une raison quelconque. Puisque l'application est en cours de téléchargement, si elle est fermée, le téléchargement s'arrêtera. Une solution de conception alternative consiste à utiliser des services système distincts pour les téléchargements et les mises à jour des applications. À l'aide des services système, les téléchargements de mises à jour se poursuivent même lorsque l'application elle-même n'est pas en cours d'exécution. En fait, Windows XP dispose d'un service de téléchargement intégré appelé BITS, qui sert à cet effet. BITS est utilisé par Windows XP pour télécharger et mettre à jour Windows lui-même. Pour plus d'informations sur BITS, consultez http://msdn.microsoft.com/library/en-us/dnwxp/html/WinXP_BITS.asp . Ce service n'est pas utilisé dans le composant .NET Application Update, il peut donc être utilisé dans Windows 9x qui ne prend pas en charge les services système.
(3) Implémentation des mises à jour
Le composant de mise à jour de l'application .NET gagne en robustesse en divisant les processus de téléchargement et de mise à jour en deux phases distinctes. Lorsque chaque étape est terminée, elle est enregistrée dans un fichier manifeste mis à jour situé dans le répertoire de l'application cliente. Si le processus de téléchargement ou de mise à jour est interrompu à un moment quelconque, le travail original reprendra à partir du dernier point d'arrêt terminé au prochain démarrage de l'application. Chaque étape peut être réexécutée, donc si un échec survient au milieu d'une étape, la réexécution de l'étape réussira. Si une erreur se produit, telle que la perte de la connexion au serveur pendant le téléchargement, le composant de mise à jour .NET réessayera ultérieurement. Si trop d'erreurs sont signalées (par exemple, le serveur Web ne revient jamais en ligne), les téléchargements et les mises à jour seront interrompus et les erreurs signalées.
Notre première approche consiste simplement à démarrer un processus distinct pour implémenter la mise à jour. Ce processus distinct arrêtera d'abord le processus de candidature, mettra en œuvre la mise à jour (puisqu'il est maintenant déverrouillé), redémarrera le processus de candidature, puis s'arrêtera une fois terminé. Par conséquent, cette conception pose trois problèmes fondamentaux :
. Dans certains cas, elle ne fonctionne pas. Lorsqu'une application est mise à jour, le processus de mise à jour ferme le processus de candidature d'origine et le processus de mise à jour lui-même est également fermé, de sorte que la mise à jour ne sera pas implémentée.
. Nous voulons pouvoir mettre à jour automatiquement tout le code qui doit être mis à jour. Nous voulons pouvoir installer automatiquement les correctifs non seulement sur l'application, mais également sur le composant .NET Application Update lui-même. En utilisant ce mode, nous ne pouvons pas mettre à jour le processus qui implémente la mise à jour.
. Il est impoli de forcer l'utilisateur à fermer l'application et à attendre pendant son utilisation.
La dernière méthode utilisée pour implémenter les mises à jour d’application consiste à utiliser le modèle d’assemblage parallèle .NET Framework. Au lieu d'essayer de mettre à jour l'application elle-même, générez une version de l'application plus récente que la version actuellement existante.
De nouvelles versions peuvent être générées en fusionnant le catalogue d'applications actuellement existant avec les versions mises à jour téléchargées. Une fois la nouvelle version terminée, l'utilisateur utilisera automatiquement la nouvelle version la prochaine fois qu'il rouvrira l'application. La copie de la demande originale peut alors être supprimée. Le plus délicat est de savoir quelle version doit être chargée à un moment donné. Nous introduisons une application nommée Appstart. Appstart est le point d'entrée dans votre application. En utilisant ce mode, votre répertoire d'application ressemble à ceci : ..
--> Program Files
--> MyApp
--> Appstart.exe
--> Appstart.config
- -> V1 Folder
-- > MyApp.exe
--> Dossier V1.1
--> MyApp.exe
Pour exécuter votre application, vous démarrez généralement Appstart.exe. Si vous souhaitez avoir une touche de raccourci sur le bureau, cette touche de raccourci doit pointer vers Appstart et non directement vers l'application (notez que vous pouvez renommer AppStart.exe comme vous le souhaitez, comme YourApp.exe). Appstart.exe C'est un programme très simple qui lit le fichier Appstart.config et charge l'application spécifiée. Un fichier Appstart.config valide ressemble à ceci :
<Config>
＜AppFolderName＞Dossier V1＜/AppFolderName＞
＜AppExeName＞MyApp.exe＜/AppExeName＞
＜AppLaunchMode＞appdomain＜/AppLaunchMode＞
＜/Config＞
AppFolderName spécifie le sous-dossier qui contient la version de l'application en cours d'exécution. AppExeName contient le nom du fichier exe à charger dans ce dossier. Lorsqu'une mise à jour d'une application est terminée, la dernière étape consiste à modifier la valeur de AppFolderName pour qu'elle pointe vers la nouvelle version de l'application. De cette façon, la prochaine fois que l'utilisateur exécutera l'application, la nouvelle version mise à jour de l'application s'exécutera. AppLaunchMode spécifie la manière dont l'application est chargée. Il existe deux manières de charger des applications : La première consiste à utiliser AppDomains. AppDomains est une fonctionnalité du Common Language Runtime du framework .NET et constitue également une unité logique indépendante et un objet de gestion. Le Common Language Runtime autorise plusieurs domaines d’application par processus. De cette façon, Appstart.exe peut charger votre application dans un AppDomain distinct mais dans le même processus AppStart.exe. Malgré le fait que deux programmes exe différents sont en cours d'exécution (c'est-à-dire Appstart.exe et MyApp.exe), un seul processus est utilisé. Les AppDomains fonctionneront très bien pour la plupart des applications, bien qu'il existe des différences subtiles entre l'exécution dans un AppDomain distinct et l'exécution dans un processus distinct. Dans ce cas, AppLaunchMode peut être défini sur « processus », ce qui entraînera le chargement de l'application dans un processus distinct.
Une fois qu'Appstart lance l'application, elle se met en veille en attendant la fin de l'application. Une fois l'application terminée, Appstart est également fermé.
3. Exemple de procédure
pas à pas Nous avons discuté plus tôt du fonctionnement de la mise à jour de l'application .NET. Appliquons-le maintenant à un exemple.
Étape 1 : Créer une application à mettre à jour
1. Utilisez VS.NET pour générer un nouveau projet d'application Windows, nommé « SampleApp ».
2. Donnez au formulaire une couleur d’arrière-plan intéressante de votre choix. Nous utiliserons une couleur d’arrière-plan pour le différencier des versions mises à jour ultérieures.
3. Ajoutons maintenant une fonctionnalité subtile à cette application. Tout d'abord, ajoutons un bouton à votre formulaire. Le fichier compressé contient un assembly avec un simple formulaire Windows. Ajoutez une référence à l’assembly SamplesSampleAppSimpleForm dans le fichier compressé. Ajoutez ensuite deux lignes de code à votre gestionnaire d'événements de bouton :
..
SimpleForm.Form1 F = new SimpleForm.Form1();
F.Show();
4. Convertissez votre indicateur de build de débogage en RELEASE. Cela nous permettra d'éviter les problèmes de verrouillage des fichiers PDB plus tard lorsque nous créerons une nouvelle version de l'application pendant que la copie originale est en cours d'exécution. Créez et testez votre application.
Étape 2 : Ajouter le composant de mise à jour de l'application .NET
1. Dans l'onglet Composants de la barre d'outils VS.NET, cliquez avec le bouton droit et sélectionnez « Personnaliser la barre d'outils ». Sélectionnez l'onglet "Composants .NET Framework". Cliquez sur "Parcourir" et sélectionnez AppUpdater.dll situé sous le projet AppUpdater dans le fichier compressé, cliquez sur OK.
2. Une icône AppUpdater devrait maintenant apparaître au bas de la liste des composants de la barre d'outils. Faites glisser et déposez le composant AppUpdater sur le formulaire SampleApp. Une instance du composant .NET Application Update nommée appUpdater1 apparaît au bas du formulaire.
Étape 3 : Configurer le composant de mise à jour de l'application .NET
Dans cette étape, nous allons configurer le composant de mise à jour de l'application .NET. Notez que dans cet exemple, vous devez uniquement modifier les quatre premières propriétés, en laissant le reste à leurs valeurs par défaut.
Attribut AppUpdater : il s'agit du cœur de la mise à jour de l'application .NET. Les paramètres suivants doivent être définis pour ce programme :
(1) AutoFileLoad : ceci contrôle les caractéristiques de téléchargement de la commande qui seront décrites plus tard.
(2) ChangeDetectionMode : cette énumération détermine comment vérifier les mises à jour. Dans cet exemple, nous utiliserons une vérification explicite du serveur, définissez donc cette valeur sur "ServerManifestCheck".
(3) ShowDefaultUI : le composant de mise à jour de l'application .NET dispose d'une série d'interfaces utilisateur pour informer les utilisateurs de certains événements, tels qu'une nouvelle mise à jour disponible ou une erreur survenant lors de la mise à jour. Cette interface utilisateur peut être désactivée en définissant l'interface utilisateur par défaut sur invalide et en la remplaçant par une interface utilisateur personnalisée spécifique à l'application, en se connectant aux événements appropriés (par ex.
OnUpdateComplete) et affichez l'interface utilisateur personnalisée. Pour cet exemple, nous utiliserons l'interface utilisateur par défaut, définissez donc cette valeur sur true.
(4) UpdateUrl : UpdateUrl détermine où le programme de mise à jour recherchera les mises à jour. Dans cet exemple, nous utilisons un fichier explicite du serveur pour vérifier les mises à jour, cette propriété doit donc être définie sur l'URL du fichier explicite du serveur.
Dans cet exemple, définissez-le sur : http://yourWebserver/SampleApp_ServerSetup/UpdateVersion.xml . Veuillez remplacer « votre serveur Web » par le nom de votre serveur Web.
Propriété Downloader : le composant AppUpdater comporte deux sous-composants. Le premier s'appelle Downloader, qui contrôle les propriétés de téléchargement et de Poller du composant : Le deuxième sous-composant d'AppUpdater est Poller, qui contrôle la vérification des mises à jour.
(1)AutoStart : valeur booléenne qui contrôle si le Poller doit commencer l'interrogation au démarrage de l'application ou s'il doit attendre le démarrage d'une requête de mise à jour planifiée.
(2) DownloadOnDetection : valeur booléenne, contrôle si Poller commence à télécharger les mises à jour immédiatement lorsqu'une nouvelle mise à jour est découverte, ou s'il doit démarrer le téléchargement explicite en appelant la méthode DownloadUdpate().
(3)InitialPollInterval : nombre de secondes à attendre avant d'effectuer la première vérification de mise à jour après le démarrage de l'application.
(4)PollInterval : Après la première vérification de mise à jour, PollInterval contrôle le nombre de secondes entre chaque vérification de mise à jour suivante. Remarque : La valeur par défaut est de vérifier toutes les 30 secondes. Vous souhaiterez évidemment que votre application réduise le nombre de vérifications de mise à jour. .
Une fois tout cela fait, votre table de propriétés devrait ressembler à ceci :
Le répertoire SamplesSampleAppSampleApp_Complete contient une version correctement installée de l'application.
Installation :
(1)Tentatives de nouvelle tentative : si une erreur se produit pendant le téléchargement (par exemple, le serveur Web est en panne), le téléchargeur réessayera plus tard. Cette propriété contrôle le nombre de fois que le téléchargeur réessaye une requête réseau avant de la considérer comme une erreur complète de mise à jour de l'application.
(2) SecondsBeteweenDownloadRety : nombre de secondes à attendre avant de réessayer la requête réseau.
(3) UpdateRetryAttempts : si une erreur grave se produit lors de la mise à jour (par exemple, le téléchargeur dépasse le nombre de tentatives), une erreur de mise à jour de l'application sera générée. Par défaut, les tentatives de mise à jour seront arrêtées. Mais il tentera de récupérer au prochain démarrage de l'application (par exemple, la mise à jour du serveur Web peut être indisponible pendant plusieurs jours). Cette propriété contrôle le nombre de tentatives de mise à jour. Si cette valeur est dépassée, le programme de mise à jour annule la mise à jour, réinitialise son état et revient à la vérification des mises à jour.
(4) ValidateAssemblies : cet attribut contrôle le niveau auquel les assemblys téléchargés sont effectivement terminés. Consultez la section Sécurité de cet article pour plus d’informations.
Étape 4 : Générez et déployez la version V1 de l'application sur le client.
Dans le projet SampleApp, ouvrez le fichier AssemblyInfo.cs. Modifiez la valeur de AssemblyVersion de "1.0" à "1.0.0.0". Cela entraîne, lors de la construction de l'assembly, l'obtention d'une balise avec la valeur "1.0.0.0".. au lieu de la valeur que VS.NET spécifie normalement comme incrément.
1. Créez l'application.
2. Copiez le répertoire SamplesSampleAppSampleApp_ClientSetup du fichier compressé sur votre ordinateur local. Notez que ce répertoire contient déjà AppStart.exe. AppStart.config a été configuré pour pointer vers le répertoire 1.0.0.0 et démarrer SampleApp.exe.
Copiez SampleApp (Appupdater.dll, SimpleForm.dll et SampleApp.exe) du répertoire de version de SampleApp
vers le répertoire client SampleApp_ClientSetup1.0.0.0. À ce stade, une version entièrement fonctionnelle de l'application a été « installée » sur le client et peut être exécutée en exécutant AppStart.exe.
Étape 5 : Installer le serveur Web
Dans cette étape, nous installerons le serveur Web pour fournir une fonctionnalité d'interrogation de mise à jour. Le composant .NET Application Update utilise HTTP-DAV pour télécharger les mises à jour d'application et nécessite donc un serveur Web prenant en charge HTTP-DAV. IIS5.0 sur Windows 2000 et les systèmes d'exploitation plus récents prennent en charge HTTP-DAV.
1. Copiez le répertoire Samples/SampleApp_ServerSetup dans le répertoire wwwroot de votre serveur Web.
2. Copiez la version V1 de SampleApp dans le dossier 1.0.0.0 du serveur Web.
3. Activez l'autorisation « Parcourir le répertoire » d'IIS pour le répertoire SampleApp_ServerSetup sur le serveur Web.
Sixième étape : mettre à jour automatiquement les applications
OK,... Il est maintenant temps de voir les résultats de tout ce travail acharné en installant automatiquement une nouvelle version.
1. Si la version de SampleApp que vous avez déployée sur le client n'est pas en cours d'exécution, chargez-la et laissez-la s'exécuter. N'oubliez pas d'utiliser AppStart.exe.
2. Revenez à VS.NET et apportez des modifications notables au formulaire SampleApp (telles que la modification de la couleur d'arrière-plan).
3. Modifiez les informations de version de AssemblyInfo.cs sur 2.0.0.0.
4. Régénérez.
5. Revenez au serveur Web et générez un répertoire 2.0.0.0 équivalent au répertoire 1.0.0.0. Copiez la nouvelle version de l'application du répertoire de génération de version vers le répertoire 2.0.0.0 nouvellement créé sur le serveur Web.
6. Ouvrez UpdateVersion.xml et modifiez AvailableVersion sur 2.0.0.0. Modifiez l'ApplicationURL pour qu'elle pointe vers le nouveau chemin 2.0.0.0.
7. Enregistrez les modifications apportées à UpdateVersion.xml.
Une fois que vous avez enregistré le nouveau UpdateVersion.xml, dans les 30 secondes, l'exécution de copies de SampleApp détectera la nouvelle version disponible.
4. Installation à la demande, sécurité, évolutivité et débogage
(1) Installation à la demande
L'installation dite à la demande signifie que seul le programme exécutable principal est explicitement installé sur l'ordinateur client. Le reste de l'application peut être automatiquement téléchargé et installé en fonction des besoins de base.
Lancez l'installation à la demande via la propriété AutoFileLoad du composant de mise à jour de l'application .NET. Vous devez soigneusement réfléchir à l'emplacement des limites de l'assembly dans votre application et aux actions qui entraîneront le téléchargement de l'assembly. Étant donné que le téléchargement de l’assembly implique une entrée et une sortie réseau, le temps nécessaire au téléchargement est variable. Pendant le téléchargement de l'assembly, l'application est gelée en attendant la fin du téléchargement de l'assembly.
(2) Déploiement
La possibilité d'installer automatiquement et en toute sécurité les mises à jour des applications présente de nombreux avantages, mais elle comporte également certains dangers potentiels. Lorsque vous facilitez l'installation des mises à jour, vous pouvez également faciliter l'installation de codes malveillants si vous ne faites pas attention. Il existe deux dangers. Le premier est que quelqu'un utilise son propre serveur Web pour tromper le serveur Web utilisé pour déployer les mises à jour. Ils peuvent utiliser ce serveur Web pour installer un virus dans le chemin de votre application. Le moyen le plus simple d’empêcher l’usurpation d’identité ou toute autre interférence inappropriée sur le réseau consiste à utiliser HTTPS. Pour utiliser HTTPS avec le composant .NET Application Update, remplacez simplement les URL HTTP par des URL HTTPS. Bien entendu, HTTPS n’est pas une solution miracle. L'utilisation de HTTPS pose deux problèmes. Le premier est l'évolutivité. L'utilisation de HTTPS nécessite que le serveur crypte tous les fichiers téléchargés depuis le serveur Web. Si les fichiers de mise à jour d'une application sont volumineux, le coût du chiffrement des fichiers de mise à jour peut surcharger le serveur. Un autre problème lié à l’utilisation de HTTPS est qu’il ne profite en rien au deuxième danger de sécurité. Le deuxième danger est que des pirates informatiques peuvent attaquer votre serveur aussi bien de l’intérieur que de l’extérieur. Si l’attaque réussit, cela pourrait signifier que des centaines, voire des milliers de clients seront également concernés par les mises à jour automatiques, ce qui serait catastrophique.
Pour résoudre ce problème, le composant .NET Application Update utilise la fonctionnalité de nom fort pour les assemblys .NET afin de vérifier les assemblys téléchargés. Si le composant .NET Application Update détecte qu’un assembly n’est pas signé avec votre clé lors du téléchargement, le téléchargement sera annulé. Cela signifie que seule une personne disposant de la clé privée de votre application peut créer des mises à jour pouvant être déployées automatiquement.
Pour vérifier que l'assembly est valide, le composant .NET Application Update vérifie que la clé publique de l'exécutable de votre application actuellement installée et la clé publique de la mise à jour téléchargée correspondent. Si deux assemblys sont signés avec la même clé privée secrète, alors la clé publique intégrée sera la même. Étant donné que l'assembly chargé par le CLR vérifie sa clé publique, le CLR calcule sa vérification de hachage normale pour garantir que l'assembly est bien un assembly authentique et non un assembly falsifié. Pour activer la validation au moment du téléchargement, ajoutez des noms forts à tous vos assemblys d’application et définissez la propriété ValidateAssemblies du composant .NET Application Update sur true.
La vérification de l'assembly au moment du téléchargement est très utile, mais dans la pratique, les applications auront souvent des composants signés avec des clés privées différentes. Par exemple, votre application peut contenir deux fichiers : un assembly exécutable signé avec votre clé privée et un autre assembly dll contenant un contrôle graphique tiers que vous avez acheté et utilisé dans votre application. Les assemblys tiers peuvent être signés à l’aide de la clé privée du tiers au lieu de la vôtre. Pour compliquer encore la situation, le paramètre de clés privées valides utilisées pour signer les assemblys dans votre application peut changer d'un numéro de version à l'autre. Comment mettre à jour automatiquement ces types d’applications ? Pour résoudre ce problème, vous pouvez générer un assembly dans votre application contenant une liste de clés publiques valides. Signez l'assembly avec la clé privée principale de l'application (la clé utilisée pour signer le fichier exe de l'application) et placez l'assembly dans un répertoire sur le serveur Web contenant les fichiers de mise à jour de l'application. Avant le début du processus de téléchargement de la mise à jour, le composant .NET Application Update recherchera un assembly nommé « AppUpdaterKeys.dll » dans le répertoire de mise à jour de l'application sur le serveur Web. S’il est présent, l’assembly est téléchargé. L’assembly est vérifié par rapport à la clé publique de l’application principale. Si la signature est valide, la liste des clés est extraite. Désormais, toute clé de cette liste sera considérée comme une signature valide pour le fichier mis à jour.
L'approche de sécurité recommandée consiste à utiliser des URL HTTPS pour les vérifications de mise à jour. Cela fournit le premier niveau de protection contre l’usurpation d’identité. Pour les téléchargements de mises à jour, il est préférable de ne pas utiliser de RL HTTPS pour éviter de surcharger votre serveur Web. Au lieu de cela, ajoutez des noms forts aux assemblys de votre application et utilisez la fonctionnalité de validation des assemblys.
(3) Évolutivité
Dans l'exemple mentionné plus haut dans cet article, nous avons simplement glissé et déposé un composant dans l'application et défini certaines propriétés pour réaliser un déploiement automatique.
Bien que cela fonctionne bien dans de nombreuses applications, certaines applications nécessitent un niveau de contrôle élevé qui ne peut être obtenu qu'en écrivant du code. Nous pouvons écrire notre propre code pour remplacer le processus standard du composant de mise à jour de l'application .NET, en utilisant les méthodes CheckForUpdate() et ApplyUpdate() substituées pour personnaliser le comportement de vérification et de mise à jour.
(4) Débogage
Cette section soulignera certaines options de débogage préférées, ainsi que décrira les problèmes les plus courants rencontrés par les utilisateurs de ce composant.
Le programme de mise à jour d'application .NET génère un fichier journal masqué nommé AppUpdate.log dans le même répertoire qu'AppStart.exe.
Toutes les informations de réussite et d’échec de la mise à jour sont enregistrées dans ce journal. Le fichier journal est particulièrement utile lorsqu'un client particulier ne parvient pas à se mettre à jour correctement.
Vous pouvez utiliser les journaux pour déterminer quand et comment les mises à jour ont échoué. De plus, le composant .NET Application Update utilise la classe Debug du .NET Framework pour générer une multitude d'informations utiles. Si vous exécutez votre application dans le débogueur, vous verrez ces informations dans la fenêtre de sortie. Vous pouvez suivre les journaux de .NET Application Updater pour mettre en évidence et trouver les zones problématiques.
Si, pour une raison quelconque, vous ne parvenez pas à faire fonctionner le programme de mise à jour de l'application .NET, assurez-vous des points suivants avant de vous lancer dans le débogage. Le problème que vous rencontrez est probablement l'un des suivants : ..
Avez-vous accédé à IIS. répertoire ? Ouvert ? Sinon, le programme de mise à jour ne téléchargera et n’installera aucun fichier.
. Avez-vous tout déployé correctement et défini l'URL correctement ?
. Si votre application est installée dans le répertoire des fichiers du programme, êtes-vous sûr d'être le super administrateur ou le super utilisateur de la machine ? Sinon, vous n'aurez pas d'accès en écriture pour mettre à jour l'application.
. Générez-vous l'objet AppUpdater dans le thread principal de l'interface utilisateur de l'application ? Dans le cas contraire, le programme de mise à jour ne pourra pas afficher l’interface utilisateur et échouera lors du renvoi d’un événement vers l’interface utilisateur.
. La mise à jour réussit-elle mais l'application ne parvient pas à redémarrer automatiquement avec la nouvelle mise à jour ? Le composant .NET Application Update tente de quitter l’application en appelant la méthode Application.Exit. Cependant, cette méthode ne garantit pas la fermeture d’une application. Si vous générez et laissez un thread distinct en cours d'exécution, cette méthode ne peut pas arrêter le processus. La solution pour garantir que tous les threads se terminent consiste à appeler l'événement Application.OnExit ou à se connecter à l'événement OnUpdateComplete du programme de mise à jour de l'application .NET et à gérer vous-même l'arrêt.
5. Résumé
Le déploiement pratique des applications client est un objectif important de la première version du framework .NET. L'utilisation du framework .NET est une excellente technique pour créer des applications clientes qui résolvent les problèmes de déploiement. La facilité de déploiement reste un objectif important pour les futures nouvelles versions du .NET Framework. En guise de solution, le composant de mise à jour de l'application .NET décrit ici représente certaines de nos idées que nous pourrons utiliser directement dans les futures versions du .NET Framework. Cependant, avant ce moment, le composant de mise à jour des applications .NET peut être considéré comme un moyen important de commencer à créer des applications de mise à jour automatique.
De : csdn, je l'ai vu sur Tianji, je ne l'ai pas encore étudié attentivement, je. je vais le laisser pour plus tard.