Un bon mécanisme de diffusion pour les applications .net internes pour annoncer leur emplacement et leur version?

Question

Je souhaite fournir à un grand nombre d'applications .net internes un moyen léger d'annoncer leur utilisation. Mon objectif est de savoir quels utilisateurs pourraient bénéficier des enregistrements d’assistance technique et / ou des rappels de mise à niveau.

Il s’agit d’un réseau interne. Il y a bien une connectivité IP entre toutes les machines, et probablement UDP. (Mais probablement pas multicast.)

Écrire sur un partage interne connu ou charger une URL connue serait une possibilité, mais j'aimerais minimiser autant que possible l'impact sur l'application elle-même, même au détriment de la fiabilité. Je préférerais donc ne pas risquer de perdre du temps (par exemple, si j'accède à une ressource centralisée alors qu'elle a disparu) et, idéalement, je ne lancerais pas non plus de thread de travail.

Il serait également intéressant de permettre la présence de plusieurs auditeurs, ce qui est une autre raison pour laquelle je songe à diffuser plutôt qu’à invoquer un service.

Existe-t-il un mécanisme de diffusion inconditionnel que je pourrais utiliser efficacement et en toute sécurité pour cela?

Answer 1

Il existe certes de nombreuses options pour cela, mais celle qui est très facile à implémenter et qui répond à vos critères est un Appel du service Web asynchrone .

Cela ne vous oblige pas à démarrer un thread de travail (le Framework le fera en arrière-plan). Plutôt que d’utiliser l’une des options décrites dans ce lien pour récupérer le résultat, ignorez simplement le résultat car il n’a pas de sens pour l’appel appelant.

Answer 2

J'ai fait quelque chose de similaire, mais pas exactement un "braodcast"

J'ai en interne un outil que plusieurs non-techniciens utilisent dans l'entreprise. Je l'ai vérifier un partage réseau pour un fichier EXE spécifique (le même fichier EXE que vous téléchargeriez si vous vouliez l'utiliser) et compare le numéro de version de ce fichier avec l'assembly en cours d'exécution. Si celui du réseau est plus récent, avertissez l'utilisateur de télécharger le nouveau.

Beaucoup plus simple que d'essayer de configurer un programme de mise à jour automatique pour quelque chose qui ne sera utilisé que dans le même bâtiment que moi.

Answer 3

Si la mise à niveau n'est pas un problème (c'est-à-dire qu'il n'y a aucun cas où utiliser l'ancienne version est meilleure), vous pouvez faire ce que j'ai fait avec quelque chose de similaire:

L’application que les utilisateurs lancent en réalité est un programme de mise à jour. Elle vérifie la version et l’horodatage du fichier sur un partage réseau et, si une version plus récente existe, la copie dans le répertoire du programme. Il exécute ensuite le programme (qu’il ait été mis à jour ou non).

var current = new FileInfo(local);
var latest = new FileInfo(remote);

if (!current.Exists)
    latest.CopyTo(local);

var currentVersion = FileVersionInfo.GetVersionInfo(local);
var latestVersion = FileVersionInfo.GetVersionInfo(remote);

if (latest.CreationTime > current.CreationTime || latestVersion.FileVersion != currentVersion.FileVersion)
    latest.CopyTo(local, true);

Process.Start(local)

J'ai également le programme lui-même pour vérifier si le programme de mise à jour doit être mis à jour (car le programme de mise à jour ne peut pas se mettre à jour lui-même en raison de verrous de fichiers)

Answer 4

Après quelques expériences, j'ai obtenu de bons résultats avec Win32 mailslots .

Il n’existe pas de gestionnaire officiel, mais les fonctions sont simples à utiliser via PInvoke, comme illustré dans des exemples tels que celui-ci .

L'utilisation d'un emplacement de courrier "domaine" fournit un véritable mécanisme de diffusion, autorisant plusieurs écouteurs et ne nécessitant aucun serveur connu.