¿Un buen mecanismo de transmisión para que las aplicaciones .net internas anuncien su ubicación y versión?

Question

Me gustaría proporcionar una gran cantidad de aplicaciones .net internas con una forma liviana de anunciar que se están utilizando. Mi objetivo es hacer un seguimiento de los usuarios que podrían beneficiarse de los registros de asistencia y / o recordatorios para actualizar.

Esto está en una red interna. Definitivamente hay conectividad IP entre todas las máquinas, y probablemente UDP. (Pero probablemente no sea multidifusión).

Escribir en un recurso compartido interno conocido o cargar una URL conocida serían posibilidades, pero me gustaría minimizar el impacto en la aplicación lo más completamente posible, incluso a expensas de la confiabilidad. Así que prefiero no arriesgarme a un tiempo de espera (por ejemplo, si estoy accediendo a un recurso centralizado y ha desaparecido), e idealmente tampoco preferiría lanzar un hilo de trabajo.

También sería bueno permitir múltiples oyentes, que es otra razón por la que estoy pensando en transmitir en lugar de invocar un servicio.

¿Existe algún tipo de mecanismo de transmisión de disparar y olvidar que podría usar de manera segura y efectiva para esto?

Answer 1

Ciertamente hay muchas opciones para esto, pero una que es muy fácil de implementar y cumple con sus criterios es un Llamada de servicio web asíncrono .

Esto no requiere que inicie un subproceso de trabajo (el Framework lo hará detrás de escena). En lugar de utilizar una de las opciones descritas en ese enlace para obtener el resultado, simplemente ignore el resultado, ya que no tiene sentido para la aplicación de llamadas.

Answer 2

Hice algo similar, aunque no exactamente un "braodcast"

Tengo una herramienta interna que utilizan varios no técnicos en la empresa. Le pido que compruebe un recurso compartido de red para un EXE específico (el mismo EXE que descargaría si quisiera usarlo) y compara la versión # de ese archivo con el ensamblaje en ejecución. Si el de la red es más nuevo, alerta al usuario para que descargue el nuevo.

Mucho más simple que intentar configurar un actualizador automático para algo que solo se utilizará en el mismo edificio que yo.

Answer 3

Si la actualización no es un problema (es decir, no hay casos en los que usar la versión anterior sea mejor), puede hacer lo que hice con algo similar:

La aplicación que la gente realmente inicia es un programa de actualización, comprueba la versión del archivo y la marca de tiempo en un recurso compartido de red y, si existe una versión más nueva, la copia en el directorio del programa. Luego ejecuta el programa (ya sea que se haya actualizado o no).

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)

También tengo el programa en sí para verificar si el actualizador necesita actualización (ya que el actualizador no puede actualizarse debido a bloqueos de archivos)

Answer 4

Después de experimentar un poco, he obtenido buenos resultados con Win32 mailslots .

No hay un contenedor administrado oficial, pero las funciones son fáciles de usar a través de PInvoke, como se demuestra en ejemplos como este .

El uso de una ranura de correo de 'dominio' proporciona un verdadero mecanismo de difusión, que permite múltiples escuchas y no requiere un servidor conocido.