Comment spécifier le nom du fichier App.config de ma demande dans WPF?

Question

C'est très frustrant ... Je peux très bien définir le fichier de configuration pour une application Windows Forms. Considérez ceci:

public static void Main(){ 
    AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", @"SharedAppConfig.config"); 
    //do other things 
} 

Cependant, dans une application WPF, cela ne semble pas fonctionner! Si je définis cette valeur, la valeur de la propriété AppDomain.CurrentDomain.SetupInformation.ConfigurationFile est correcte, mais tous les appels à ce fichier de configuration lors du débogage ne donnent aucun résultat. Il existe des paramètres de configuration WCF dans un App.config que j'ai besoin de partager entre les applications, c'est donc ma solution proposée. Est-il possible de définir dynamiquement l'emplacement de mon fichier de configuration dans WPF?

Aide! Merci!

Answer 1

Vous devriez être en mesure de faire quelque chose le long des lignes de:

using System.Configuration; 

public class TryThis 
{ 
    Configuration config = ConfigurationManager.OpenExeConfiguration("C:\PathTo\app.exe"); 

    public static void Main() 
    { 
     // Get something from the config to test. 
     string test = config.AppSettings.Settings["TestSetting"].Value; 

     // Set a value in the config file. 
     config.AppSettings.Settings["TestSetting"].Value = test; 

     // Save the changes to disk. 
     config.Save(ConfigurationSaveMode.Modified); 
    } 
} 

NOTE: Cette tente d'ouvrir un fichier nommé app.exe.config C: \ pathto. Cela EXIGE également qu'un fichier existe sur le même chemin avec le nom "app.exe". Le fichier "app.exe" peut simplement être un fichier vide. Pour votre cas, je ferais presque une bibliothèque "Config.dll" partagée qui gérerait le fichier de configuration.

~ md5sum ~

Answer 2

Est-ce du côté du service ou du côté client? Si du côté du service, il arrive souvent que le service s'exécute dans son propre AppDomain, de sorte que si vous définissez AppDomain.CurrentDomain.SetData (...), il ne s'appliquera pas à la configuration du service. Je ne suis pas entièrement sûr de savoir comment contourner cela, mais vous devriez pouvoir contrôler la configuration du service en mettant en place votre propre ServiceHost.