Closed andrewlock closed 4 years ago
Howdy! I have a feeling we've hit tooling issues when trying to use this dependency-version-switching scheme in the past (I think we only just got rid of it recently in this package); do we win much by making this change? I've been using this package quite a bit via netstandard2.0
in netcoreapp3.0
projects and haven't noticed any downsides, but it's been fairly simple usage.
Honestly, no, I don't think we get much at all. The extension dependency is pulled up to 3.0 automatically, which theoretically could cause issues in the future but in reality I'm pretty sure it won't in the short term at least.
In the Serilog.AspNetCore package at least (and possibly the M.E.Hosting package) I think we will need to use the dependency switching unfortunately 🙁
I'll close this one for now, send a PR for fixing the deprecated properties, and take a look at the hosting lib 🙂
Cool, thanks for the reply :-)
I've been using/testing/updating the other two packages (hosting and aspnetcore) against 3.0 and all seems to work nicely there, but it would be interesting to hear whether you find more opportunities to improve them 👍
Yeah I spotted that afterwards and it all seems to work fine, so I don't think there's any need to try and bump the dependencies as you say. I probably should have had a look at that before I started updating all my other libraries 😀
Also fixed a couple of deprecated properties in NuGet.
If this is an approach that we want to take, then will need to merge this before incorporating into downstream packages. Technically it's not actually necessary to update this one at all, as apps can roll forward the hosting libraries anyway, but we probably do need to update the ASP.NET Core packages to support the generic host.