NLog нет вывода журнала из ссылочного проекта - PullRequest
0 голосов
/ 13 февраля 2019

Я использую NLog 4.5.11 в одном решении Visual Studio 2017.Он имеет файл nlog.config в стартовом проекте, но фактическое требуемое ведение журнала происходит из другого проекта, на который ссылается NLog (но nlog.config не существует).Запуск этого решения работает нормально, журналы NLog создаются там, где я ожидаю.

Второе решение VS использует (ссылки) как стартовый проект, так и тот, что с журналированием.Одним из замечаний по этому проекту является то, что это дополнение к Excel.Когда я запускаю (отлаживаю из VS) это второе решение, я НЕ получаю журналирование NLog, которое должно было быть запущено с помощью кода ссылочных проектов и журналирования NLog.Я не получаю никаких ошибок, исключений или файлов ошибок и т. Д.

Я попытался также установить пакеты NuGet для NLog во второе решение.Я также попытался добавить к нему копию nlog.config.Я посмотрел в директории сборки и там копируются dll и файл конфигурации NLog.Я также попытался включить throwExceptions = "true" и internalLogLevel = "Trace".

Я искал SO и в других местах, но не могу найти решение или даже как его отладить.Все, что когда-либо происходит, просто не выводится, что действительно расстраивает.

NLog.config

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd"
      autoReload="true"
      throwExceptions="true"
      internalLogLevel="Trace" internalLogFile="c:\temp\nlog-internal.log">

  <variable name="appName" value="FSIS" />
  <variable name="logDir" value="c:\temp\Rbnz.Fsis.Logging" />
  <variable name="logDirArchive" value="c:\temp\Archive\Rbnz.Fsis.Logging" />

  <targets async="true">
    <target xsi:type="File"
            name="default"
            layout="${longdate} - ${level:uppercase=true}: ${message}${onexception:${newline}EXCEPTION\: ${exception:format=ToString}}"
            fileName="${logDir}\${shortdate}.log"
            keepFileOpen="false"
            archiveFileName="${logDirArchive}\${shortdate}.{##}.log"
            archiveNumbering="Sequence"
            archiveEvery="Day"
            maxArchiveFiles="30"
    />
  </targets>
  <rules>
    <logger name="*" writeTo="default" minlevel="Debug" />
  </rules>
</nlog>

Использование внутри кода ссылочного проекта:

private static NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger();

и позже, внутри метода:

logger.Info("Start: CompileSeries()");
logger.Info("Done: CompileSeries()");

Я ожидал, что если ведение журнала NLog будет работать для проекта, то включение этого проекта в качестве ссылки в другой проект (в другое решение) вызовет такую ​​же запись в журнал.Очевидно, я ошибаюсь в этом предположении.

1 Ответ

0 голосов
/ 13 февраля 2019

Исходя из того, что вы написали, у вас есть First Solution, который имеет два проекта - стартовый проект, который настраивает объект logger.Это решение имеет второй проект, который ссылается на объект logger запускаемого проекта.Отлично.

Теперь у вас есть второе решение.В этом решении вы просто ссылаетесь на сборку стартового проекта First Solution и второй проект First Solution.У вашего Второго решения есть собственный проект, который пытается получить доступ к logger, предоставляемому ссылочными проектами First Solution.

Эта проблема заключается в том, что ваше Первое решение на самом деле выполняет свой запускаемый проект .Ваше второе решение не выполняет его - оно просто ссылается на него .Следовательно, ваш объект logger не инициализируется должным образом NLog.

Решение (в общем случае) состоит в том, чтобы гарантировать, что ваш logger объект инициализируется в вашем Втором решении так же, как он инициализирован в вашем Первом решении.Если вам нужны более конкретные указания, покажите, как при запуске проекта First Solution инициализирует объект logger, и я смогу помочь вам воспроизвести эту логику во Втором решении.

Ваш вывод о том, что вы не можетелог из другого решения неверный.Все дело в правильной инициализации объекта.

Надеюсь, это поможет.

...