Aktuellen Namespace-, Class- und Methode-Namen ermitteln

Unabhängig davon, dass ich keine Lösung weis, da es gegen OOP verstoßen würde ein kleiner Tipp:

Dazu biete ich drei Methoden an, für Warnings, Errors und Messages.

Biete eine Methode an, die einen Status als Enum annimmt (Warning, Errors, Messages).

So vereinfachst du zum einen die Verwendung und zum anderen hast du eine Zentrale Log-Schnittstelle.

Was du intern dann machst bleibt dir überlassen.

@inflames2k:
Vielen Dank für deinen Hinweis, habe diesen gerade umgesetzt. Wie würdest Du denn soetwas realisieren? Ich denke Du störst dich an der static class. Doch ich habe diesen Weg gewählt, da es eine zentrale Stelle geben soll, an der "geschrieben" werden kann.

So vereinfachst du zum einen die Verwendung und zum anderen hast du eine Zentrale Log-Schnittstelle.

Das sehe ich anders:
Das Verhalten einer Methode sollte nicht von einer compiletime-Konstante abhängen - da sind mehrere Methoden IMHO durchaus die elegantere Variante.

Intern können sie ja trotzdem eine Methode aufrufen.

Mein Logger arbeitet auch als Static. - Aber eben mit einem ENUM. Kannst ja mal anschauen. (Siehe Signatur).

Ich biete sogar nur eine Klasse an über die alles passiert (die statisch ist) und intern anhand der Konfiguration Xml-Logfile oder Windows EventLog nutzt. -> Aufrufende Methoden logge ich allerdings nicht.

@winSharp93
Naja, das ist wohl Ansichtssache.

Aber wenn ich sowieso einen Log-Eintrag schreibe, wo sich nur der Typ unterscheidet, kann ich das doch anhand des ENUM machen. - Ist jedenfalls meine Auffassung.

Naja, das ist wohl Ansichtssache.

Ja - durchaus.

Aber wenn ich sowieso einen Log-Eintrag schreibe, wo sich nur der Typ unterscheidet, kann ich das doch anhand des ENUM machen

Die Frage ist jedoch: Was bringt ein Enum für Vorteile im Vergleich zu einer Methode aus Aufrufersicht?
IMHO sind das kaum welche bis gar keine.

Stattdessen wird die Methode komplexer: Ein weiterer Parameter erhöht die Unübersichtlichkeit, muss validiert werden und dann in der Methode erneut geprüft.
Auch aus Aufrufersicht wird die Methode komplexer:

Logger.Log(Severity.Warning, "Person {0} not found", person.Id);
//vs:
Logger.Warning("Person {0} not found", person.Id);

Letzteres Variante ist nicht nur kürzer, es ist auch deutlich besser zu erkennen, was genau geloggt wird.

Zudem ist man besser gewappnet für zukünftige Refactorings: Angenommen, _Error_s sollen zusätzlich um einen optionalen Fehlercode erweitert werden; bei Informationsmeldungen soll dieser jedoch nicht zum Zuge kommen.
In diesem Fall würde es reichen, nur die Error-Methode zu verändern, da sie genau eine Zuständigkeit hat.

Weiteres Beispiel:
Auch im Framework existieren an vielen Stellen verschiedennamige Methoden, die man theoretisch auch zu einer zusammenfassen könnte.
So schreibt man beispielsweise:

s.ToLower(); 
s.ToLowerInvariant();
//und nicht:
s.ToLower(false);
s.ToLower(true);

//oder:
enumerable.OrderBy(p => p.Name);
enumerable.OrderByDescending(p => p.Name);
//Statt:
enumerable.OrderBy(SortOrder.Ascending, p => p.Name);
enumerable.OrderBy(SortOrder.Descending, p => p.Name);

Und nochetwas, wer statische Klassen fürs logging benutzt verwehrt sich einen Umstieg und sollte sich auch mal überlegen etwas zu Architektur zu lesen.

Das benutzen eine IOC Containers ist wirklich nicht schwer und vereinfacht solche sachen echt ungemein.

Naja...wenn man es erst einmal verstanden hat ist es wirklich einfach, aber ggf. dauert es ein bißchen **bis **man es wirklich verstanden hat... 😁 Siehe DI/IoC in der Praxis (und korrekter Aufbau der zugehörigen Klassen)

Mich würde aber sehr interessieren wie Du Logging in Verbindung mit IoC benutzt.
Klar, ich kann mir den Logger injecten lassen, aber dann habe ich ja in **jeder **Klasse die irgendwas loggen muß den ILogger im Konstruktor.