.NET 3.5 DLL utilizando su propio archivo de configuración

Question

Es necesario disponer de una DLL .NET 3.5 tiene su propio archivo de configuración. Esta DLL podría invocarse desde muchas aplicaciones diferentes, por lo que la información (como las cadenas de conexión) almacenadas en el archivo de configuración debía mantenerse en un archivo de configuración al que la DLL puede hacer referencia. Lo que quiero es que cuando se utiliza el archivo DLL, necesito "cambiar" el archivo de configuración que se utiliza para hacer referencia a la información para que sea el archivo de configuración de DLL. Luego, cuando la DLL se completa con la información de configuración, el switch vuelve a ser el predeterminado. La DLL está escrita usando .NET 3.5. He estado buscando cómo hacer esto y lo que sigo encontrando es cómo combinar la información con el archivo app.config de un exe. En mi caso, no sé cómo se utilizará esta DLL para modificar los archivos app.config de los ejecutables. Esta solución debe ser independiente. Sin embargo, mis clases base utilizadas para crear el archivo DLL (que contienen objetos comerciales) esperan buscar la cadena de conexión y otra información en un archivo de configuración, por eso necesito "cambiar" a mi archivo de configuración DLL en el momento en que se accede y luego lo vuelve a cambiar para no estropear la aplicación exe que llamó a la DLL.

Answer 1

El sistema de configuración de .NET 2.0 y hasta le da capacidades - que, por ejemplo, puede cargar un archivo de configuración específico bajo demanda. Es un poco más trabajo, pero funciona.

Habría que hacer algo como esto:

// set up a exe configuration map - specify the file name of the DLL's config file 
ExeConfigurationFileMap map = new ExeConfigurationFileMap(); 
map.ExeConfigFilename = "ConfigLibrary.config"; 

// now grab the configuration from the ConfigManager 
Configuration cfg = ConfigurationManager 
        .OpenMappedExeConfiguration(map, ConfigurationUserLevel.None); 

// now grab the section you're interested in from the opened config - 
// as a sample, I'm grabbing the <appSettings> section 
AppSettingsSection section = (cfg.GetSection("appSettings") as AppSettingsSection); 

// check for null to be safe, and then get settings from the section 
if(section != null) 
{ 
    string value = section.Settings["Test"].Value; 
} 

También es necesario asegurarse de que la configuración para el archivo DLL de biblioteca de clases se está construyendo y se copia en un lugar donde se puede llegar a ella. En el peor de los casos, debe especificar un archivo de configuración específico y asegurarse de que se copie en el directorio de salida configurando su propiedad "Copiar en el directorio de salida" en la ventana de propiedades de Visual Studio.

También debe consultar la serie de tres partes de Jon Rista sobre la configuración de .NET 2.0 en CodeProject.

• Unraveling the mysteries of .NET 2.0 configuration
• Decoding the mysteries of .NET 2.0 configuration
• Cracking the mysteries of .NET 2.0 configuration

Muy recomendable, bien escrito y muy útil!

Marc

Answer 2

La respuesta más fácil a esto sería poner los valores en el machine.config. De esta forma, todas las aplicaciones que usen el dll podrán acceder a la información a través de las clases de configuración de la aplicación .net. De esta manera, si necesita reemplazar un valor para una aplicación determinada, puede anularlo en el archivo app.config de la aplicación principal.

Answer 3

No se puede utilizar el sistema de configuración integrada en .Net para hacer esto. Está diseñado (como debería ser) para configurar procesos de aplicación, no Dlls individuales. La forma correcta de hacerlo es agregar los ajustes de configuración para el dll en el sistema app.config para cada aplicación ejecutable que "use" (tenga una referencia) ese dll. (O en el machine.config)

• Simplemente, hacer los ajustes accesibles a TODAS applictions que USET que dll se puede lograr poniéndolos en el Machine.config (en C: \ WINDOWS \ Microsoft. NET \ Framework \ v2.0.50727 \ CONFIG para .Net2.0

Si no desea hacerlo de esa manera, entonces usted tendrá que escribir su propio código para abrir, leer y escribir FRM un archivo XML personalizado, (o cualquier formato que elija usar) a extyract esos ajustes.

Answer 4

Generalmente cuando se tiene la configuración a nivel de aplicación, es necesario para generar los ajustes en el nivel de aplicación, y luego filtrarse a través de sus bibliotecas. Agrega algunas líneas más de código a su inicialización para inyectar dependencias, pero esencialmente está tratando de hacer eso de todos modos.

Usted va a ejecutar en forma más problemas que su valor si se intenta incluir un archivo de configuración para sólo el lado dll al lado del otro con cada despliegue de su biblioteca, y que simplemente no tiene mucho sentido semánticamente .

Tome System.Data por ejemplo ... cuando crea una conexión, especifica la cadena de conexión, no crea un archivo de configuración separado para solo la cadena de conexión para desplegar al lado de la biblioteca System.Data. [Y que podría causar un montón de problemas, ya que es probable reside en la GAC ​​en su sistema de todas formas]

Answer 5

sé que este post es un poco viejo, pero yo quería tirar mis 2 centavos de dólar. Mientras en los casos Mayo, estaría de acuerdo en que la aplicación debe proporcionar la configuración, no la DLL. He encontrado una situación en dll mientras que las configuraciones específicas parecen ser más deseables.

Utilizamos la aplicación de programación/tarea Quartz.NET. Desarrollamos una interfaz para crear y supervisar trabajos contra el servidor de Quartz. Una de las mejores cosas de Quartz.NET es que crea sus programas de "trabajo" y los compila en DLL y luego los suelta en la carpeta del servidor Quartz.NET y, a través de la reflexión, Quartz puede comenzar a usar la nueva DLL sin ajustes adicionales al servidor de Quartz ... si no hay información que deba mantenerse en los archivos de configuración.

Con el servidor de Quartz si tiene alguna información de configuración específica que deba mantenerse en un archivo de configuración, debe colocarla en el archivo de configuración de Quartz.NET. Hemos creado varias aplicaciones de "trabajo", cada una con sus propios bits de información de configuración, por lo que ahora nuestro archivo de configuración de Quartz.NET está lleno de todas estas configuraciones no relacionadas. Tener un archivo de configuración específico dll reduciría en gran medida el desorden del servidor Quartz.NET. La única otra opción que veo es agregar todas estas configuraciones individuales en una tabla de DB de configuración, pero para consolidar y mantener el código, para nuestros propósitos, los archivos de configuración individuales son preferibles.

Simplemente tirando eso para pensar.