2009-08-05 11 views
5

mam dostępu do konfiguracji mojego zgromadzenia tak:Pierwsze StringCollection z AppSettings przez menedżera konfiguracji

ExeConfigurationFileMap map = new ExeConfigurationFileMap(); 
map.ExeConfigFilename = Assembly.GetExecutingAssembly().Location + ".config"; 
Configuration conf = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None); 
AppSettingsSection appSettings = conf.AppSettings; 

Mój plik .config zawiera sekcję jak ten

<configSections> 
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > 
     <section name="CsDll.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" /> 
    </sectionGroup> 
</configSections> 
<connectionStrings> 
    <add name="CsDll.Properties.Settings.SabreCAD" connectionString="A Connection string." /> 
    <add name="CsDll.Properties.Settings.StpParts" connectionString="Another connection string" /> 
</connectionStrings> 
<applicationSettings> 
     <CsDll.Properties.Settings> 
      <setting name="StpInsertSearchPath" serializeAs="Xml"> 
       <value> 
        <ArrayOfString xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
         <string>A string</string> 
         <string>Another string in the collection</string> 

mogę skutecznie odczytania ciągi połączeń zawierające zmiany, jeśli edytuję plik .config. Wiem, że jestem podłączony do poprawnego pliku. Ale nie mogę znaleźć tej kolekcji ciągów wewnątrz obiektu appSettings. Nie znajduje się w .Settings KeyValueConfigurationCollection. Gdzie znajdę moją kolekcję ciągów?

Odpowiedz

6

Powinieneś uzyskać dostęp do elementów w kolekcji za pomocą tego prostszą składnię

foreach (string s in CsDll.Properties.Settings.Default.StpInsertSearchPath) 
{ 
    Console.WriteLine(s); 
} 

EDIT:

Poniższy kod powinien rade

ExeConfigurationFileMap map = new ExeConfigurationFileMap(); 
map.ExeConfigFilename = Assembly.GetExecutingAssembly().Location + ".config"; 
Configuration conf = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None); 
ConfigurationSectionGroup appSettingsGroup = conf.GetSectionGroup("applicationSettings"); 
ClientSettingsSection clientSettings = (ClientSettingsSection) appSettingsGroup.Sections["CsDll.Properties.Settings"]; 
ConfigurationElement element = clientSettings.Settings.Get("StpInsertSearchPath"); 
string xml = ((SettingElement)element).Value.ValueXml.InnerXml; 
XmlSerializer xs = new XmlSerializer(typeof(string[])); 
string[] strings = (string[])xs.Deserialize(new XmlTextReader(xml, XmlNodeType.Element, null)); 
foreach (string s in strings) 
{ 
    Console.WriteLine(s); 
} 

Nie może być krótsza droga , ale to działa dla mnie.

+0

OK. W ten sposób mogę odczytać tablicę znaków. Ale ciągi pochodzą od domyślnej skompilowanej do złożenia. Muszę mieć możliwość dodawania, usuwania i zmieniania ciągów w tej kolekcji po wdrożeniu zestawu. Plik .Properties.Settings.Default nie przechwytuje zmian w pliku .config. Wystąpił ten sam problem z ciągami połączeń, dopóki nie zacząłem przechodzić przez menedżer konfiguracji ConfigurationManager. –

+0

Prawdopodobnie potrzebujesz dostępu do metody menedżera ConfigurationManager: ConfigurationManager.GetSection ("applicationSettings"); który powinien zwrócić obiekt, dla którego chcesz przeanalizować – jkelley

+0

ConfigurationManager.GetSection ("applicationSettings") zwraca wartość null –

1

Twoje ciągi połączeń znajdują się zwykle we właściwości ConnectionStrings menedżera konfiguracji. Powinieneś być w stanie uzyskać dostęp w znacznie prostszy sposób dzięki jego statycznej metodzie.

string myConnectionString = ConfigurationManager.ConnectionStrings["connectioStringName"]; 

wierzę, należy użyć tagu „AppSettings” zamiast „ApplicationSettings” w pliku .config, aby umożliwić dostęp do ConfigurationManager pośrednictwem właściwości AppSettings.

Nie wiem wystarczająco dużo o tym, w jaki sposób ConfigurationManager działa, aby upewnić się, że rozwiąże to problem, ale zmiana nazwy i usunięcie tej niestandardowej grupy sekcji powinno umożliwić prawidłowe skonfigurowanie AppSettings.

Edit Tak, wydaje się, że nieruchomość AppSettings ConfigurationManager za dostęp do sekcji o nazwie w pliku .config.

2

AppSettings i ConnectionStrings są właściwościami dostępnymi bezpośrednio w menedżerze konfiguracji ConfigurationManager.

Jednak applicationSettings i userSettings, które odpowiadają znanych Settings.settings można edytować w VS ustawień projektanta, nie jest tak łatwo dostać się na. AppSettings to NOT takie samo, jak applicationSettings, które znajduje się w zupełnie innej sekcji używanego pliku konfiguracyjnego.

Należy stosować metodę górniczą powyżej lub wariant dostać na applicationSettings i userSettings. Ponadto, aplikacja zaktualizuje się tylko następnym razem, gdy uruchomisz aplikację, nawet jeśli będziesz w stanie w ogóle do nich pisać w czasie wykonywania.

Na przykład (żłobienia skądinąd - dziękuję):

public static string ReadSetting(string sectionGroupName, string sectionName, string settingName, Configuration config = null) 
    { 
     if (config == null) 
      config = SharedConfigSettings; 
     // Get sectionGroup 
     var sectionGroup = 
      config.GetSectionGroup(sectionGroupName); 

     // Get section 
     var section = 
      (ClientSettingsSection)sectionGroup.Sections.Get(sectionName); 
     // Get setting 
     var setting = section.Settings.Get(settingName); 
     // Read setting value 
     return setting.Value.ValueXml.InnerText; 
    } 

a dla innego przykładu (adaoted z wielu przykładów - dziękuję światu):

///<summary> 
    /// return the applicationSettings section 
    ///</summary> 
    ///<returns></returns> 
    public static ClientSettingsSection GetSettingsSection(ConfigurationSectionGroup group, string clientSectionName) 
    { 
     return (ClientSettingsSection)group.Sections[clientSectionName]; 
    } 


    ///<summary> 
    /// return the section settings collection 
    ///</summary> 
    ///<returns></returns> 
    public static System.Configuration.SettingElementCollection GetSettingsCollection(ClientSettingsSection section) 
    { 
     return section.Settings; 
    } 

    ///<summary> 
    /// return the connectionStrings section collection 
    ///</summary> 
    ///<returns></returns> 
    public static System.Configuration.SettingElementCollection ConnectionStringsCollection() 
    { 
     return ((ClientSettingsSection)SharedConfigSettings.GetSection("connectionStrings")).Settings; 
    } 

    ///<summary> 
    /// A collection of all the UserSettings in a SettingElementCollection 
    ///</summary> 
    ///<returns></returns> 
    public static SettingElementCollection UserSettings() 
    { 
     return 
      GetSettingsCollection(GetSettingsSection(GetSettingsSectionGroup(@"userSettings"), 
                @"MyAssembly.Properties.Settings")); 
    } 

    ///<summary> 
    /// A collection of all the ApplicationSettings in a SettingElementCollection 
    ///</summary> 
    ///<returns></returns> 
    public static SettingElementCollection ApplicationSettings() 
    { 
     return 
      GetSettingsCollection(GetSettingsSection(GetSettingsSectionGroup(@"applicationSettings"), 
                @"MyAssembly.Properties.Settings")); 
    } 

Potem, niestety wciąż muszą radzić sobie z obiektami SettingElement, które znajdują się w zbiorze ustawień w tych sekcjach. Każdy musi mieć deserializację do typu właściwości, chyba że jest to ciąg, np. dla applicationSettings SettingElement (jeden, który nie może być dynamicznie aktualizowanych w czasie pracy):

(ćwicząca)

var y = GetSettingsSection(GetSettingsSectionGroup(@"applicationSettings"), @"MyAssembly.Properties.Settings"); 
var c = (y.Settings.Cast<SettingElement>().FirstOrDefault(s => s.Name == "WellKnownDirectories").Value).ValueXml 
       .InnerXml; // the setting as Xml 
var xs = new XmlSerializer(typeof(string[])); 
var strings = (string[])xs.Deserialize(new XmlTextReader(c, XmlNodeType.Element, null)); 

foreach (string s in strings) 
     { 
      Console.WriteLine(s); 
     } 

nieruchomości w ciąg łatwiej jest (ten przykład jest w zasadzie zbędny z pierwszym powyżej):

var s = (y.Settings.Cast<SettingElement>().FirstOrDefault(s => s.Name == "MyUserSettingName").Value).ValueXml 
       .InnerText 

Wszystkie te przykłady były konfigurowane za pomocą aplikacjiUstawienia. To samo podejście może działać z userSettings z dodatkiem prawdopodobnie niektórych metod zapisu i tak dalej, i musisz śledzić (mniej więcej), które z wielu wielu plików konfiguracyjnych są w grze - main, roaming lub local .

Dlaczego to robię? Ponieważ dwie powiązane aplikacje i wspólna biblioteka klas (lub biblioteki) muszą korzystać z tych samych ustawień, które są własnością jednej z aplikacji, w których ustawienia są zarządzane wizualnie. Czy ktoś rozwiązał to w lepszy sposób?

Dzięki.

2

jeśli jest to StringCollection staramy się wydobyć z ustawieniami

var strings = (StringCollection) Properties.Settings.Default["StpInsertSearchPath"]; 

dokona tyle ze na potrzeby XmlSerializer

Powiązane problemy