log 4net: Где разместить объект c LogManger? (используя его в разных проектах решения, каждый из которых имеет отдельный config-файл) - PullRequest
Новая
       41

log 4net: Где разместить объект c LogManger? (используя его в разных проектах решения, каждый из которых имеет отдельный config-файл)

0 голосов
/ 04 марта 2020

До сих пор я не связывался с config-файлами. Итак, что касается этого, я думаю, что мне не хватает некоторых базовых c знаний, чтобы полностью понять, при использовании журнала 4net в первый раз.

Это то, что я уже прочитал:

https://stackify.com/log4net-guide-dotnet-logging

https://csharp.today/log4net-tutorial-great-library-for-logging

log 4net конфигурация с [сборка:]

Допустим, у нас есть три различных типа проектов в решении, к каждому из которых прикреплен журнал 4net:

  • Project MidLevel:. NET Framework 4.6.1 (с использованием LowLevel)
  • Проект LowLevel:. NET Стандарт 2.0
  • Проектное приложение:. NET Framework 4.6.1 (с использованием LowLevel и MidLevel)

1 ) Где именно я должен разместить следующие строки? В каждом классе, куда я хочу войти? 

private static readonly log4net.ILog log 
       = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

2) Мне было интересно, как я могу получить объект stati c выше везде, где я хочу его использовать. Поэтому я добавил класс, подобный следующему, в проект LowLevel, надеясь, что только «использование» может помочь. 

using System;
using System.Collections.Generic;
using System.Text;

using log4net;

namespace LowLevel.NuGet.Log4Net
{
    public class Log4Net
    {
        // Avoiding overhead by logging, reducing use of CPU via static LogManager object.
        private static readonly log4net.ILog _log
            = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

        //
        // Properties
        //

        public static log4net.ILog Log { get => _log; }
    }
}

Но я предлагаю не работать, потому что. NET Стандарт 2.0 проекта не получил собственный конфигурационный файл.

  • Я прав? (Конечно, я тоже проверю это самостоятельно. Но может быть полезно, если вы заранее укажете мне знания, которых мне не хватает в данный момент.)
  • Как можно создать только одну статистику? c Объект LogManager, использующий его в каждом проекте?
  • Будет ли упомянутый объект c LogManger использовать разные файлы конфигурации каждого отдельного проекта? А если нет, то как этого добиться?

Заранее большое спасибо.

1 Ответ

0 голосов
/ 06 марта 2020

Часть 1: LogManager.GetLogger 

private static readonly log4net.ILog log =
   log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

Я действительно не знаю, почему Мэтт предлагает эту мерзость (imho). Да, вы можете просто скопировать и вставить его в каждый класс, из которого вы хотите войти, но отражение медленное .

Несмотря на то, что LogManager должен выдавать вам тот же экземпляр Logger для того же класса рекомендуется , чтобы сделать его статичным c, чтобы избежать вызовов в LogManager. Это должно повысить производительность, особенно если у вас есть классы журналирования, которые создаются очень часто.

В журнале 4net документы (и то, что я сделал бы естественно), альтернативный способ - сделать это следующим образом:

private static readonly ILog log = LogManager.GetLogger(typeof(ClassName));

Недостаток: у вас есть имя класса, поэтому нет простого C & P.

НО Visual Studio изменит его, если вы измените имя класса с помощью функций рефакторинга, и вы сможете определить ярлыки / шаблоны для автоматического заполнения имени класса. Но даже если вы сделаете это вручную, я все равно предпочел бы это, а не отражение.

Для справки: оператор typeof и ссылка на lang: typeof

Часть 2: Конфиг

Не имеет смысла иметь конфигурацию регистрации с библиотеками. Они не будут выполнены "автономно". Вместо этого вы будете использовать пространства имен.

Учитывая, у вас есть библиотеки A и B, с пространствами имен "my.prj.A" и "my.prj.B" и "Основным" приложением "my. prj.App ", тогда у вас будет один конфиг в приложении. Тем не менее, вы все равно можете применять другие параметры / дополнения:

log 4net охватывает дерево наследования конфигурации (как описано в их документах «конфигурация» и «начало работы»). Таким образом, у вас будет всегда логгер root. Это значение по умолчанию или откат, если другие журналы не применяются.

Затем вы можете определить под-регистраторы (мой термин, не уверен, как они их называют), например:

  • logger "my.prj", который будет применяться ко всем регистраторам, созданным из typeof(my.prj.*.SomeClass), если больше не указано c logger. Не имеет смысла? Да, это так - не относится, например, к сторонним библиотекам. Если им случится использовать log 4net, они вернутся к root.

  • logger "my.prj.A" будет применяться ко всем классам из библиотеки A.

  • регистратор "my.prj.B.SomeFeatureNamespace" будет применяться ко всем классам из FeatureNamespace в библиотеке B.

... вы получите суть.

КСТАТИ: Используя ... = LogManager.GetLogger("MySuperSpecialLogger");, вы можете определить одну конфигурацию для «MySuperSpecialLogger», которая пригодится при отладке, потому что вы можете «следить» за некоторыми потоками по классам и легко фильтровать журналы с помощью регистратора. имя или пусть это записать в другой файл и т. д. c.
Или вы можете объединить логин для документации. Например, у вас было бы 3 метода для входа в систему, но вам нужен журнал попыток и успехов / неудач: вы можете создать именованный регистратор для этого и подключить его к своему собственному аппендеру, получить его в 3 реализациях, записать журнал вывод для попыток входа в систему / успеха / неудачи - сделано.

Наличие нет конфигурации с libs также имеет некоторые другие эффекты:

  • , если вы на самом деле их можно использовать повторно, каждое решение может определять для них различные конфигурации регистрации.
  • вы можете отключить регистрацию в проектах модульного тестирования.
  • , если вы (или кто-то еще) используете их в проекте, который использует другую структуру ведения журнала, вы можете иметь возможность вести журнал, но конфигурации могут поступать через фасад или адаптер.
...