search

getsentry / raven-csharp

Superseded by: https://github.com/getsentry/sentry-dotnet
BSD 3-Clause "New" or "Revised" License
231 stars 121 forks source link

Add support for .NET Core #125

Closed polarina closed 6 years ago

polarina commented 8 years ago

Hi,

Is it possible to get the ability to use this library with .NET Core?

Thanks in advance!

asbjornu commented 7 years ago

@phenixdotnet:

.NET 3.5, WP8 / Silverlight support are deprecated by MS,. .NET standard doesn't support it

I've (thankfully) never touched WP8 or Silverlight in my life, but .NET 3.5 has proven useful to a number of consumers of this library, so that's something I hope we can keep around.

The .Core part could be build only for .NET Standard, it will be compatible with all .NET version

Which .Core part are you thinking of? I'm thinking that SharpRaven.Core should be built for all desired targets (.NET Core / Standard, .NET Framework 3.5, 4.0, 4.5 and 4.6) and included in the package for the specific web framework (AspNet, AspNetCore and Nancy).

Regarding the @LordMike's ideas seem good also but as a user I don't want to have to inject all those dependencies, I want the lib to do it for me at startup if I don't provide my own implementation.

Yes, that's the idea behind the AspNet, AspNetCore and Nancy packages; they will integrate everything for you out of the box. The only thing you should have to provide is the DSN.

phenixdotnet commented 7 years ago

@asbjornu

Which .Core part are you thinking of? I'm thinking that SharpRaven.Core should be built for all desired targets (.NET Core / Standard, .NET Framework 3.5, 4.0, 4.5 and 4.6) and included in the package for the specific web framework (AspNet, AspNetCore and Nancy).

I was talking about SharpRaven.Core package. Again netstandard target is compatible with .NET framework (except 3.5), it is build for this purpose. You can build the SharpRaven.Core package for netstandardand use it in .NET Framework 4.5 project for example.

ricardoalcantara commented 7 years ago

@asbjornu

Another option might be you leaving the old package SharpRaven 2.2.x targeting just NET 3.5, Rename it to something like Legacy and just provide fixes if needed. Then move to netstandard and target it from 4.5 ahead.

So you will wind up with two projects, but the legacy will exist just to fill that gap/problem of whom doesn't or can't migrate to at least .NET 4.5.

Deprecated

Assembly Description Targets
SharpRaven.Legacy The Core Legacy project .NET 3.5
SharpRaven.Legacy.Nancy As is .NET 3.5
SharpRaven.Legacy.AspNet Without touch .NET 3.5

Current (based on what you did before)

Assembly Description Targets
SharpRaven The Core Project .NET Core, .NET 4.5 +
SharpRaven.Nancy As is, basically. Adjusted for the refactored SharpRaven.Core. .NET Core, .NET 4.5+
SharpRaven.AspNet Contains whatever we need to integrate SharpRaven.Core into System.Web.* (ASP.NET) and other legacy .NET Framework .NET 4.5+
SharpRaven.AspNetCore Integrates SharpRaven.Core into ASP.NET Core .NET Core

It is just a suggestion based on what was told about netstandard not been compatible with NET 3.5 and I don't know yet if it's possible to target multiple frameworks like we could do with the old netcore versions. 

...
"frameworks": {
    "net20": {
      "frameworkAssemblies": {
        "System.Xml": {
          "type": "build"
        }
      }
    },
    "net40": {
      "frameworkAssemblies": {
        "System.Xml": {
          "type": "build"
        }
      }
    },
    "net451": {
      "frameworkAssemblies": {
        "System.Net.Http": {
          "type": "build"
        },
        "System.Xml": {
          "type": "build"
        }
      }
    },
    ...

I also coundn't test it yet because I don't have access to a VS on my work time.

phenixdotnet commented 7 years ago

@ricardoalcantara you can still target multiple framework with the new csproj format in VS 2017. you can have a sample in my PR: https://github.com/getsentry/raven-csharp/pull/168/files#diff-aa1376b7cbbc10abfd987d0b9c66d45d In short: <TargetFrameworks>netstandard1.6;net46;net45;net40;net35</TargetFrameworks>

ricardoalcantara commented 7 years ago

@phenixdotnet it's nice, based on that I searched for documentation.

So I believe that we can work with Preprocessor Directives and target NET 3.5 as well. Do you think it will be a huge effort?

ricardoalcantara commented 7 years ago

@phenixdotnet I have just found your pull request, you have done all that already.

phenixdotnet commented 7 years ago

@phenixdotnet I have just found your pull request, you have done all that already.

yep :)

But what I understand from @asbjornu is he want a new clean lib dedicated to .NET Core and recent .NET Framework. Using pre-processor directives can be a solution but it include complexity for a deprecated framework. Guys at NLog do this and IMO the code is now very complex. If targeting .NET 3.5 must be a first class citizen, using pre-processor directives is ok, otherwise I suggest to split project in 2 lib.

ricardoalcantara commented 7 years ago

@phenixdotnet I like the idea of splitting the lib too, like I suggest on those tables I made. I also tried to port this code and it became a really complex code in my POV.

wakawaka54 commented 7 years ago

It seems like we want to maintain the Core library with Net35 support. I can understand this and basically don't mind putting 75% of the code in the Core library under a Net35 directive so that we can pretty much have a clean slate for .Net Core implementations and future implementations. @phenixdotnet @ricardoalcantara it sounds like they do want to maintain Net35 support. Either way I don't really mind, I use this library exstensive right now and there are a lot of things about it that bug me in their current state and I just want to fix them without having to deal with all these difficulties. Last time I checked, there are about 11,000 users on the .Net Core port so it's starting to be significant and I think we could get a lot more people using it if we do a solid implementation. Anyways, I'll look into working on this major revision in sometime later on this week. I would like to leave this repo in a state as @asbjornu described. That would be ideal.

wakawaka54 commented 7 years ago

Haha especially considering that anyone trying to use this library for .NET Core has to stumble onto this post to know how to set it up.

ricardoalcantara commented 7 years ago

@wakawaka54 It's not really important for me to maintain .NET 3.5 specifically, but @asbjornu said it is important, I believe he has a point. I currently use my tine little version of this lib, but I rather have the official one. I am just waiting someone to merge the first branch so I can make a fork and help with something.

wakawaka54 commented 7 years ago

@ricardoalcantara yeah I not sure if I can make a branch on this repo but I branched and added a "major/netstandard" branch to my forked repo. Link to Repo I will try to work out of this branch for now. I can grant whomever permissions to push directly into the branch I think.

ricardoalcantara commented 7 years ago

@phenixdotnet has done the same thing, and he has already a pull request running. So to avoid rework and other conflicts I prefer to wait until someone has passed and merged with the official repo.

asbjornu commented 7 years ago

@ricardoalcantara:

Another option might be you leaving the old package SharpRaven 2.2.x targeting just NET 3.5

I would like to avoid that, if possible. I haven't investigate it deeply, but I don't really understand what a SharpRaven.Core package we create might need that won't be simultaneously compatible with .NET Core and .NET 3.5. The language is C# and the simple types in System.* have the same signature, no? Besides that, I don't know anything such a core library should need.

As mentioned, everything requiring System.Configuration and System.Web should be moved out of the core. Please point out specifics we are dependent on or have to depend on that is impossible to make compatible with .NET Core and .NET 3.5 simultaneously, because I don't understand what it might be.

ricardoalcantara commented 7 years ago

@asbjornu Sorry, I may have lost the notification from this last message, I am going to check what are not compatible between the NETCore and NET 3.5.

ricardoalcantara commented 7 years ago

@asbjornu I took sometime just to analyse, not to actually migrate, I left it to the next step. I think for a core version of the lib we will have to change a few things like:

I believe that this project might be organized like this

it's just an exempla of something I have briefly thought:

asbjornu commented 7 years ago

@ricardoalcantara: Excellent analysis.

  • Remove the reference to System.Configuration and the Configuration.cs file; (Not compatible with netcore)

👍

  • Remove the reference to System.Security.Principal and the Data/SentryUser.cs and the Data/SentryUserFactory.cs

👍

Both uses IPrincipal (I do believe that both classes are just used for the web version, aren't they?);

Indeed.

  • Change Change HttpWebRequest To HttpClient - (I am not sure if HttpClient works on top net35, if not we might have to #IF it

Already begun in the feature/httpclient branch. HttpClient does not exist on .NET 3.5, so I'm trying to #if my way to success, but found it horrible to do with bare MSBuild, so I've rebased the feature/cake-build branch on top of feature/httpclient so we get a much more sane and simplified build structure. I'm nearly done; it's just some assembly and solution configurations plus #if-ing left to do.

  • Add System.Diagnostics.StackTrace for netcore version

👍

  • Remove everything that Uses HttpContext; (Will be moved out of the core lib)

👍

  • I don't know what it does, so I couldn't find any alternative to it: 
    if (exception.TargetSite != null)
       {
           // ReSharper disable ConditionIsAlwaysTrueOrFalse => not for dynamic types.
           Culprit = String.Format("{0} in {1}",
                                   ((exception.TargetSite.ReflectedType == null)
                                       ? "<dynamic type>"
                                       : exception.TargetSite.ReflectedType.FullName),
                                   exception.TargetSite.Name);
           // ReSharper restore ConditionIsAlwaysTrueOrFalse
       }

I think this code is for special handling of dynamic, which (at least in some circumstances) won't have a ReflectedType, thus falling back to the string <dynamic type> instead of ReflectedType.FullName. No idea how this can be handled in .NET Core.

I believe that this project might be organized like this

it's just an exempla of something I have briefly thought:

  • Solution.sln
    • SharpRaven.Core (NetCore, Net35, Net45+)
    • SharpRaven.(SomeName) (Net35+)
      • Here we can place the Configuration.cs and other things that run just on Net35+
    • SharpRaven.(SomeOtherName) (NetCore)
      • Here we can place the NetCore AppSettings Files
    • SharpRaven.AspNET (Net35+)
      • HttpContext, IPrincipal,...
    • SharpRaven.AspNETCore (Net)
      • Microsoft IoC, Microsoft Logger, Extensions for startup configurations
    • SharpRaven.Nancy - I don't know much about this framework to say something useful

I think it looks good, but I'm not sure we need the assembly split between .NET Core and .NET 3.5. If we can get away with #if inside the SharpRaven.Core assembly, I think that would be preferable. Otherwise I agree with everything else you've suggested. 😄

ricardoalcantara commented 7 years ago

Already begun in the feature/httpclient branch. HttpClient does not exist on .NET 3.5, so I'm trying to #if my way to success, but found it horrible to do with bare MSBuild, so I've rebased the feature/cake-build branch on top of feature/httpclient so we get a much more sane and simplified build structure. I'm nearly done; it's just some assembly and solution configurations plus #if-ing left to do.

Nice, I checked it :+1:

I think it looks good, but I'm not sure we need the assembly split between .NET Core and .NET 3.5. If we can get away with #if inside the SharpRaven.Core assembly, I think that would be preferable. Otherwise I agree with everything else you've suggested. :smile:

I believe that it will end up a heavily #IF'ed code.

I have checked the pull requests of netcore versions and there are at least 4 requests, what is missing?

asbjornu commented 7 years ago

@ricardoalcantara:

I believe that it will end up a heavily #IF'ed code.

The code is already rather heavily #if-ed, but by separating things into separate files, it's manageable. And with the build rewritten to Cake, it will be much easier to ensure a successful build across all build targets than today.

I have checked the pull requests of netcore versions and there are at least 4 requests, what is missing?

None of the pull requests attempt to preserve backwards compatibility with .NET 3.5 and all of them break the tests. I think that without completing the feature/httpclient branch and feature/cake-build branch branches, it's not worth attempting a .NET Core port because it's just going to break the existing continuous integration and release pipeline as well as the .NET 3.5 target.

ricardoalcantara commented 7 years ago

The code is already rather heavily #if-ed, but by separating things into separate files, it's manageable. And with the build rewritten to Cake, it will be much easier to ensure a successful build across all build targets than today.

This is something I like! :slightly_smiling_face:

None of the pull requests attempt to preserve backwards compatibility with .NET 3.5 and all of them break the tests. I think that without completing the feature/httpclient branch and feature/cake-build branch branches, it's not worth attempting a .NET Core port because it's just going to break the existing continuous integration and release pipeline as well as the .NET 3.5 target.

Got it! I am going to keep on track.

radenkozec commented 7 years ago

@asbjornu Do you support .NET Core? What I need to do to integrate my .NET Core project?

asbjornu commented 7 years ago

@radenkozec: Currently, no. But the long discussion above is an attempt to describe how to get there.

DMW007 commented 7 years ago

Are there any news about this issue? And is .NET 3.5 support really required? That framework is about 10 years old...

Would like to see a integration for .NET Core that is independent from the old .NET framework, so that it can run on linux, too. Sentry is a very great tool, that should be avaliable for .NET core, which is a great framework too 👍

asbjornu commented 7 years ago

@DMWOO7: We should be able to achieve .NET 3.5 compatibility as well as a clean break for .NET Core all at the same time. As I wrote in https://github.com/getsentry/raven-csharp/issues/125#issuecomment-297399008, the work to enable this has been started, but I haven't had time to complete it just yet.

If you're able to help, please take a look at the feature/httpclient branch or feature/cake-build branch and submit one or more pull requests to move this in the right direction. 😃

JoseFMP commented 7 years ago

@DMWOO7 support in Linux works fine with .NET 4.6 using mono. But really missing support of .NET Core. I have some .NetStandard library were I would like to use SharpRaven and not yet possible. :(

raRaRa commented 7 years ago

@Jose-CF It should be fairly easy to migrate from SharpRaven to HttpClient. I've ported about 6 clients that were previously using SharpRaven without problem.

asbjornu commented 7 years ago

The port to System.Net.HttpClient is already complete in both the feature/httpclient branch and feature/cake-build branch. The latter builds on the former to simplify cross platform and framework building and is all that needs to be completed in order to also target .NET Core. Anyone wanting to pick this up, please fork and branch from the cake-build branch so we can get this thing baked already. 😄

DMW007 commented 7 years ago

I tried the port from @wakawaka54 which works excellent. The only issue I see is that the RavenSharp.Core Client causes an exception on every ravenClient.CaptureAsync() Call:

System.NotSupportedException: Specified method is not supported.
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.FrameRequestStream.Seek(Int64 offset, SeekOrigin origin)
   at SharpRaven.Core.Data.DefaultHttpRequestBodyConverter.TryConvert(HttpContext httpContext, Object& converted)

Don't know where it came from. But it seems that this haven't any affect to the logger, since my exception was logged in sentry, although the SharpRaven error indicates that something went wrong with the loggin http request.

jabrown85 commented 7 years ago

In case anyone is looking for a relatively simple way to use RavenSharp as-is with aspnetcore on full .NET framework I'm posting a simple implementation.

https://gist.github.com/jabrown85/82baf795fc3853266118996fbd30dd50

The main part of the effort is how we decided to handle the HttpContext mismatch between aspnet versions. We created a request factory (AspNetCoreSentryRequestFactory.cs) that uses the dynamic overload of HttpRequestBodyConverter.Convert(httpContext) to provide a shim that matches the old HttpContext but is backed by the newer version.

Note: We didn't map Environment variables in the custom request factory. This was an internal decision for our project but adding support for it wouldn't be difficult.

I figured this might help out others looking to get middleware up and going for a full .net framework project on the aspnetcore bits.

gtarsia commented 7 years ago

Is this happening anytime soon? I'm trying really hard to stick to sentry, but this problem is making it hard.

michaelpinnell commented 7 years ago

Going off the gist @jabrown85 provided I was able to get a mostly working implementation of it up and running for our new Core Services project, so depending on your needs @erandros your best bet currently is to go for that.

That being said now that Core 2.0 has been finalized I'm considering trying to see if I can get something a little more robust working so we can really get Core Support off the ground.

JoseFMP commented 7 years ago

I think there is a good point in getting it working in NetStandard 2.0 rather than 1.x ... Being the point that it can be reusable from net461 assemblies.

MaikuMori commented 7 years ago

Seems like there are multiple PR, but none is finalizing this. What's the status?

asbjornu commented 7 years ago

@MaikuMori: I tried to outline the status in https://github.com/getsentry/raven-csharp/issues/125#issuecomment-297399008.

JoseFMP commented 7 years ago

@DMWOO7 over here we really need support for 3.5. The reason is that currently Unity3D does not support anything higher than .NET Framework 3.5. So, that's terrible, but you can send the complains to them :p

asbjornu commented 7 years ago

@Jose-CF: Yes, the goal is to support everything from .NET 3.5 and up to the latest version of .NET Core through #if statements in the code and conditional builds in Cake.

Rekeyea commented 7 years ago

Just tried RavenSharp on .Net Core 2 without modifications and it works like a charm :-D

gtarsia commented 7 years ago

@Rekeyea just tried it on my project and the build was ok
@asbjornu how safe do you feel is it to use it on my production projects?

asbjornu commented 7 years ago

If it works, I see no reason why it shouldn't be as stable as on other runtimes. Good to hear that .NET Standard 2.0 finally brings .NET Core up to speed! 😄 👍

Vlaaaaaaad commented 7 years ago

Is there still work to be done on this?

ghost commented 7 years ago

It might run on dotnet core when you're running windows. but (at least out of the box) not when you're on osx or linux. most of the dependencies for SharpRaven are .net 4.6.1 warning NU1701: Package 'Newtonsoft.Json 6.0.8' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project. for example (among a lot of others) so @Vlaaaaaaad i think there's still work to be done

asbjornu commented 7 years ago

Yes, that's why we have #132, #145, #163, #168 and #189 going. Once we have a build targeting .NET Core, it should work on all platforms.

Vlaaaaaaad commented 7 years ago

Perfect! Even though some of the PRs are from 2016...

We are considering using Sentry for new projects and this is a blocker for us as all the new apps are .NET Core 2.0 on Linux.

asbjornu commented 7 years ago

@Vlaaaaaaad: Seems like #189 is moving forward now, so it shouldn't be long before we have this in place.

MaikuMori commented 6 years ago

With #189 merged, what's the progress on this?

matheusmogi commented 6 years ago

I'm trying to use the example for C# with .net Core (RavenSharp.Core -Version 1.0.0-beta-1) but I can't get the exception to my account. Is it working?

xgenvn commented 6 years ago

@Rekeyea Can you share your configuration and steps to make RavenSharp.Core beta working? I'm trying to integrate to a .Net Core 2 Web API project, throw the exception doesn't seem to have any effect.

Thanks.

ShooterArk commented 6 years ago

I have integrated Sentry as directed but I am unable to get any exceptions :/ .. Is anyone still facing this issue? A simple "Hello World" is also not visible on the dashboard. Am I missing something? Doesnt it take 24 hours to update like few of the others that I have worked it!! Please advise.

Thanks.

semarj commented 6 years ago

FWIW I just hooked 2.2.0 up in an AspNetCore app and it appears to works well other than the suppressible NU1701 warning. Exceptions being captured with all the expected context. I checked on https://icanhasdot.net/result?github=getsentry~2Fraven-csharp and it makes me comfortable that the .NET Core compatibility shim will just work.

sereeth commented 6 years ago

there any release in sight? Would like to use nlog sentry target but it ref's the old version which obviously doesn't work with .net core (which is kinda popular).