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?
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:
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.
.. und Pfade programmiert man nicht fest in den Code.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Relative Pfade kann man schon in den Code hereinbauen....absolute natürlich nicht 😉
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... 😄
Gute, externe Plugins greifen auf AppKeys zu.
zB
<app key="HerstellerName:PluginName:KeyName" value="" />
Es gibt keine Notwendigkeit für eigene Config files.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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... 😄
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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 |
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.
@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... 😄
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ß!