Я уже писал в статье, что там нужны слишком концептуальные изменения. Одним только пул-реквестом это не решить. Не уверен, что на такие изменения автор пойдёт.
Нет никакого «Serilog для .NET Core»
Согласен. Но Я и не писал, что он есть. Я писал про дизайн Serilog с точки зрения разработчика .NET Core.
Я боюсь, у нас тут с вами фундаментальное разногласие. Я вот считаю, что библиотека Serilog ничего вам не должна.
Это действительно так. Я никому ничего не навязываю. Ничего не требую. Я рассуждаю о дизайте Serilog с точки зрения программиста .NET Core. Разве программисту .NET Core нужно думать о какой-то совместимости? О какой? .NET Core 3.1 с 1.0 если только.
PS: Отличнй ответ на все тикеты в github Serilog )))
Да Я понимаю, что если после добавления Serilog в подсисетму логирвоания .NET Core, присвоить в Log.Logger другой объект, то он не будет никак связан с тем, который будет использоваться подсистемой логирвоания .NET Core. Я думал, что не надо будет об этом писать — это итак очевидно.
Но сразу после интеграции, это именно так, как Я написал. Я это проверил, прежде чем отвечать на Ваш комментарий.
Это не одно и тоже. Вы предлагаете создать несколько логгеров. А потом что с ними делать? Пихать в DI? В подсистеме лоигрования регистрируются не сами логгеры, а их провайдеры.
хочет сохранять совместимость с теми своими пользователями, которые пользуются ей за пределами ASP.NET Core. Это и есть легаси.
Теперь понятно о каком легаси шла речь. Это понятное желание. И, если смотреть на картину в общем, то понятно почему это всё доступно и в .Net Core. Но разработчик .Net Core не виноват, что разрабочику Serilog надо там какое-то легаси поддерживать, поэтому надо дополнительно разбираться где ему предлагают использовать что-то сомнительное и какие оверлоады методов интеграции Serilog надо вызывать, чтобы всё работало норм. Уверен, что если приложить больше желания, то дизайн Serilog для .NET Core мог быть сильно лучше, даже при условии сохранения совместимости для .NET Framework проектов.
Да, всё так. И nuget с этой библиотекой подгружается в проект, как зависимость nuget пакета Serilog.AspNetCore. Принося с собой и глобальный логгер, не смотря на то, что он там не нужен.
Проблема не в том, что Я не смог разобраться как работает Srilog или не справился с его использованием. Я пытаюсь донести, что как разрабочик .NET Core Я не должен видеть и иметь доступ к тому, что мне не следует использовать, но Я могу это использовать и мало того, мне ещё показывают в самом видном месте (в readme.md) как это делать, наводя меня на ложный путь. Вы об этом сами уже несколько раз упомянули — «Не используйте его». Тогда зачем он там нужен, если его не следует использовать? Значит библиотека Serilog для .NET Core должна быть иного содержания — адаптированая для API логирования .Net Core. А вместо этого мы имеем спорным образом прилепленный Serilog. Ещё раз уточню: Я не спорю, что есть технические возможности сделать всё нормально и правильно. Но это должно быть естественно и прозрачно/понятно. А не так, что надо бить по рукам или писать анализаторы кода.
Библиотека Serilog.AspNet.dll использует Serilog.dll. Поэтому в комилирующемся проекте, если используется первая библиотека, то и вторая — тоже. В этом случае доступ к сборке Serilog не ограничить. Если знаете способ — поделитесь.
Вы, кстати, понимаете, почему вброшенный через DI ILogger не равен Log.Logger?
Да, Я упустил тот момент, что это не тот же самый объект. Но вброшенный объект — это обёртка над объектом из Log.Logger, которая всё равно передаёт соощение тому же глобальному логгеру, как Я понял.
Глобальный логгер это ж legacy для обратной совместимости
Если вообще, то — да. Но контекст статьи – это .NET Core. Какое legacy Вы имеете в виду?
Интеграция Serilog с .NET Core в виде библиотеки serilog-aspnetcore появилась для .NET Core 2.0. Легаси тут может быть, наверное, если его писали под .NET Core 1 или Standard того времени. Правда, Я так и не раскопал, как обстояли дела с интеграцией Serilog с этими платформами на тот момент.
Его нигде не нужно использовать.
Опять же. Если самоконтроль — хорошо. Но когда приходится работать с другими людьми, то надо бить по рукам или, как предложил lair, писать статический анализатор кода.
Я брал код из примера, на который есть ссылка с этой же страницы.
К сожадению, многие просто копипастят и не думают.
Затем, что иначе этот функционал недосутпен. А пуш пропертей — это, на мой взгляд, категорически необходимая вещь. Иначе какой толк от Serilog?
Которые мне предлагют сделать разработчики Serilog в примере на главной странице провекта в github.
Ок, Я Вас не так понял.
Я уже писал в статье, что там нужны слишком концептуальные изменения. Одним только пул-реквестом это не решить. Не уверен, что на такие изменения автор пойдёт.
Согласен. Но Я и не писал, что он есть. Я писал про дизайн Serilog с точки зрения разработчика .NET Core.
Это действительно так. Я никому ничего не навязываю. Ничего не требую. Я рассуждаю о дизайте Serilog с точки зрения программиста .NET Core. Разве программисту .NET Core нужно думать о какой-то совместимости? О какой? .NET Core 3.1 с 1.0 если только.
PS: Отличнй ответ на все тикеты в github Serilog )))
Log.Loggerдругой объект, то он не будет никак связан с тем, который будет использоваться подсистемой логирвоания .NET Core. Я думал, что не надо будет об этом писать — это итак очевидно.Но сразу после интеграции, это именно так, как Я написал. Я это проверил, прежде чем отвечать на Ваш комментарий.
Теперь понятно о каком легаси шла речь. Это понятное желание. И, если смотреть на картину в общем, то понятно почему это всё доступно и в .Net Core. Но разработчик .Net Core не виноват, что разрабочику Serilog надо там какое-то легаси поддерживать, поэтому надо дополнительно разбираться где ему предлагают использовать что-то сомнительное и какие оверлоады методов интеграции Serilog надо вызывать, чтобы всё работало норм. Уверен, что если приложить больше желания, то дизайн Serilog для .NET Core мог быть сильно лучше, даже при условии сохранения совместимости для .NET Framework проектов.
Да, всё так. И nuget с этой библиотекой подгружается в проект, как зависимость nuget пакета Serilog.AspNetCore. Принося с собой и глобальный логгер, не смотря на то, что он там не нужен.
Да, пожалуй, Я не совсем правильно выразился. Но думаю, что все (и Вы тоже) меня правильно поняли.
Srilogили не справился с его использованием. Я пытаюсь донести, что как разрабочик .NET Core Я не должен видеть и иметь доступ к тому, что мне не следует использовать, но Я могу это использовать и мало того, мне ещё показывают в самом видном месте (в readme.md) как это делать, наводя меня на ложный путь. Вы об этом сами уже несколько раз упомянули — «Не используйте его». Тогда зачем он там нужен, если его не следует использовать? Значит библиотека Serilog для .NET Core должна быть иного содержания — адаптированая для API логирования .Net Core. А вместо этого мы имеем спорным образом прилепленный Serilog. Ещё раз уточню: Я не спорю, что есть технические возможности сделать всё нормально и правильно. Но это должно быть естественно и прозрачно/понятно. А не так, что надо бить по рукам или писать анализаторы кода.Serilog.AspNet.dllиспользуетSerilog.dll. Поэтому в комилирующемся проекте, если используется первая библиотека, то и вторая — тоже. В этом случае доступ к сборкеSerilogне ограничить. Если знаете способ — поделитесь.Да, Я упустил тот момент, что это не тот же самый объект. Но вброшенный объект — это обёртка над объектом из
Log.Logger, которая всё равно передаёт соощение тому же глобальному логгеру, как Я понял.Мне кажется, что есть пример обращения к Log.Logger в принципе — и этого уже достаточно.
Если вообще, то — да. Но контекст статьи – это .NET Core. Какое legacy Вы имеете в виду?
Интеграция Serilog с .NET Core в виде библиотеки serilog-aspnetcore появилась для .NET Core 2.0. Легаси тут может быть, наверное, если его писали под .NET Core 1 или Standard того времени. Правда, Я так и не раскопал, как обстояли дела с интеграцией Serilog с этими платформами на тот момент.
Опять же. Если самоконтроль — хорошо. Но когда приходится работать с другими людьми, то надо бить по рукам или, как предложил lair, писать статический анализатор кода.