是否有任何SQL Server Serilog接收器来支持.Net Core

Question

I was about to use the existing Serilog's SQL Server sink but I realized that the latest pre-release and stable versions do not support ASP.NET Core.

Is there an alternative to this sink? What am I supposed to do? Should I write a new sink?

Answer 1

I can't tell you what you're supposed do, but I can describe a couple options. The Sql Server Serilog provider on GitHub would be a better place to ask the question of what they intend to do.

Serilog is indeed on the .Net Core train, as many, many other mainstream .Net projects are. You are correct that as of today, the SQL server sink is .Net 4.5 only. You can:

• Continue developing your ASP.Net Core project, target .Net 4.5 in your project json, build and deploy to windows OS only, but carry on using SQL server sink.

  Many companies are migrating to .Net Core but targeting .Net 4.xx in order to keep 100% back compatibility with existing packages while the kinks are ironed out in the framework. This has been a viable solution for my large scale projects.

• Target .Net Core, and write your own logging repository layer to manage custom SQL and database log dumping code.

  If you're in core, this is easier than it sounds, but requires experience with Data Repositories and IoC. Any code that needs to dump logs to the database would have to have some sort of "ILoggingRepository". It does however, duplicate calls to logging methods, in addition to deviation from the ILoggerProvider interfaces in Microsoft.Logging.Abstractions - forgoing the flexibility of log levels and such, unless you decided to re-engineer your own. It's a working solution; I never said it was an elegant one.

• Write your own Serilog sink.

I don't have experience with this one, but I have seen code samples that describe details of how to accomplish this. The reason I never pursued this option is due to a fear that by the time I finished writing my beastly database sink, the open-source community would rework the Sql Server version into a fully core-compliant and database independent version. This would be the most heavy-handed solution, but also the most robust.

There may be other sinks available for .Net Core, but if you're looking for the SQL server one specifically, then you most likely are working with constraints that prevent using MongoDB sinks and file providers and such.

Answer 2

The Serilog sink for SQL Server depends on some types not yet in .NET Core. Work started to refactor the sink and remove the dependencies, but since then, the types in question have been added to the next .NET Core version:

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

Due to this, the Serilog SQL Server sink will most likely remain .NET Framework-only until the next .NET Core/.NET Standard release, after which support will be quick to add.

In the interim, writing a quick implementation of ILogEventSink of your own would be a reasonable way to get unblocked.

Answer 3

I guess the question is not really technical, but rather a philosophical one, then I do not propose an answer, but consideration:

In my humble opinion, Microsoft with its Silverlight killing, UWP orientation and "escape to clouds", admitted defeat of its entire concept of proprietary software development, so liberation of dotnet platform is nothing more than the farewell gift for developers, deceived in their hopes.

By itself, dotnet ecosystem is very promising, but its future has little to do with the Microsoft products, as it was before. At least, I hope as a developer who has been working with Microsoft products more then twenty years. Therefore, common infrastructure libraries that were focused on concrete Microsoft products (I mean MS SQL Server in this current case) are dying now.

Therefore, the conclusion is: if you already have long-term project that tightly coupled with SQLServer, maybe it is better to put some efforts to your current logging solution adaptation, otherwise it is better to look for some logging solution, not dependent on MSSQL. Probably it should support different storages via adapters or something like that.

Try to look at this , they declare Core support in next version, at least this is a live project.