Migrate to .NET Core RTM #34
Conversation
With the new .NET Core configuration paradigm, the user should be responsible of loading configuration from different sources and passing ColumnOptions. Hence the removal of loading configuration directly from extensions and of configuration classes.
| @@ -0,0 +1,189 @@ | |||
| <?xml version="1.0" encoding="UTF-8" standalone="no"?> | |||
There was a problem hiding this comment.
I don't think we need to include this file here.
There was a problem hiding this comment.
No problem, I can delete it. Was actually copying from the Console sink.
|
Hi, thanks for the PR! Looking good. To make this move, we need to maintain the current functionality under .NET 4.x, so instead of removing all of the Conditional compilation can be controlled with the Where possible, when conditionally compiling features we've tried to keep the public API identical between the core and full framework versions, which seems worthwhile given the future alignment in functionality between these platforms. |
| configuration: Release | ||
| install: | ||
| - ps: mkdir -Force ".\build\" | Out-Null | ||
| - ps: Invoke-WebRequest "https://raw.githubusercontent.com/dotnet/cli/rel/1.0.0/scripts/obtain/dotnet-install.ps1" -OutFile ".\build\installcli.ps1" |
There was a problem hiding this comment.
Probably we want this to be consistent?
Others point to preview2 and specify the exact version.
There was a problem hiding this comment.
I took the Console sink as a guide for it. Which others point to preview2 so I can update it accordingly?
There was a problem hiding this comment.
https://github.com/serilog/serilog-enrichers-thread is a good starting point I think
|
Hi @ninety7, I've merged Serilog 2 support into This should help with the build infrastructure side of these changes. There's no .NET Core support in there however, so still looking forward to progressing with this one! :-) All the best, |
|
I made an upstream merge and started working on conditional compiling but stumbled upon the code that creates the sql table, which uses a lot of System.Data.* classes which are not available on .NET Core. I'll be working on this as I have time to migrate that code into a .NET Core compatible one. |
Merge with upstream and port to .net core
|
This PR is getting a little messy with the changes made on the dev branch. Is it possible to rebase it from the latest dev? Also, @nblumhardt I've been thinking about a staged move to .Net Core, with the first step being to get rid of |
|
@colin-young that sounds like a good way forward 👍 @ninety7 what do you think? |
|
See #53 for getting |
|
Hi guys, any chance this ending up in stable version soon? thanks |
|
Hi all, The System.Data support we need in order to target .NET Core without major breakage just landed upstream: I believe this will be .NET Standard 2.0/.NET Core 1.1. With those features available, this PR should turn into a simple case of conditionally excluding the System.Configuration stuff. Do we want to continue with this PR, or open a fresh one against the new platform definition? I think the latter will be easier, given there's a bit of work involved here just in getting back to parity with (the configuration code on) dev. |
|
I vote for a fresh start... |
Here's my try on moving this sink forward. Let me know what you think!