.NET Core

[peske]

I'm not sure if you've considered this so far, but I'm pretty sure that .NET Core version (build) would be very useful improvement. I've analyzed the project with portability analyzer, and it looks that it shouldn't be too hard to do this. Basically there are few things to do:

• Change configuration mechanism: use Microsoft.Extensions.Configuration instead of System.Configuration namespace. I don't believe that anyone will cry for the later one. Nevertheless, it is even possible to keep both mechanisms (to select the appropriate one in conditional compilation).
• Remove System.Diagnostics.PerformanceCounter from core version. It would be especially easy to accomplish if the project is broken down to pieces (as I've suggested in https://github.com/etishor/Metrics.NET/issues/132). For example there can be two modules:
  • Metrics.NET.Core (referring to .NET core, without System.Diagnostics.PerformanceCounter)
  • Metrics.NET.Full (referring to full framework, which would actually extend core version, and contain System.Diagnostics.PerformanceCounter feature).
• Few other changes.

Thanks

[niemyjski]

I'd have one package and use compiler directives!

[danielcrenna]

@peske There is also a .NET Core RC2 port of the original port, to aid in such a port. https://github.com/hq-io/metrics (port port port)

[peske]

@danielcrenna Thanks Daniel! You are the guy who originally created the first .NET port, right? Now you are starting with brand new project? Can you publish there few sentences about why the new project, what is different (better) than in this one, etc. so that others (me) can consider migrating?

I'm bit afraid to move because I still don't know how things will going with the community, especially when it comes to reporter libraries for different platforms (to save metrics in KairosDB, InfluxDB, bluefood, etc.)

Anyway thanks for your effort! I'm looking forward to see what will happen with the new project.

[peske]

@danielcrenna Btw. why RC2? Release version (NETStandard.Library 1.5.0) is out there, and there's already first update NETStandard.Library 1.6.0

[peske]

@niemyjski Sorry for late response! Regarding your suggestion: if some features are conditionally compiled then .NET Core and .NET full versions will not offer the same features / API. It's not good practice to have the same library (with the same name), with different set of features and different API for different platforms - it causes confusion. For this reason it's better to separate these features in a separate library.

Btw. I've did the exact thing you are suggesting - I've created Metrics.NET with conditional compilation, and now I have exactly what I've criticized. But it can be done when you are developing for yourself; not when you want to publish the library to the world.

[mribichich]

+1

[alhardy]

Any plans on starting on the .net core build, happy to help if there's a direction on the approach?

[alkampfergit]

Now that .NET Core 2.0 is out, is any plan to port the library to .NET core?

[alkampfergit]

I do not know if this issue is monitored anymore, I think that the main problem for running in .NET core is the section that expose windows performance counter. That part should be moved in another assembly and the rest of the library probably will compile with .NET standard 2.0 just fine.