Me gustaría actualizar un dll para un proceso de servidor sin detener el servicio. ¿Cómo puedo hacer eso? Un poco como asp.net automáticamente recoge nuevos dlls colocados en la carpeta bin.Actualizar un dll sin detener el servicio
Asp.Net utiliza una técnica llamada shadow copy
Si se copia un archivo DLL actualizada en el subdirectorio bin de una aplicación, el tiempo de ejecución de ASP.NET reconoce que hay nuevo código a ejecutar. Como ASP.NET no puede cambiar el archivo DLL en el dominio de aplicación existente, inicia un nuevo dominio de aplicación. El antiguo dominio de la aplicación está "agotado detenido", es decir, las solicitudes existentes pueden terminar de ejecutarse, y una vez que están terminadas, el AppDomain puede descargar. El nuevo AppDomain comienza con el nuevo código y comienza a tomar todas las nuevas solicitudes.
Normalmente, cuando un dll se carga en un proceso, el proceso bloquea el dll y no puede sobrescribir el archivo en el disco. Sin embargo, AppDomains tiene una característica conocida como Shadow Copy que permite que los ensambles permanezcan desbloqueados y reemplazables en el disco.
El tiempo de ejecución inicializa ASP.NET con Shadow Copy habilitado para el directorio bin. AppDomain copiará cualquier dll que necesite del directorio bin a una ubicación temporal antes de bloquear y cargar el dll en la memoria. Shadow Copy nos permite sobrescribir cualquier dll en el directorio bin durante una actualización sin tener que desconectar la aplicación web.
Eche un vistazo al episodio # 5 de Hibernating Rhinos: http://ayende.com/hibernating-rhinos.aspx – asgerhallas
Los podcasts de Hibernating Rhinos se han movido.Vea esta publicación de Ayende describiendo su nueva ubicación a partir de mayo de 2011: http://ayende.com/blog/4838/hibernating-rhinos-webcasts –
Además de la respuesta de Gulzar:
Si el servicio se está refiriendo simplemente directamente el archivo DLL de que tendrá que volver a diseñar el servicio un poco para utilizar dominios de aplicación y las capacidades de duplicación para tomar ventaja de esta característica.
Hacemos algo como esto donde el servicio es solo un proceso shell/host. Toda la funcionalidad se carga en dominios de aplicaciones separados cuando sea necesario.
Cuando un proceso ha cargado un DLL que no es posible cambiarlo.
IIS no mantiene una DLL cargada en la memoria cuando no se está utilizando (affected by the Cache property) y supongo que lo mismo es el caso de ASP.NET. Si sigues la misma estrategia, también puedes actualizar tus dlls.
Sin embargo, si usa sus dlls, debe tener una forma de indicarle a su servidor que descargue todos sus dlls.
Para que esto suceda, el proceso del servidor debe cargar todo el DLLS utilizando las llamadas a LoadLibrary, de forma que pueda descargarlas cuando reciba una comunicación pidiéndole que lo haga.
La comunicación con el proceso del servidor se puede hacer mediante la creación de un evento con nombre disponible a nivel mundial al que se puede acceder mediante el nuevo programa y que se utiliza para señalar el proceso en curso de una actualización. (También podría pensar en otras variaciones de hacer esto).
¿En qué entorno/idioma está escrito su servicio? Hay una gran diferencia entre Win32 y .NET cuando se trata de una solución para este problema ... – mdb
esta es una aplicación .net. – Matt
Tenga en cuenta que, si bien asp.net parece continuar ejecutándose, la actividad del usuario aún puede interrumpirse y causar la pérdida de trabajo cuando se colocan archivos dll nuevos en la carpeta bin. – StingyJack