Práctica recomendada para almacenar configuraciones para un servicio .NET Windows: configuración de propiedades de servicio, serialización,

Question

Estoy trabajando en un servicio .NET Windows donde intento almacenar la configuración que se usará cuando se inicie el servicio y mientras esté corriendo. He buscado a través de publicaciones en SO y descubrí que usar la configuración en las propiedades del proyecto es ideal para utilizar con consola y aplicaciones de winforms. Sin embargo, Google y SO guardan silencio cuando se trata de almacenar estas configuraciones con un servicio de Windows.

¿Alguien sabe si es apropiado usar estas configuraciones en un servicio .NET? Si no, ¿la serialización es mi próxima mejor opción? ¿Alguien ha tenido usos prácticos para la configuración de un servicio y ha descubierto que es mejor usar un método específico?

Answer 1

He tenido problemas con el uso de Settings.settings. Por ejemplo, si necesita realizar cambios en el tiempo de ejecución, puede haber problemas con la configuración anulada por aquellos que se almacenaron inicialmente en el archivo settings.settings en oposición a lo que se muestra se debe almacenar según la aplicación/web .config. En consecuencia, hago que todas las configuraciones proxy de mi servicio web sean "estáticas" en las propiedades y las extraigo manualmente de la aplicación/web.config a través de un método de ayuda y las establezco programáticamente. Esto evita cualquier problema.

Un ejemplo del problema que tuvimos: apunté mi máquina de desarrollo a un servicio web en un servidor de prueba para probar el código que consumió el servicio web. Cuando el código se movió a nuestro servidor de prueba, no se manifestaron problemas, ya que el servidor de prueba todavía apuntaba al mismo servicio web en el mismo servidor de prueba. Sin embargo, cuando movimos la aplicación al servidor de producción y reconfiguramos el web.config para apuntar al servidor de producción, comenzamos a obtener resultados confusos. Nos llevó bastante esfuerzo señalar que, a pesar de que habíamos reconfigurado la aplicación para apuntar a la implementación del servicio web del servidor de producción, todavía se estaba conectando al servicio web en el servidor de prueba. No fue hasta que cambiamos las configuraciones en mi máquina de desarrollo y volví a compilar la aplicación que funcionaba. Además de esto, también notamos que si había problemas de DNS para conectarse al servicio web de producción, en lugar de fallar, se volvía a la configuración original que se especificaba en la configuración. Configuraciones desde que creamos el proxy del servicio web en nuestra aplicación - el generador de proxy realmente los codifica con fuerza. En consecuencia, cuando hubo interrupciones en la red, en lugar de fallas de conexión fácilmente diagnosticadas, simplemente volvieron al servidor de prueba y empezamos a tener problemas de datos incomprensibles. No estoy seguro de si se trata de un problema conocido o si se ha solucionado, pero sin duda es algo que debes tener en cuenta.

En consecuencia, desde entonces, siempre configuré las propiedades del servicio como estáticas y utilicé un método de ayuda para leer las configuraciones correctas del web.config directamente y escritas programáticamente, ya que esto parece eludir el problema.

Puede parecer que el problema que tuve no tiene nada que ver con el suyo porque estaba usando servicios web que no tienen nada que ver con los servicios de Windows, sin embargo, cualquier entorno donde necesite poder cambiar la configuración en el tiempo de ejecución sin tener que recompilar podría verse afectado por este problema, por lo que debe tener en cuenta que si ejecuta en un entorno Dev/Test/Production o cualquier entorno donde necesite que su aplicación se reconfigure en tiempo de ejecución (es decir, sin tener que recompile) para que pueda obtener resultados impredecibles al usar settings.settings. Tener cuidado.

Answer 2

Uso el material Settings.settings para almacenar la configuración de mis servicios y no he tenido problemas. Lo habitual es que la configuración del usuario que se modifique se almacene en su ubicación oscura habitual que debe buscar si quiere editarla manualmente.

Answer 3

No veo ningún motivo para no utilizar la configuración en las propiedades del proyecto como lo haría con una aplicación winForms. Hacemos esto, y funciona bien.

Answer 4

normalmente uso el registro para almacenar información que necesito en mi servicio portuario es decir, etc.

string lsbkey = @"Software\mycompany\adas"; 

RegistryKey adaskey = Registry.LocalMachine.OpenSubKey(lsbkey, false); 

try 
{ 
    object regip = adaskey.GetValue("IP"); 
    object regport = adaskey.GetValue("PORT"); 
    localip = regip.ToString(); 
    localport = int.Parse(regport.ToString()); 
} 
catch (NullReferenceException ne) 
{ 
    localip = null; 
    localport = 0; 
    writelog(@"Aborting Service, IP or PORT doesn't exist in \local machine\software\mycompany\adas : "+ne.Message); 
    status = 0; 

}