NLog namespace.name из другого класса

Question

В настоящее время у меня есть класс LogWrapper, который инициализирует NLog и отправляет ему Info/Debug/Warning и так далее.

Таким образом, каждый метод в другом классе начинается с

LogWrapper.Informational(string.Format(" {0} starts {1}", MethodBase.GetCurrentMethod().DeclaringType.Name, MethodBase.GetCurrentMethod().Name)); 

Когда в LogWrapper:

private static readonly Logger s_log = LogManager.GetCurrentClassLogger(); 

public static void Informational(string fmt, Exception exception) 
{ 
    s_log.Info("{0} {1}",fmt, exception.ToString()); 
} 

Проблема заключается в том, что с вызовом класса отличается от одного обращающегося журнала журнал обертку всегда показывает namespace.methodname LogWrapper, поэтому создаются бесполезные вызовы MethodBase.

Есть ли способ вызова функции из класса, который является другим классом, фактически обращающимся к NLog?

благодаря

Answer 1

Если вы в основном заинтересованы в использовании вашей NLog обертку, но все еще в состоянии поддерживать callsite информацию, увидеть мой ответ на предыдущий вопрос здесь:

Nlog Callsite is wrong when wrapper is used

Вкратце, вам может использовать метод журнала NLog и передать тип вашей обертки. Затем, если вы используете NLog callsite LayoutRenderer, NLog сможет определить информацию о вызывающем абоненте, не задумываясь о себе.

Таким образом, ваш LogWrapper может иметь метод, как это:

public static void Informational(string fmt, Exception exception) 
{ 
    LogEventInfo le = new LogEventInfo(LogLevel.Info, logger.Name, null, fmt, exception.ToString()); 
    logger.Log(typeof(LogWrapper), le); 
} 

Ключ проходящего типа вашей оболочки (typeof(LogWrapper)) в качестве первого аргумента Logger.Log. NLog использует это значение для перемещения стека вызовов до тех пор, пока не увидит этот тип как DeclaringType текущего MethodInfo. NLog рассматривает этот стек кадров как последний стек стека перед фактическим сайтом, поэтому NLog поднимается на один уровень после его просмотра.

Вы должны знать, что у NLog также есть Exception LayoutRenderer, поэтому вам не нужно использовать exception.ToString() самостоятельно.

В то время как вопрос, связанный с Даниэлем Хильгартом в его комментарии, содержит интересный код, я думаю, что вы должны быть очень осторожны с добавлением кучи кода для определения информации, которую NLog может получить для вас за «свободный». Если вам это нужно только для ведения журналов, я бы рекомендовал, чтобы NLog определил его для вас. Если вам нужна какая-то другая цель, у вас, вероятно, нет другого выбора, кроме как разобраться в себе.

На стороне записки, я также рекомендовал бы не сделать свое протоколирование вызовов с использованием этого стиля:

LogWrapper.Informational(string.Format(" {0} starts {1}", 
    MethodBase.GetCurrentMethod().DeclaringType.Name, MethodBase.GetCurrentMethod().Name)); 

Если LogWrapper.Informational делегатов метода вплоть до logger.info NLog, тогда вы делаете некоторую дополнительную работу в случае, если ведение журнала не включено или уровень ведения журнала меньше Info (например, Warn, Error, Fatal). Если из-за текущих параметров уровня ведения журнала инструкция фактически не будет регистрироваться, вы все равно форматируете строку, и вы делаете два относительно дорогих звонка, чтобы получить информацию о вызывающем абоненте.