En mi tienda, estamos acostumbrados a almacenar cadenas de conexiones en el archivo .config. Pero cuando tuvimos que actualizarlo en varias aplicaciones en la misma máquina, alguien dio la idea de almacenarlo en el registro de Windows.¿Dónde almacenar una cadena de conexión utilizada por muchas aplicaciones en la misma máquina?
¿Es esta una buena idea? ¿Cuáles son las implicaciones (seguridad)?
Estamos almacenando datos comunes en el registro en forma cifrada. modificando Machine.config es una operación muy aterradora. ;) Una desventaja es una seguridad de registro. Y las ventanas de 64 bits pueden hacer que trabajar con el registro sea muy extraño. especialmente en el modo WoW.
También el registro para los administradores es un amigo muy viejo y conocido (copia de seguridad, restauración, importación, exportación, etc. no es una novedad para ellos). en cuanto a machine.config desearía que nunca quisieran tocarlo.
Tal vez podría tener simplemente un componente común (WCF u otro) al que haga referencia para las cadenas de conexión. De esa forma solo tendrías que guardar la cadena en un solo lugar.
No utilizaría el registro de Windows para los ajustes específicos de la aplicación por el estilo, aunque sé que un montón de otras aplicaciones hacer ...
Puede escribir una biblioteca simple que lea la cadena de conexión desde un archivo XML simple y lo devuelve. Presumiblemente, entraría en el GAC. –
se puede almacenar en machine.config. Todos los archivos .config heredarán cualquier cadena de conexión definida en ellos, a menos que se borre explícitamente.
¿Funciona para aplicaciones que no son web? –
sí funciona (si solo necesita acceso de lectura), machine.config es global para dotnet completo, pero ¿qué ocurre si alguien reinstala .net o reemplaza machine.config. (alguien como @Mark ;-)) –
Bueno, con suerte usted tiene el control de su propio servidor. Podría hacer la misma pregunta sobre su propia aplicación. :) –
Acepto el método machine.config. Sin embargo, la manera más fácil de hacerlo sería crear un directorio en algún lugar de su sistema de archivos con un archivo xml cifrado. Use Dpapi por ejemplo y luego simplemente cree una clase común que lea, descifre el archivo y devuelva la cadena de conexión. Recuerde tener un método alternativo para obtener los datos de configuración si alguien borra ese archivo. Como se señaló anteriormente, el machine.config se puede sobrescribir, lo mismo ocurre con este enfoque. Los permisos de directorio se pueden usar para establecer restricciones de lectura y denegar escritura a todos los desarrolladores. Esto debería evitar que se sobrescriba "accidentalmente" y al mismo tiempo garantizar que nadie pueda leer los datos allí (aunque esto es irrelevante sin la clave)
El registro es antiguo y conocido, pero eso no lo convierte en una buena opción. En todo caso, .NET ha intentado por todos los medios alejarse de la dependencia del registro de COM y, en su lugar, permitir las instalaciones de XCOPY. Entonces, en este caso, iría con machine.config. –
XCOPY no funciona en absoluto. _todos los programas_ requerían .net y ¿dónde está XCOPY? .net requiere msi etc. –
XCOPY es una tontería de marketing: no es manejable a través de AD, no se muestra a través de WIA. pensar en los administradores de sistemas. quién debe admitir programas que el usuario puede copiar en cualquier carpeta. –