dotnet core support

[rdghickman]

Is there currently any plan for the Metrics.NET library to be made compatible with the dotnet core framework? If not, are you open to any PR that may attempt this?

[niemyjski]

+1

[rdghickman]

Currently I see a bunch of dependencies that are blockers (though these are mostly not for the actual core Metrics code) and a few things in the actual codebase that are not in dotnet core namespaces (Configuration, the MethodImpl.Synchronized attribute, some things in the Environment, etc.). I'm not an expert at porting this stuff but the effort is not completely trivial. There's some question here as to what the project should support going forward (ie. is Mono still relevant if targetting core?). I haven't gotten around to looking at the test code.

[niemyjski]

I'd just target only netstandard and be done with it (it should work everywhere). This site really helps with upgrading packages: http://packagesearch.azurewebsites.net/ More things in environment have been moved around and some will be coming back this fall. If you have any questions, please let me know.

[rdghickman]

I tend to agree about only supporting netstandard. I'll update this thread if I do end up with a working port of this, but I can't commit to it as of right now.

[tsibelman]

I also took a look , it looks the biggest problem is HttpListener that is removed from .net core, it replaced by Kestrel web server. I think it will be much easier to port Metrics if it could be separated into core project and one or more extensions projects. This way it would be possible to move gradually to .net core, also it will provide leaner and cleaner core library. If maintainers see it as a good way forward I can work on PR with my suggested separation.

[niemyjski]

Why would a metrics project have a http listener?

[tsibelman]

It used for pulling metrics data from application, also it used by build in web ui

[tsibelman]

@PaulParau What do you think about my suggestion would you accept such pull request where I separate Metrics into core project and one or more extensions projects?

[PaulParau]

In principle yes, splitting optional parts from the "core" sounds like a good idea. We had thought about separating components such as the Elastic Search and InfluxDB reporters into separate projects. Not only would this improve the maintainability of the entire project but, like you said, it would make it easier to eventually add dotnet core support.

Do you have an idea about what would have to be separated, i.e. what those extension projects would be? I'm asking because some thing are trivially separable (like the reporters I mentioned) while other parts bring value to the core metrics library and separating them should be carefully considered (e.g. metrics visualization, text reports - which are served by the HttpListener).

I'll also discuss this with the other maintainers and get back with a more concrete response :)

[PaulParau]

I've discussed this further with the team: we're OK with removing optional parts (e.g. reporters I mentioned), but we'd rather not remove features like those served by the HttpListener. Without those, the core metrics library would have no built-in reporting support and would need to be used together with another package.

[tsibelman]

In this case HttpListener based implementation need to be rewrite to use Kestrel web server for this purpose. I will take a look into how complex it is.

[mribichich]

+1

[alhardy]

+1

[alhardy]

I've copied across the Metrics.NET core project to my aspnet core integration project and stripped it down so it could be upgraded to dotnet core. Stripped down but it works! What's been removed?

• Remote Metrics related stuff
• HttpReporter (I do still get the /json endpoint using the middleware i've written in aspnet core)
• CSV Reporter
• All the other reporters graphite, influxdb
• Performance counter stuff
• Visualization stuff (Is anyone actually using this? I'm guessing most are pushing to influxdb, graphite or es)
• A few other things commented out around
  - properties on the Environment class
  - I didn't bother with appsettings (Metrics.GlobalContextName, Metrics.CompletelyDisableMetrics)
  - IP Address resolution

There are currently two sample projects in the solution Api.Sample and Mvc.Sample to test it out, metrics are visible at /json or /metrics for each sample respectively.

alhardy/aspnet-metrics@9031ae4

Should we just create a completely new project with dotnet core support and reporters etc broken out to separate projects with this repo?

[PaulParau]

While I agree with removing the evidently non-core stuff (reporters - separating them is actually in progress), I'm a bit concerned about the others (e.g. HttpListener, Visualization - I think it's still useful in certain scenarios).

.NET Core support is not a priority for us now (we're focusing right now on getting the next stable release out the door), but we'll look into it and clarify whether we want to go forward with it and the way we want to do it.

[rudygt]

I worked on this some time ago, I got the basics working on core using nancyfx + kestrel for the self hosting. the ui works.

there is the branch if someone wants to give it a look

https://github.com/rudygt/Metrics.NET/tree/CoreClrPrototype

Regards

[slawomirbrys]

Is anybody working on porting this lib to .Net Core?

[niemyjski]

I'm not sure, I've been trying to gauge when this will be available so I can update our foundatio metrics implementation for this lib (https://github.com/exceptionless/Foundatio#metrics)

[alhardy]

@slawomirbrys @niemyjski I tried by providing a POC. I ended up porting Metrics.NET to App.Metrics. Things slowed down since @etishor unfortunately.

My port is a significant redesign, some functionality is removed to support a .NET Standard library as mentioned in previous comments, however new functionally also exists.

I was using Metrics.NET for years and contributed the OWIN package, unfortunately I was not able to get any guidance or direction on dotnet core and after efforts made to provide a POC it was mentioned that it was not a priority to support dotnet core.

My first attempt to continue with Metrics.NET and dotnet core was implementing https://github.com/alhardy/aspnet-metrics which has a dependency on Metrics.NET, however this limits to the full framework.

[danielmarbach]

it seems HTTPListener is coming back https://github.com/dotnet/corefx/blob/master/src/System.Net.HttpListener/src/System/Net/HttpListener.cs

https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md

Maybe targeting .NET Standard 2.0 will be a good option?

[niemyjski]

I'd remove it, things like that shouldn't be in the core library, it should be an extension. Thanks -Blake Niemyjski

…

On Thu, Apr 6, 2017 at 2:21 AM, Daniel Marbach ***@***.***> wrote: it seems HTTPListener is coming back https://github.com/dotnet/ corefx/blob/master/src/System.Net.HttpListener/src/System/ Net/HttpListener.cs https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/ dogfooding.md Maybe targeting .NET Standard 2.0 will be a good option? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-So_FJJ4YQhwakQ5EpyQ-pHT8Konafks5rtJKJgaJpZM4JGE4d> .

[cocowalla]

@niemyjski I'd have to agree.

Visualisations and an HTTP endpoint are definitely nice to have for some systems, but I certainly don't see them as a core part of a metrics library. I struggle to see any reason not to have these as separate packages.

@PaulParau is there likely to be any movement on this in the near future, or is App.Metrics now the best option where .NET Standard support is required (which would be most greenfield projects, I would think)?

[niemyjski]

@cocowalla you could also check out foundatio :) https://github.com/exceptionless/foundatio#metrics

[cocowalla]

@niemyjski actually, I did have a look yesterday :) But I'm already using Serilog for logging, am using Quartz.net for jobs, have already implemented my own async queue, and have already implemented my own in-memory caching mechanism. The only bit I'm missing is metrics.

Could have saved some time if I'd been aware of foundatio beforehand!

[alkampfergit]

Any news for this issue? Actually we really love Metrics.NET library, but without .NET core support we will need to move to another library.

[niemyjski]

@gian, We have an implementation for Foundatio for this lib but we support others as well (https://github.com/FoundatioFx/Foundatio#metrics) perhaps short term you can move to one of our impls and then move back when it's supported via the abstraction? Thanks -Blake Niemyjski

…

On Wed, Mar 28, 2018 at 2:36 AM, Gian Maria ***@***.***> wrote: Any news for this issue? Actually we really love Metrics.NET library, but without .NET core support we will need to move to another library. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-Soy164RiceJSnhTy0vdeUhSsvcbpCks5tiz1qgaJpZM4JGE4d> .

[alkampfergit]

I'll give it a try. :)

Many thanks.

[alhardy]

@alkampfergit There is also https://www.app-metrics.io/getting-started/ ;)