Remove unnecessary dependencies

[sungam3r]

I think that these dependencies were added unintentionally due to sample projects that reference the main package.

In fact, only two are enough:

[nblumhardt]

Thanks Ivan! This is #110 - moving this package towards a "batteries included" approach, since the core UseSerilog() functionality is now implemented in the (low dependency) Serilog.Extensions.Hosting package.

It would be interesting to know which features of Serilog.AspNetCore you're using, so that we can evaluate whether this is the optimal factoring. Cheers!

[sungam3r]

Wow! I could not even imagine that it was intended. I highly recommend not including such dependencies. It's like shooting yourself in the foot. With the same success, you can turn on a bunch of other sinks/formatters/appconfigs/etc. in the hope that they will be useful to someone. But in fact, only version conflicts will arise when the consumer uses a package of another major version. These are all spurious dependencies.

The goal is to make the onboarding process smoother.

In this case, you can make a separate package and name it like Serilog.AspNetCore.All but I still would not recommend doing so.

For some consumers, this concern actually turns into problems of versioning dependencies. And the other part simply does not use this "ballast". You have already done sample projects with good examples. No need to mix.

[sungam3r]

It would be interesting to know which features of Serilog.AspNetCore you're using, so that we can evaluate whether this is the optimal factoring.

I use Serilog.Sinks.Kafka for example.

[nblumhardt]

Thanks for the reply!

As you'd know, the Serilog packages are all very fine-grained, for many of the reasons you point out. Unfortunately, something resembling a meta-package is needed if we're going to meet the ease-of-setup expectations set by Microsoft.Extensions.Logging/ASP.NET Core, which includes console and debug logging by default.

I use Serilog.Sinks.Kafka for example.

Sorry, I meant which features from this package? Since the core logging adapters and UseSerilog() are now in Serilog.Extensions.Logging and Serilog.Extensions.Hosting, the only feature actually implemented directly in this package is UseSerilogRequestLogging() - unless you're using that middleware, then Serilog.Extensions.Hosting is possibly the dependency-free package that you're looking for. Let me know! 👍

None of this set in stone, of course! It will be interesting to see whether the batteries-included approach here reduces some of the support around this package, or ends up increasing it. We can definitely re-evaluate and change direction if needed.

[nblumhardt]

We should in any case be able to get rid of these two 👍

[nblumhardt]

Argh, nice catch 😅

[sungam3r]

unless you're using that middleware, then Serilog.Extensions.Hosting is possibly the dependency-free package that you're looking for

When I read this comment, I realized that this is what I needed. But when I opened the source code, I was disappointed. It uses IHostBuilder, but I need IWebHostBuilder. So Serilog.Extensions.Hosting package only integrates logging to Generic Host and the package name can be misleading.

Relates to #126

[nblumhardt]

Ah, thanks for the follow-up. This is a point-in-time issue, I think, since in .NET Core 3.0, startup will be HostBuider-based (with WebHostBuilder deprecated), so generally the IHostBuilder will be the desirable place to configure logging - unless I've misunderstood how these are intended to evolve - does that match your understanding?

[sungam3r]

Yes, but it will be only in netcoreapp3.0 and netstandard2.1. Still need to wait for the release. For netstandard2.0 there is no such unification.

[nblumhardt]

Thanks for the reply. It sounds like there's a bit of a compromise necessary for the time being on netcoreapp2.x 🤔

[nblumhardt]

3.0 is now available, I think that's the way forwards. Cheers!