.NET Core

Question

.NET Core

peske opened this issue 8 years ago · comments

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 #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

Matias Ribichich commented 8 years ago

+1

Blake Niemyjski · Answer 1 · Sat Jun 25 2016 00:07:09 GMT+0800 (China Standard Time)

I'd have one package and use compiler directives!

Daniel · Answer 2 · Thu Jul 14 2016 04:57:15 GMT+0800 (China Standard Time)

@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)

Aleksandar Pesic · Answer 3 · Thu Jul 14 2016 05:09:43 GMT+0800 (China Standard Time)

@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.

Aleksandar Pesic · Answer 4 · Thu Jul 14 2016 05:14:14 GMT+0800 (China Standard Time)

@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

Aleksandar Pesic · Answer 5 · Thu Jul 14 2016 05:20:38 GMT+0800 (China Standard Time)

@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.

Allan Hardy · Answer 6 · Mon Sep 19 2016 16:29:34 GMT+0800 (China Standard Time)

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

Gian Maria · Answer 7 · Wed Aug 16 2017 18:25:45 GMT+0800 (China Standard Time)

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

Gian Maria · Answer 8 · Mon Jan 15 2018 18:41:24 GMT+0800 (China Standard Time)

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.