2010-07-29 6 views
10

J'ai plusieurs assemblys .NET qui doivent tous partager des paramètres utilisateur communs, tels que les préférences, les noms d'utilisateur, etc. L'une est une application WPF, une autre est une application console et la troisième est un Office. -dans. Tous ces paramètres sont définis par l'utilisateur.Partage des paramètres entre applications

Seule l'application WPF doit pouvoir modifier les paramètres. Le reste vient de les lire.

Idéalement, j'aimerais utiliser le framework de configuration .NET. Je ne suis pas sûr de savoir comment faire cela. Si j'ajoute des paramètres à l'application WPF, comment les autres applications peuvent-elles trouver le fichier user.config?

Est-il simplement plus facile de créer une bibliothèque de classes et d'utiliser IsolatedFileStorage et de sérialiser mes paramètres?

Un conseil serait grandement apprécié.

Répondre

0

Je vous recommande de créer un service pour fournir et mettre à jour les informations utilisateur et/ou les préférences. Ce sera une meilleure architecture, une solution plus propre et il sera plus facile à entretenir et à étendre.

1

Vous pouvez implémenter votre classe de paramètres personnalisés, en héritant ApplicationSettingsBase. Pour commencer, vous pouvez ajouter le fichier de paramètres utilisateur par défaut à un exemple de projet (clic droit sur le projet ->Properties ->Settings ->This project does not contain a default settings file. Click here to create one.). Ajouter un paramètre scope utilisateur et étudier la structure du fichier Settings.Designer.cs concepteur généré:

namespace ConsoleApplication1.Properties { 


    [global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()] 
    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "11.0.0.0")] 
    internal sealed partial class Settings : global::System.Configuration.ApplicationSettingsBase { 

     private static Settings defaultInstance = ((Settings)(global::System.Configuration.ApplicationSettingsBase.Synchronized(new Settings()))); 

     public static Settings Default { 
      get { 
       return defaultInstance; 
      } 
     } 

     [global::System.Configuration.UserScopedSettingAttribute()] 
     [global::System.Diagnostics.DebuggerNonUserCodeAttribute()] 
     [global::System.Configuration.DefaultSettingValueAttribute("John Doe")] 
     public string Name { 
      get { 
       return ((string)(this["Name"])); 
      } 
      set { 
       this["Name"] = value; 
      } 
     } 
    } 
} 

Dans votre implémentation personnalisée, vous ne serez pas limité aux modificateurs d'accès concepteur généré, afin que vous puissiez implémenter la classe Settings comme interne avec les setters internes, visible uniquement pour les assemblages nécessaires, ou tout ce qui correspond à vos besoins.

Bien sûr, vous pouvez toujours implémenter votre mécanisme de sérialisation/désérialisation personnalisé, mais vous perdrez la fonctionnalité fournie par les méthodes Updgrade, Reload et Reset d'ApplicationSettingsBase. Si vous n'en avez pas besoin, cela pourrait être l'approche plus propre.

Questions connexes