2010-01-08 8 views
9

Ejecutamos un sistema complejo escrito en C# .NET 3.5, que consta de más de 20 sitios web, más de 10 servicios de Windows y varias tareas programadas y aplicaciones de ayuda.¿La mejor manera de manejar múltiples instancias de archivos de configuración?

Cada uno de éstos se incluye con una o más de nuestra lógica de negocio y el marco de DLL. Estas DLL tienen configuraciones de configuración extensas, y esto se ha convertido en una pesadilla en la que mantenemos más de 40 archivos de configuración para varias instancias de las mismas bibliotecas de clases.

No registramos nuestras DLL en el GAC por varias razones: 1) Nos gusta la flexibilidad de implementar rápidamente cambios en proyectos selectivos sin reconstruir todo el sistema o causar un tiempo de inactividad innecesario. 2) Algunas instancias de las DLL requieren configuraciones ligeramente diferentes; por ejemplo, algunos proyectos usan diferentes cadenas de conexión, direcciones de correo electrónico de notificación, etc.

Experimentamos con los atributos de archivo/configSource de AppSettings en Web.config/App.config, pero solo funcionan con rutas relativas, no entre proyectos. Consideramos guardar los valores predeterminados en machine.config pero esta es una misión, estar demasiado abarrotada y llena de cosas importantes que no están relacionadas con nuestros proyectos.

Nuestra "solución" actual es usar nuestro propio formato de archivo de configuración, que primero busca una configuración en la carpeta "bin" del proyecto actual, y si eso no existe, carga desde una ubicación central codificada. Esto nos permite anular la configuración cuando sea necesario, pero use la configuración predeterminada el resto del tiempo.

En última instancia, lo que queremos es tener las configuraciones predeterminadas de cada biblioteca de clase en una ubicación central, y cada instancia puede tener un archivo de configuración opcional que solo anula las configuraciones que difieren de las predeterminadas.

¿Existe una manera sugerida, estándar de la industria de resolver este problema en .NET?

+3

No puedo decir que tenga experiencia en este tipo de cosas, pero ¿no es esto para lo que sirve el registro? Estoy seguro de que tiene su propio conjunto de problemas, pero ¿se pregunta si debería considerarse una solución? –

+0

¿funcionan todos estos en el mismo servidor? – Amirshk

+0

(descargo de responsabilidad: es algo que escribí): hay un hilo similar en esto: http://stackoverflow.com/questions/1987013/how-to-setup-web-config-for-build-to-multi-environments- without-code-changes/2024921 # 2024921, y escribí acerca de una herramienta que he escrito allí, que también puede ayudarte aquí. FWIW. –

Respuesta

2

Si esto es todo dentro de la misma empresa ¿Por qué no simplemente almacenar las configuraciones en la base de datos? Creo que Enterprise Framework incluso tiene adaptadores que puede enchufar para hacer justamente esto.

Sé que en nuestra empresa, ya que teníamos sitios que se ejecutan en webfarms, almacenaríamos la configuración en el archivo db, y si necesitábamos cambiar algo tendríamos un script db para actualizar la configuración. no es necesario presionar a los sitios, solo tiene que reiniciar el sitio o tocar el archivo web.config para forzar la recarga.

Otra solución que teníamos para otros artículos era utilizar una base de datos que alojara pares de valores clave junto con otros tipos de datos de configuración para poder cambiar fácilmente cosas en nuestros proyectos de formularios de Windows/web que usaban los mismos componentes.

así que supongo que lo que estoy diciendo es si están todos dentro de la misma empresa/esfera de influencia de tal manera que se puede utilizar una base de datos que es fundamental para toda sólo tiene que utilizar el DB ellos.

No contaminan el registro.

+0

+1 - Estaba escribiendo que nuestra empresa hace exactamente eso cuando Joshua publicó su respuesta. Las configuraciones se almacenan como clases serializadas y se pueden almacenar de varias maneras (estación de trabajo + aplicación, aplicación global, etc.). – TrueWill

0

Usaría OpenExeConfiguration (http://msdn.microsoft.com/en-us/library/ms224437.aspx) y haré que cada aplicación/dll abra 2 configuraciones, la primera serían las predeterminadas, la segunda las sobrescrituras.

Se podría mantener los valores por defecto en ese lugar "central", la concesión de acceso de lectura a todas sus aplicaciones a la misma, y ​​tienen las configuraciones locales residen cerca de sus aplicaciones.

0

¿Cómo implementó estos sitios web y aplicaciones, estos módulos en su sistema se ejecutan en la misma máquina y estos módulos invocaron las DLL desde un directorio específico?

Si está en la misma máquina puede usar el archivo de configuración, si en una granja de servidores necesita una base de datos como la mencionada anteriormente por Joshua.

Si solo necesita reemplazar alguna sección de configuración a un archivo de configuración común, primero puede cargar los valores predeterminados de la ubicación central y cargar su configuración específica en cada proyecto y luego modificar el objeto Configuración en el tiempo de ejecución.

+0

Los sitios/aplicaciones se implementan sftp en una carpeta separada para cada proyecto, en el mismo servidor. Pronto tendremos equilibrio de carga con un segundo servidor idéntico con sus propias copias de todas las aplicaciones y configuraciones. Cuando pienso en una granja de servidores, una simple base de datos de clave/valor comienza a sonar bastante bien. – realworldcoder

Cuestiones relacionadas