Quelle est la meilleure façon de télécharger et d'installer à la demande des DLL dans .NET?

Question

Nous avons une application pour laquelle nous souhaitons installer un shell de base. Au fur et à mesure que les utilisateurs l'utilisent, il télécharge et installe les DLLs nécessaires pour les actions à effectuer (imaginez un scénario d'application avec plusieurs chemins possibles). Actuellement, tout est installé pour tous les chemins possibles via l'application shell. Pendant environ 3 mois sur l'année, les dll utilisées pour les chemins possibles subissent un taux de résiliation élevé avec des mises à jour, nous souhaitons donc commencer à nous assurer que les utilisateurs disposent de la version la plus récente de ces dll. L'idée est que, une fois toutes leurs sélections faites, nous ferions une vérification en ligne pour voir quelles DLL sont requises pour leur sélection et vérifierons si elles ont la version la plus récente de ces fichiers.

Tout cela, nous avons un plan pour la façon de le faire. Le problème que je me bats est quelle est la manière la plus appropriée d '"installer" ces fichiers. ClickOnce n'est pas une option ... trop de choses héritées ici. Notre application est installée dans "Program Files" qui a évidemment des restrictions pour l'écriture de fichiers aléatoires dans le dossier d'installation du programme sous Vista et plus tard.

En ce moment, je vois les options suivantes:

1. On marque installer le répertoire d'installation en écriture pour le groupe « Tout le monde ». Je n'ai pas réellement testé pour voir si cela fonctionnerait encore, ou si Vista fait quelque chose de différent dans ce scénario.
2. Fractionnez la partie téléchargement dans une deuxième application que nous pouvons utiliser pour obtenir des privilèges élevés afin de pouvoir télécharger et installer ces fichiers.

Je penche vers la deuxième option car cela maintient l'aspect sécurité du dossier Program Files. D'autres dans le groupe se penchent vers la première option parce qu'ils ne veulent pas avoir à s'inquiéter des choses. Ou y a-t-il une autre option qui me manque?

L'application est une application .NET, même si elle comporte certaines exigences relatives aux DLL tierces qui ne sont pas des assemblys gérés.

Answer 1

Tant que les DLL que vous voulez charger sont gérées, il existe plusieurs façons de le faire. Une manière consiste à désigner un chemin Environment.SpecialFolder tel qu'AppData et à charger dynamiquement des assemblys dans votre domaine d'application à partir de là. RssBandit fait cela pour les plugins, il y a un répertoire spécial qui charge les dll et recherche des implémentations d'interface spécifiques, les charge dans un domaine d'application temporaire, puis les appelle depuis l'application. Vous pouvez aller plus loin en utilisant une librairie IoC comme ninject ou structuremap.

vous pouvez également essayer MEF, le nouveau cadre d'extensibilité qui sort en C# 4.

Answer 2

Personnellement, j'aime ce que les applications Firefox/XUL font. C'est un hybride de vos deux solutions proposées, je suppose. Ils ont un updater.exe qui vit dans le répertoire d'installation. Je suppose que cela signifie que le répertoire d'installation est rendu inscriptible pendant l'installation afin qu'ils puissent exécuter l'application de mise à jour. Cependant, n'ayant jamais déployé une application de cette manière, je ne peux pas vous dire à quel point c'est un mal de tête (ou pas).

Une alternative que vous n'avez pas mentionnée et que vous ne connaissez peut-être pas est l'utilisation du cache de téléchargement .Net. Lorsque vous tentez de charger un assembly, vous pouvez lui donner une base de code à partir de laquelle charger. Si vous définissez la base de code sur une URL Web (c'est-à-dire http://mywebhost/mycoolapp/) .Net téléchargera l'assembly à partir de cette URL s'il ne se trouve pas dans le cache de téléchargement.Il va également récupérer la dernière version de l'assembly depuis l'URL web s'il y en a une. Cette approche peut être pénible, car vous aurez probablement à faire face à des problèmes de sécurité CAS si votre application nécessite des autorisations élevées. Cependant, il est bon de ne pas avoir à écrire du code pour télécharger les dernières versions de vos assemblys pour vous. Si vous voulez plus d'informations, je peux trouver quelques ressources et donner des exemples plus détaillés.

Answer 3

La façon dont je le gère est d'avoir un update.exe installé dans les fichiers du programme à côté du fichier principal .exe.

Ensuite, au démarrage de l'application, l'application télécharge un fichier XML sur le Web et l'enregistre dans le dossier App Data. Ce fichier contient les dernières versions des dll et a une structure de nom de fichier, version simple.

Exécutez la liste des noms de fichiers et si vous n'avez pas la DLL localement ou si vous avez une ancienne version, ajoutez la DLL nécessaire à une liste de mise à jour. Après la génération de votre liste de mise à jour,

Ignorez Updater.exe avec une liste de lignes de commande des fichiers à mettre à jour. Vous n'avez pas besoin de les écrire dans les fichiers de programme, mais c'est le cas. Sur Vista, mon programme de mise à jour affiche l'invite UAC correctement (comme il se doit pour maintenir la sécurité de Program Files).

Le programme de mise à jour télécharge ensuite les fichiers dans Program Files et redémarre l'application principale. Un problème avec le lancement de la deuxième application est que vous devez lui donner un manifeste avec "AsAdministrator" défini dedans.

Ce n'est pas difficile à faire, mais une fois que le programme de mise à jour est terminé et qu'il redémarre l'application principale, il ne peut pas démarrer l'application principale avec des privilèges normaux. Un exe qui s'exécute en tant qu'administrateur peut également démarrer d'autres exe en tant qu'administrateur, même si "AsInvoker" est défini dans le manifeste. Je ne sais pas pourquoi vous ne pouvez pas le restreindre aux droits normaux ... vous ne pouvez qu'élever des permissions pour une raison quelconque ...