Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.NET Standard 2.0 support #91

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

megakid
Copy link

@megakid megakid commented Nov 10, 2017

So I have done my best to convert all current adapters etc to the new .NET Standard.

I've decided that a NotSupportedException can be thrown if people try to wire up performance counters in a non-full framework (I have targetted net45 and netstandard2.0). I would appreciate views on this as this is my first wholesale .NET standard upgrade.

Please review and get back to me - happy to tweak etc

@megakid megakid mentioned this pull request Nov 10, 2017
@danzel
Copy link
Contributor

danzel commented Nov 12, 2017

Probably need to fix travis and appveyor :)
I'm taking a look now.

@danzel
Copy link
Contributor

danzel commented Nov 12, 2017

Are the Owin changes backwards compatible?
Looks like Owin.Metrics references Microsoft.AspNetCore.Owin instead of Microsoft.Owin.*

@danzel
Copy link
Contributor

danzel commented Nov 13, 2017

Okay, I've done most of the work getting CI builds going.
First I made everything build on VS2017, then I made it work on appveyor:
https://github.com/danzel/Metrics.NET/tree/netcore
(Feel free to grab my commits)

I've also started on travis, but I haven't managed to get mono + netcore2 to work together.
https://travis-ci.org/danzel/Metrics.NET/builds/301168930 (It is grabbing older libs, not the standard 2.0 versions, so it can't find some things added in 2)
Do we need to support mono going forwards? If so we may need separate csproj files for it.
Otherwise we could swap out the current osx build for a linux dotnet core 2 build instead? (even an osx dotnet core 2 build, linux would be quicker on travis I think)

@megakid
Copy link
Author

megakid commented Nov 14, 2017

Great - there are some breaking changes that can be further discussed. I tried to port the Owin adapter across but it does have breaking changes as it uses the Microsoft.AspNetCore.Owin package as you say. I then realised it would be far simpler introduce a native AspNetCore (Kestrel) adapter. I think we need to split the Adapter test suites out into individual projects for starters. I further step would be to split the Github repos into Metrics.NET being just the core libraries and a new repos for each of the adaptors. This means that they can progress at their own rates as currently a single .sln referencing both VS2017 csproj files as well as older csproj files has some issues.

Ideally we'd have a PR to update the core lib to .net core (which is very simple) separate to each of the adapters.

@danzel
Copy link
Contributor

danzel commented Nov 14, 2017

@PaulParau any thoughts on this?

@danzel
Copy link
Contributor

danzel commented Nov 16, 2017

We could just use https://github.com/AppMetrics/AppMetrics instead

@thiagoloureiro
Copy link

Any news about this one ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants