Laden...

[log4net] Konfiguration über App.config

Erstellt von Caveman vor 7 Jahren Letzter Beitrag vor 7 Jahren 3.957 Views
Caveman Themenstarter:in
187 Beiträge seit 2009
vor 7 Jahren
[log4net] Konfiguration über App.config

Hallo zusammen,

in einer Klassenbibliothek habe ich ein Logging mittels log4net eingebaut. Da ich zum ersten mal Logging verwende, habe ich das erstmal mit einer Konsolenanwendung und diesem Videotutorial probiert.
In der Konsolenanwendung, die auf meine Bedürfnisse ausgelegt ist, funktioniert das Logging einwandfrei.
Die App.config habe ich dann in mein Klassenbibliotheks-Projekt übernommen und auch den Logger gleich implementiert.
In der Klassenbibliothek funktioniert das Logging jedoch nicht, da der Logger als nicht konfiguriert definiert ist.
Nach stundenlangem Suchen und googeln habe ich das Problem gefunden.
In der AssemblyInfo.cs habe ich folgende Zeile eingefügt:

[assembly: log4net.Config.XmlConfigurator(Watch = true)]

Damit wird offenbar die App.config nicht gefunden. Die App.config und die DLL liegen im gleichen Verzeichnis, einem Unterordner zur Exe.
Gebe ich eine Konfigurationsdatei wie folgt an, dann klappt das Logging

[assembly: log4net.Config.XmlConfigurator(ConfigFile = "E:\\App.config", Watch = true)]

Kann mir jemand bitte die Ursache erklären?
Wie kann ich die Angabe der Konfigurationsdatei im XmlConfigurator vermeiden?

P
1.090 Beiträge seit 2011
vor 7 Jahren

Hi soweit ich weiß wird im Standard in den Ordner der Exe nach der Konfig Datei geschaut. Wenn du einen anderen Ordner Verwendet musst du das Irgendwo angeben.

Meines Erachtens ist es jetzt auch eher unüblich. Konfig Dateien in eine Klassenbibliothek auszulagern.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

W
872 Beiträge seit 2005
vor 7 Jahren

Wenn Du eine Konsole-Anwendung hast, dann ist die Konfiguration in foo.exe.config - nicht in app.config.
Beim Kompilieren wird app.config nach foo.exe.config kopiert. Vielleicht ist da etwas schief gelaufen.
Die Klassenbibliothek sollte keine eigene Konfiguration haben - das sollte alles an einem Platz sein, sonst wird das schnell unübersichtlich und unwartbar.

16.807 Beiträge seit 2008
vor 7 Jahren

.. und Pfade programmiert man nicht fest in den Code.

W
872 Beiträge seit 2005
vor 7 Jahren

Relative Pfade kann man schon in den Code hereinbauen....absolute natürlich nicht 😉

T
461 Beiträge seit 2013
vor 7 Jahren

Die Klassenbibliothek sollte keine eigene Konfiguration haben - das sollte alles an einem Platz sein, sonst wird das schnell unübersichtlich und unwartbar.

Stimt durchaus, nur Ausnahmen bestätigen die Regel. Bei einem PlugIn via DLL ist eine eigene DLL.confg sogar besser (bei einem Fremdprodukt), besonders bei updates..

Ich habe den Titel mal angepasst, so dass Suchende auch etwas damit anfangen können. EDIT: Ich sollte beim Wort "Shift" im Titel das "f" nicht vergessen... 😄

16.807 Beiträge seit 2008
vor 7 Jahren

Gute, externe Plugins greifen auf AppKeys zu.
zB
<app key="HerstellerName:PluginName:KeyName" value="" />

Es gibt keine Notwendigkeit für eigene Config files.

T
461 Beiträge seit 2013
vor 7 Jahren

Hmm, von der Wartbarkeit her ist eine eigene *.config finde ich besser, weil man dann nicht in installierte Produkte herumfudeln muß 😉 und bei passenden Standardwerten keine Änderungen braucht außer Copy/Paste..

Natürlich ist es bei mehreren PlugIns dann schon etwas schwieriger und umständlicher, wenn man je eine config bearbeiten muß.. deren Inhalte zu pflegen sind, das stimmt. Ist aber auch die Frage, was man sinnvollerweise alles in so eine Config steckt.. das größere Änderungen überhaupt notwendig sein müssen..

Ich habe den Titel mal angepasst, so dass Suchende auch etwas damit anfangen können. EDIT: Ich sollte beim Wort "Shift" im Titel das "f" nicht vergessen... 😄

16.807 Beiträge seit 2008
vor 7 Jahren

Die Wartbarkeit bei eigenen Config Files ist sogar deutlich schlechter.
Spätestens, wenn die einzelnen Plugins an unterschiedlichen Stellen liegen und/oder Du mit einer größeren Anzahl zutun hast, wirst Du diese Meinung revidieren.
Auch bei verteilten Systemen macht es alles andere als Spaß Config Files zu suchen.

Plugins sind extern. Du kannst also gar nicht dessen Umfang kennen - sie kommen schließlich nicht von Dir. Dahingehend kann die Frage nach Sinnhaftigkeit und Umfang nicht gestellt werden.
Settings sollten an einer Stelle sein; nicht an 50.

Es kann auch zu Konstellationen kommen, dass Config Settings Deines Plugins im Userscope liegen müssen.
Funktioniert mit einer hard-coded Config passend zur DLL nicht. Der ConfigManager kennt nur den Userscope der Hauptconfig.

2.298 Beiträge seit 2010
vor 7 Jahren

Wie verhält es sich denn mit externen Config's die im ConfigSection-Abschnitt definiert sind?

Verschlüsselung funktioniert in dem Fall, aber werden die denn korrekt in den UserScope übernommen?

Ich meine soetwas:


<configSections>
   <sectionGroup name="external">
       <section name="Authorization" type="System.Configuration.SingleTagSectionHandler" />
       <!-- ... -->
   </sectionGroup>

   <external>
       <Authorization configSource="ConfigFile_Auth.xml" />
   </external>
</configSections>

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

F
10.010 Beiträge seit 2004
vor 7 Jahren

Und gerade bei so std Sachen wie Logging würde ich niemals fest einen Logger in Bibliotheken verwenden.
Genauso wie beim ServiceLocator ( Microsoft.Practices.ServiceLocation.IServiceLocator ) gibt es auch für Logging einen Common.Logging ( https://github.com/net-commons/common-logging )
und entsprechende spezielle Implementierungen.
https://www.nuget.org/packages?q=Common.Logging

Da muss man dann nicht zig verschiedene Logger in Projekte mit einschleppen.

T
461 Beiträge seit 2013
vor 7 Jahren

@Abt, hattest mich ja schon vorher überzeugt 😁 , ich meinte bei weniger aufwendigen Konstellationen, z.Bsp. bei 1 uoder 2 Plugins mit vielleicht einem Konfigurationseintrag.. In so einem Fall wäre es durchaus einfacher/praktischer..

Nur denk ich weiß ich schon auf was du hinaus willst, daß man für solche Sachen immer den gleichen Weg nehmen sollte um sich daran zu gewöhnen und es als Standardvorgehen zu fixieren, weil es, wie du schon sagtest, auch aufwendiger werden kann.

Nur stell ich mir dann immer die Frage, wieso man dann so eine Funktion überhaupt erst zur Verfügung stellt?

Ich habe den Titel mal angepasst, so dass Suchende auch etwas damit anfangen können. EDIT: Ich sollte beim Wort "Shift" im Titel das "f" nicht vergessen... 😄

Caveman Themenstarter:in
187 Beiträge seit 2009
vor 7 Jahren

Hallo,

vielen Dank für die Antworten.
In meinem Fall handelt es sich um ein "Plugin" für die Siemens Software Process Simulate.

Der Logger wird nun über eine relative Pfadangabe gefunden und es wird auch schön alles mitgeloggt.
Mit dem Thema Settings muss ich mich erst noch beschäftigen.
Der User sollte aber keinesfalls selbst in der XML mit einem Editor rumpfuschen. Dafür gibt es einen Dialog für die Einstellungen. Dieser wird in der Regel einmalig aufgerufen. Ich sehe da im Moment noch kein Problem für eine eigene Config-Datei. Aber vielleicht ändert sich das auch noch. Bis es zum Einsatz kommt, vergeht noch rund ein Jahr, denn mit der aktuell eingesetzten Version funktioniert es nicht (fehlende Methoden in der API). Habe also noch viel Zeit zum Ändern und verbessern.

PS: Process Simulate ist auch der Grund dafür, dass ich mich jetzt mit C# beschäftige(n muss)! Macht aber höllisch Spaß!