App.config bei Klassenbibliotheken

Question

Hallo zusammen,

gibt es eine Möglichkeit, in einem Projekt vom Typ Klassenbibliothek eine App.config zu hinterlegen? (Tracing/Logging) der Trace-Klassen sollte verwendet werden können.

Answer 1

Hallo,

 

per Default gibt es pro .exe (bzw. pro AppDomain) nur eine App.config. Daher muss man leider die speziellen config - settings immer in alle app.config's kopieren.

Ich kenne das Problem, da ich log4.net einsetze und auch immer diese Dinge kopieren musste. Der einfachste Ausweg für ein separates .config File ist sich eine eigene Klasse zu schreiben. Diese funktioniert analog zum ConfigurationManager, kann aber gefüttert werden mit einem eigenen config - file. Ein Beispiel für eine solche Klasse kannst du dir hier: -> AssemblySettings.cs ansehen.

Es gäbe da noch die alternative mittels pre-build conditions und skripting die app.config sich jedesmal aus verschiednen Files zu bauen. Ist aber sehr aufwendig und man kann viel falsch machen.

Answer 2

Bei log4net kann man sich behelfen, in dem man z.B. die app.config bzw. eine log4net.config in einem fest definierten Pfad hinterlegt und die Konfiguration über .Configure(..) lädt:

 

FileInfo configfile = new FileInfo(...);
log4net.Config.XmlConfigurator.Configure(configfile);

Möglicherweise lassen sich hier auch relative Pfade definieren, so dass es etwas flexibler wird.

Bei "normalen" App.config Dateien frage ich mich, ob man diese sinnvoll im Zusammenhang mit DLLs nutzen kann? Weshalb werden die denn nicht erkannt, wenn man ein Klassenbibliotheksprojekt macht und zusammen mit der DLL eine app.config ausliefert? Da haben sich die Macher des Frameworks sicher was gedacht, an das ich momentan nicht denke bzw. was ich momentan nicht verstehe.

 

Answer 3

Ja, warum bringt es nichts eine app.config in einem .dll - Projekt zu haben? Bzw. wie du es ausdrückst "Sie wird nicht erkannt".

Kann ich dir echt auch nicht sagen. Als ich vor 4 Jahren mit .NET begonnen habe, dachte ich auch bei meinem ersten Libraryprojekt, da fügst du eine app.config hinzu, und schwupps wird die immer benutzt. Musste aber lernen, dass das nix bringt.

Ich mache es heute so in meine Library - Projekten:

1. Ich füge eine app.config hinzu

2. Sofort umbennen auf MeineLibrary.config

3. Als Ressource kennzeichnen (Dann wird sie mitkopiert beim kompilieren)

4. Meine eigene "Konfigurations - Lader - Klasse" in der Library benutzen

Die Auslieferungsdatei (sprich das .zip) enthält dann sowohl die .dll wie auch die entsprechende .config

 

Ansonsten muss halt der ersteller der des .exe - Projekts in seiner App.config immer die Einträge für die .dll reinkopieren. Mach ich zwar mittlerweile für Log4net. Bin zu faul eine zentrale Log4Net.config - Datei zu führen. Und dann noch im Code wie oben beschrieben das File separat zu laden.

 

Gut mir fällt da höchstens folgende Begründung ein:

In Java projekten, hatte über die Jahre die Menge an Konfigurationsdateien für die ganzen Bibliotheken eine gigantische Menge erreicht. Selbst beim simplesten Projekt, musste man plötzlich 2 - 5 verschiedene Konfigurationsdateien pflegen. Und das für ein paar wenige Einträge. Ganz schlimm war es bei den J2EE - Containern. Da musste man fast schon Konfigurations - Dateien - Spezialist sein.

Nun haben sich die Leute bei Microsoft wohl gedacht: "Wollen wir nicht diese Verzettelung." Es gibt nur ein Konfigurationsfile dass geladen wird. Muss in einem exe - projekt enthalten sein. Alle Einträge werden nur darin geführt.

Kann auch nur spekulieren.Es ist, wie es ist.

 

Happy Coding

 

Thomas

 

Answer 4

Hallo SP,

mehrere Möglichkeiten:

a) Jede Lib behält ihre Einstellungen in ihrer app.config.
    Man nimmt ganz normal die typsicheren Anwendungs-Einstellungen (Properties/Einstellungen) einer Klassenbibliothek.
    Setzt diese im Einstellungen-Designer rechts oben auf "public".
    Zugriff dann in der Haupt-Applikation (die die Lib einbindet) zum Beispiel über:

 var Props = WinLib1.Properties.Settings.Default;
 MessageBox.Show(Props.Zahl.ToString());

b) Alles in einer app.config
    Man kopiert im Prinzip einfach die Einstellungen aus der "app.config" der Lib in die "app.config" der Haupt-App.
    Oft ist hier die Reihenfolge noch wichtig (configSections oben ...).
    Zugriff dann wie oben.


c) Loose Kopplung über MEF (oder andere IoC Frameworks):
    Hier schafft man Unabhängigkeit vom Log-Framework, benutzt zum Beispiel Interfaces,
    und MEF bindet dann zur Laufzeit an den Logger, der (zum Beispiel in der config steht) oder der
    in einer DLL eines gewünschten Verzeichnisses steht, die das Interface exportiert (sehr flexibel)

d) [Edit] Enterprise Library 5.0 - Logging Application Block
            [Webcast: Enterprise Library im .NET Framework (Teil 5-7) - Logging Application Block | MSDN Online]
            

Dies nur mal die Haupt-Möglichkeiten ...   
________________
 
Es schadet sicher auch nicht, ein paar weitere Dinge im Hinterkopf zu behalten:

[Typsichere Anwendungs-Einstellungen in app.config schreiben]
http://dzaebel.net/ApplicationSettingsWrite.htm

[Typsichere Settings mit eigenen Array-Typen]
http://dzaebel.net/SettingsExample2.htm

[C# Globale Projekt-Einstellungen verwalten in C#]
http://www.eggheadcafe.com/software/aspnet/33117060/c-globale-projekteinstellungen-verwalten.aspx

---

ciao Frank

Answer 5

Hallo SPDeveloperXP,

Gibt es eine Möglichkeit, in einem Projekt vom Typ Klassenbibliothek eine App.config zu hinterlegen? (Tracing/Logging) der Trace-Klassen sollte verwendet werden können.

Wie Du weißt, kann man Tracelisteners entweder im Code erstellen oder aber über die App.config konfigurieren. Ich möchte Dir eine Zwitterlösung vorstellen: Du erstellst die Trace-Objekte im Code deiner Klassenbibliothek und initialisierst sie anhand von Benutzer-Einstellungen aus der App.config der Library:

using System;
using System.Diagnostics;

namespace ClassLibrary1
{
 public class Class1
 {
 public Class1()
 {
 TraceSource traceSource = new TraceSource(Properties.Settings.Default.TraceSource);
 TextWriterTraceListener textWriterTraceListener = new TextWriterTraceListener(Properties.Settings.Default.TraceLogFile);
 traceSource.Switch = new SourceSwitch(Properties.Settings.Default.Switch);
 traceSource.Switch.Level = Properties.Settings.Default.SwitchLevel;
 traceSource.Listeners.Add(textWriterTraceListener);
 Trace.AutoFlush = true;
 traceSource.TraceEvent(TraceEventType.Information, 0, "Class1-Konstruktor aufgerufen.");
 }
 }
}

Wenn Du nun, wie Frank das vorgeschlagen hat, den Zugriffsmodifizierer im Settings-Designer der Klassenbibliothek auf "public" setzt, kannst Du die Standardeinstellungen für die Klassenbibliothek zur Laufzeit aus der Hauptanwendung ändern:

private void Form1_Load(object sender, EventArgs e)
{
 ClassLibrary1.Properties.Settings.Default.TraceLogFile = Path.Combine(Application.StartupPath, "MeinLog.txt");
 ClassLibrary1.Properties.Settings.Default.SwitchLevel = System.Diagnostics.SourceLevels.Information;
 ClassLibrary1.Properties.Settings.Default.Save();
 ClassLibrary1.Class1 c1 = new ClassLibrary1.Class1();
}

So hast Du die Möglichkeit, alle Parameter, die Dein Klassenbibliothek-Listener erwartet, dynamisch zu setzen.

Gruss
Marcel