Блог

Я собирался использовать существующий приемник SQL Server Serilog в Serilog, но я понял, что последние предварительные и стабильные версии не поддерживают ASP.NET Ядро.

Есть ли альтернатива этому приемнику? Что я должен делать? Должен ли я написать новый приемник?

Приемник Serilog для SQL Server зависит от некоторых типов, которых еще нет в .NET Core. Началась работа по рефакторингу приемника и удалению зависимостей, но с тех пор рассматриваемые типы были добавлены в следующую версию .NET Core:

https://github.com/dotnet/corefx/pull/12426

В связи с этим приемник Serilog SQL Server, скорее всего, останется только для .NET Framework до следующего выпуска .NET Core / .NET Standard, после чего поддержка будет быстро добавлена.

Тем временем разумным способом разблокировки было бы написать собственную быструю реализацию ILogEventSink .

Я не могу сказать вам, что вы должны делать, но я могу описать пару вариантов. Поставщик Serilog Sql Server на GitHub был бы лучшим местом, чтобы задать вопрос о том, что они намерены делать.

Serilog действительно находится на платформе .Net Core, как и многие, многие другие основные проекты .Net. Вы правы в том, что на сегодняшний день приемником SQL server является только .Net 4.5. Вы можете:

• Продолжайте разрабатывать свой ASP.Net Основной проект, целевой .Net 4.5 в вашем project json, сборка и развертывание только в ОС Windows, но продолжайте использовать приемник SQL server.

  Многие компании переходят на .Net Core, но ориентированный на .Net 4.x.x, чтобы сохранить 100% совместимость с существующими пакетами, пока в платформе устранены недостатки. Это было жизнеспособным решением для моих крупномасштабных проектов.

• Выберите .Net Core и напишите свой собственный уровень хранилища журналов для управления пользовательским SQL и кодом сброса журнала базы данных.

  Если вы работаете в core, это проще, чем кажется, но требует опыта работы с репозиториями данных и IoC. Любой код, который должен сбрасывать журналы в базу данных, должен иметь какой-то «ILoggingRepository». Однако он дублирует вызовы методов ведения журнала в дополнение к отклонению от интерфейсов ILoggerProvider в Microsoft.Ведение журнала.Абстракции — отказ от гибкости уровней журналов и тому подобного, если только вы не решили перепроектировать свой собственный. Это рабочее решение; Я никогда не говорил, что оно элегантное.

• Напишите свой собственный приемник Serilog.

У меня нет опыта работы с этим, но я видел примеры кода, в которых подробно описывается, как этого добиться. Причина, по которой я никогда не использовал этот вариант, заключается в опасении, что к тому времени, когда я закончу писать свой ужасный приемник базы данных, сообщество с открытым исходным кодом переработает версию Sql Server в полностью совместимую с ядром и независимую от базы данных версию. Это было бы самым трудоемким решением, но также и самым надежным.

Для .Net Core могут быть доступны другие приемники, но если вы ищете конкретно SQL server, то, скорее всего, вы работаете с ограничениями, которые не позволяют использовать приемники MongoDB, поставщиков файлов и тому подобное.

Я предполагаю, что вопрос на самом деле не технический, а скорее философский, тогда я предлагаю не ответ, а рассмотрение:

По моему скромному мнению, Microsoft с ее убийством Silverlight, ориентацией на UWP и «бегством в облака» признала поражение всей своей концепции разработки проприетарного программного обеспечения, поэтому освобождение платформы dotnet — не более чем прощальный подарок для разработчиков, обманутых в своих надеждах.

Сама по себе экосистема dotnet очень многообещающая, но ее будущее имеет мало общего с продуктами Microsoft, как это было раньше. По крайней мере, я надеюсь, как разработчик, который работает с продуктами Microsoft более двадцати лет. Таким образом, библиотеки общей инфраструктуры, которые были ориентированы на конкретные продукты Microsoft (я имею в виду MS SQL Server в данном текущем случае), сейчас умирают.

Следовательно, вывод таков: если у вас уже есть долгосрочный проект, который тесно связан с SQLServer, возможно, лучше приложить некоторые усилия для адаптации вашего текущего решения для ведения журнала, в противном случае лучше поискать какое-либо решение для ведения журнала, не зависящее от MSSQL. Вероятно, оно должно поддерживать разные хранилища через адаптеры или что-то в этом роде.

Попробуйте взглянуть на это, они объявляют поддержку ядра в следующей версии, по крайней мере, это действующий проект.