Usar ConfigurationManager para cargar la configuración desde una ubicación arbitraria

Estoy desarrollando un componente de acceso a datos que se utilizará en un sitio web que contiene una combinación de páginas ASP y ASP.NET clásicas, y necesita una buena forma de administrar sus configuraciones.

Me gustaría usar una sección de ConfigurationSection personalizada, y para las páginas ASP.NET esto funciona muy bien. Pero cuando se llama al componente a través de la interoperabilidad COM desde una página ASP clásica, el componente no se ejecuta en el contexto de una solicitud ASP.NET y, por lo tanto, no tiene conocimiento de web.config.

¿Hay alguna manera de decirle al ConfigurationManager que solo cargue la configuración desde una ruta arbitraria (por ejemplo ..\web.config si mi ensamblado está en la carpeta /bin )? Si hay, entonces estoy pensando que mi componente puede recurrir a eso si el ConfigurationManager.GetSection predeterminado devuelve null para mi sección personalizada.

¡Cualquier otro acercamiento a esto sería bienvenido!

Prueba esto:

 System.Configuration.ConfigurationFileMap fileMap = new ConfigurationFileMap(strConfigPath); //Path to your config file System.Configuration.Configuration configuration = System.Configuration.ConfigurationManager.OpenMappedMachineConfiguration(fileMap); 

Otra solución es anular la ruta predeterminada del archivo de configuración del entorno.

Considero que es la mejor solución para la carga de archivos de configuración no trivial, específicamente la mejor manera de adjuntar archivos de configuración a dll.

 AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", ); 

Ejemplo:

 AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", @"C:\Shared\app.config"); 

Más detalles se pueden encontrar en este blog .

Además, esta otra respuesta tiene una excelente solución, completa con código para actualizar la configuración de la aplicación y un objeto IDisposable para restablecerlo a su estado original. Con esta solución, puede mantener la configuración de la aplicación temporal en contexto:

 using(AppConfig.Change(tempFileName)) { // tempFileName is used for the app config during this context } 

La respuesta de Ishmaeel generalmente funciona, sin embargo, encontré un problema, que es que usar OpenMappedMachineConfiguration parece perder los grupos de secciones heredados de machine.config. Esto significa que puede acceder a sus propias secciones personalizadas (que es todo lo que se desea OP), pero no a las secciones normales del sistema. Por ejemplo, este código no funcionará:

 ConfigurationFileMap fileMap = new ConfigurationFileMap(strConfigPath); Configuration configuration = ConfigurationManager.OpenMappedMachineConfiguration(fileMap); MailSettingsSectionGroup thisMail = configuration.GetSectionGroup("system.net/mailSettings") as MailSettingsSectionGroup; // returns null 

Básicamente, si pone un reloj en la configuration.SectionGroups . SectionGroups, verá que system.net no está registrado como un grupo de secciones, por lo que es prácticamente inaccesible a través de los canales normales.

Hay dos formas en que he encontrado para solucionar esto. El primero, que no me gusta, es volver a implementar los grupos de secciones del sistema copiándolos de machine.config en su propio web.config, por ej.

   

No estoy seguro de que la aplicación web en sí se ejecute correctamente después de eso, pero puede acceder a la sección Grupos correctamente.

La segunda solución es, en cambio, abrir su web.config como una configuración EXE, que probablemente esté más cerca de su función prevista de todos modos:

 ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap() { ExeConfigFilename = strConfigPath }; Configuration configuration = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None); MailSettingsSectionGroup thisMail = configuration.GetSectionGroup("system.net/mailSettings") as MailSettingsSectionGroup; // returns valid object! 

Me atrevo a decir que ninguna de las respuestas proporcionadas aquí, ni la mía ni la de Ishmaeel, están usando estas funciones como pretendían los diseñadores de .NET. Pero, esto parece funcionar para mí.

Además de la respuesta de Ishmaeel, el método OpenMappedMachineConfiguration() siempre devolverá un objeto de Configuration . Entonces, para verificar si se cargó, debe verificar la propiedad HasFile donde verdadero significa que proviene de un archivo.

Proporcioné los valores de configuración a word hosted .nET Compoent de la siguiente manera.

Un componente .NET Class Library que se llama / aloja en MS Word. Para proporcionar valores de configuración a mi componente, creé winword.exe.config en la carpeta C: \ Archivos de progtwig \ Microsoft Office \ OFFICE11. Debería poder leer valores de configuraciones como lo hace en Traditional .NET.

 string sMsg = System.Configuration.ConfigurationManager.AppSettings["WSURL"]; 

Para ASP.NET use WebConfigurationManager:

 var config = WebConfigurationManager.OpenWebConfiguration("~/Sites/" + requestDomain + "/"); (..) config.AppSettings.Settings["xxxx"].Value; 

Utilice el procesamiento XML:

 var appPath = AppDomain.CurrentDomain.BaseDirectory; var configPath = Path.Combine(appPath, baseFileName);; var root = XElement.Load(configPath); // can call root.Elements(...) 

Esto debería funcionar :

 AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", "newAppConfig.config); 

Fuente: https://www.codeproject.com/Articles/616065/Why-Where-and-How-of-NET-Configuration-Files