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: 
The [Serilog sink for SQL Server](https://github.com/serilog/serilog-sinks-mssqlserver) 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.
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.x.x 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.