.NET Core and ASP.NET Core are expected to release-to-web by the end of June 2016. There have been a few related announcments recently, surrounding the split of the runtime release (end of June) from the tooling release and return to MSBuild (tied to a later Visual Studio release).

This post is just a quick note to clarify what’s happening with Serilog.

What’s in 2.0?

As many of you noticed, we made an early leap into the DNX tooling and related libraries. Version 1.5 of Serilog, the most recent master release, has been sitting stable for quite a while now, while our long-lived dev branch has been tracking .NET Core for the last year, collecting changes and improvements in readiness for the new .NET.

Here’s what we’ve been focusing on in Serilog 2.0.

  • Packaging – the core Serilog package is now a lightweight, low-dependency package with core types like Log, ILogger and LoggerConfiguration; sinks, enrichers, and facilities like `` support have moved out.

  • Portability – much more of Serilog now works across the board; for example, we can support LogContext on all target platforms; there’s no more Serilog.FullNetFx.dll.

  • Usability – a few rough spots in the API, especially concerning logger shut-down & disposal, have been cleaned up.

  • Performance – for example Serilog.Sinks.PeriodicBatching now accepts and enqueues writes without lock contention.

  • Integration – Serilog.Extensions.Logging is a high-fidelity logging provider for ASP.NET Core that gets structured log data from your apps and the platform out to a huge variety of mature and supported sinks of all kinds - databases, log servers, the cloud, rolling files, …

There are plenty more goodies in there. (One of my favourites is this PR which landed support for fixed-length level names. In 2.0 you can use {Level,3:u} in output templates to get output like DBG, INF, WRN and so-on.) When we flick the switch on the final version we’ll publish full release notes.

What do the recent announcements mean for Serilog?

By far the biggest change has been the packaging work. Serilog used to include its own file, console and trace sinks, for example. These now live in their own repositories and packages: Serilog.Sinks.RollingFile lives in here on GitHub for example. This doesn’t just reduce dependency bloat – it’s also an important milestone in scaling out the Serilog project to support growth and community contributions (like this excellent alternative rolling file package which can now stand on an equal footing with the original).

Re-packaging Seriog has meant a lot of grappling with the in-progress tooling. DNX + DNU (soon dotnet) and project.json have brought game-changing improvements for us – especially the package building capabilities that mean a single build can compile (and then test!) for multiple target platforms. The earlier build system we’ve used to emulate this in Serilog 1.5 has been miserable. I’m sad to see project.json go, but happy that the major benefits are being carried through to the final version (even if we’re stuck with XML). I’m not thrilled about going through another round of churn, but I trust the .NET and ASP.NET engineers in their commitment to deliver a fully-baked, high-quality tooling release so however we have to get there – we’ll get there!

Roadmap to 2.0

Anyway, I digress :-) . Here’s how things will go for Serilog:

  1. We’re going all-in on RC2. It’s going to be a close, if not identical, reflection of the RTM runtime, so once it drops the Serilog core and as many sinks as possible will be ported. This also means nailing down the target framework monikers that the packages support, and paring back our declared dependencies to the bare minumum. The Serilog package will move to 2.0.0-rc-* versioning to reflect this.

  2. Serilog 2.0 will RTW as soon as .NET Core does, in June. The Serilog package will drop first (ASAP) followed by the supported sinks in roughly the order of usage.

  3. We’ll continue building/shipping Serilog with the RC2 version and later previews of the project tooling until the Visual Studio release when we can move forwards with it. From RC2, we’ll treat the tooling as if it’s RTM, and make sure Serilog and its sink/enricher/configuration packages work flawlessly with it, as well as the released Visual Studio 2013 and 2015 tools.

The Serilog contributors and community have put in a lot of work to get us to where we are today. Serilog’s the most mature and full-featured logging solution you’ll find on .NET Core, thanks to a huge effort tracking the platform changes to date. When .NET Core hits RTM, Serilog is going to be there, as we’ve always planned! I can’t wait for June.

When should I upgrade?

RC2. We’ve treated RC1 as a “best-effort” target so far, and supporting Serilog 2.0.0-beta-* has focused mostly on unblocking early adopters of the new runtime. From RC2 I’ll personally consider .NET Core a supported platform and pursue any Serilog issues on it as if they’re in an RTM. I think the promise of a .NET Core/ASP.NET Core RTW shortly afterwards will mean a lot of Serilog users and contributors will be moving forwards, so Serilog 2.0.0-rc-* is going with us.

How can I help?

If your favorite Serilog sink isn’t ported to .NET Core yet, or isn’t ready at RTW, please consider how you can chip some effort in – most porting work is a straightforward project file change and recompile. There are a lot of people in the Serilog community ready to help out; the best way to get started is to jump onto Gitter and mention you’re interested in sending a PR.