Multiple app.config Dateien

[Jelly]

Ich blicks grad nicht, weil ich die Logik nicht verstehe.

Zu jedem .NET Projekt kann ich eine app.config Datei erstellen, um gewisse Parameter abzulegen. So hab ich es gemacht mit eine .NET Library, die dann folgende .config File hat, um die Adresse eines Webservices abzulegen:

Device.dll.config

XML-Code:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
            <section name="Device.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
        </sectionGroup>
    </configSections>
    <applicationSettings>
        <Device.Properties.Settings>
            <setting name="Device_OpcWebservice_TOPCService" serializeAs="String">
                <value>http://pa-tpr/CTIOPC/opcservice.asmx</value>
            </setting>
        </Device.Properties.Settings>
    </applicationSettings>
</configuration>

Der Quellcode liest an gegebener Stelle die URL aus, soweit ganz schön.

Jetzt habe ich aber noch weitere .NET Bibliotheken erstellt, alle mit ihren eigenen .config files.

In meinem Winforms Projekt nutze ich nun gerne all diese Bibliotheken, und binde sie lediglich als Referenz in mein Projekt ein. Aber was ist mit den jeweiligen .config Dateien.

Ich würde mir vorstellen, dass jede DLL seine .config Datei beibehält, aber dem ist nicht so. Die Datei Device.dll.config wird z.B. im Winforms Projekt ignoriert.
Wo sind denn nun letztendlich die Konfigurationsparameter abgelegt. Es muss doch irgendwie weiter gewährleistet sein, dass jede DLL seine eigene .config File hat.

[Jürgen Thomas]

Hallo Tom,

meistens geht die Frage umgekehrt: eine gemeinsame config für mehrere Applikationen...

Vorschlag: Mit der Assembly.GetAssembly-Methode und Assembly.Location bekommst Du in jeder beliebigen Klasse den Pfad der DLL und durch Verknüpfung mit ".config" Pfad und Namen der config-Datei. Auf diese kannst Du mit ConfigurationManager.OpenMappedExeConfiguration() zugreifen.

Problem: Das geht erst unter NET 2.0. Für NET 1.1 ist mir kein Weg bekannt; der ConfigurationManager ist einer der Vorzüge eines Wechsels.

Jürgen

[Jelly]

Läuft unter .NET 2.0 (VS2005), das ist nicht das Problem.

Die Device.dll greift auf einen Webservice zu, den ich bequem im VS eingebunden habe. Dieser hat mir die oben gepostete .config Datei angelegt, die nachher auch als device.dll.config im Compileverzeichnis ablegt.

Aber in meinem Endprojekt wird diese .config ignoriert. Und am Quellcode den mir der VS Assistent erstellt hat um auf den Webservice zuzugreifen möchte ich eigentlich nichst ändern, da dies wieder überschrieben wird, sollte sich der Webservice mal ändern.

Mag sein, dass sich nur in Verbindung mit einem Webservice diese Problematik stellt, aber der Grund, dass die Url in einer Konfigurationsdatei abliegen muss, ist weil der Webservice mehrfach auf einem System installiert werden kann, einen pro Projekt.

[Jelly]

OK, ich glaube ich habe ein Workaround gefunden, da ich gerad gemerkt hab, dass die Url Property vom Webservice auch beschreibbar ist. Somit kann ich die Url mit den Reflection Methoden aus einer device.config auslesen und einfach neu setzen. Weil das erst beim Aufruf einer Webmethode passiert, ist der von VS erstellte Code davon nicht betroffen, und darf somit beliebig oft neu generiert werden.

[Elvis]

Du musst sie zusammenfügen, in eine Datei. Das ist ja dann die Config-Datei deiner Appliaktion und dorther kriegen auch alle referenzierten Assemblies ihre Konfigwerte.
Nehmen wir ann ich erzeuge eine App namens "Jelly.Config" und eine Classlib namens "Jelly.Config.ClassLibrary".
Der App gebe ich eine Appsetting namens "SomeAppSetting", der Classlib eine namens "SomeString".
In der Classlib habe ich nur das hier als Code:

Delphi-Quellcode:

uses 
  Jelly.Config.ClassLibrary.Properties;

type
  SomeClass = public static class
  public
    class property SomeString : String 
      read Settings.Default.SomeString;
  end;

Und in der app habe ich das hier:

Delphi-Quellcode:

Console.WriteLine('app setting: {0}', Settings.Default.SomeAppSetting);
Console.WriteLine('lib setting: {0}', SomeClass.SomeString);

Wenn ich jetzt beide Konfigdateien zusammenschiebe...

XML-Code:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
      <section name="Jelly.Config.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
      <section name="Jelly.Config.ClassLibrary.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <Jelly.Config.Properties.Settings>
      <setting name="SomeAppSetting" serializeAs="String">
        <value>Miep!</value>
      </setting>
    </Jelly.Config.Properties.Settings>
    
    <Jelly.Config.ClassLibrary.Properties.Settings>
      <setting name="SomeString" serializeAs="String">
        <value>Hallihallo...</value>
      </setting>
    </Jelly.Config.ClassLibrary.Properties.Settings>
  </applicationSettings>
</configuration>

... bekomme ich den Output:

Code:

app setting: Miep!
lib setting: Hallihallo...

Geht also. ;)

[Jelly]

Danke Robert, mal wieder hast du mich dabei ertappt, dass ich von .NET nun wirklich noch nicht die grosse Ahnung hab :mrgreen:

Aber ist das denn aber wirklich im Sinne des Erfinders. Warum getrennte Dinge (Lib und Applikations Parameter) in einer einzigen Konfigurationsdatei unterbringen. Das bin ich so nicht gewohnt, und bedarf wohl einfach nur einer anderen Denkweise.

Kann man dieses Zusammenführen von mehreren .config Dateien denn irgendwie automatisieren. Im Übrigen überschreibt das VS mir beim Kompilieren der Applikation jedes mal die existierende .config Datei im Debug Verzeichnis :wall:

[Elvis]

Zitat:

Zitat von Jelly

ann man dieses Zusammenführen von mehreren .config Dateien denn irgendwie automatisieren. Im Übrigen überschreibt das VS mir beim Kompilieren der Applikation jedes mal die existierende .config Datei im Debug Verzeichnis :wall:

Du hast doch immer noch die Defaultwerte. ;-)
Wenn du in den Projekteinstellungen deiner Lib unter SomeString nun "Möööp" geschrieben hättest, und danach den Settingskey aus der App.config der Echse entfernst, steht wie Möööp drin.
Ist doch genau das gleiche wie bei allen Settings, egal ob es DataProvider oder sonstwas sind.
IMHO ist das Konfigsystem in .Net sehr genial und das ich zentral für eine App in nur einer Datei alle Settings für alle verwendeten Bibliotheken zur Hand habe finde ich eigentlich ziemlich cool und handlich. :)

[Elvis]

Zitat:

Zitat von Jelly

Kann man dieses Zusammenführen von mehreren .config Dateien denn irgendwie automatisieren. Im Übrigen überschreibt das VS mir beim Kompilieren der Applikation jedes mal die existierende .config Datei im Debug Verzeichnis :wall:

Natürlich macht es das, du solltest ja auch die App.config in deinem Projekt editieren. :mrgreen:

[Jelly]

Zitat:

Zitat von Elvis

Natürlich macht es das, du solltest ja auch die App.config in deinem Projekt editieren. :mrgreen:

:duck:
(Mehr fällt mir dazu nicht ein)