Restsharp: Are there any plans on supporting aspnet 5 and aspnet core 5 support ?

[StefH]

Are there any plans on supporting aspnet 5 and aspnet core 5 support ?

[hallem]

There hasn't been an ask for it before and since I don't develop against that platform it hasn't come up against for me either. I'd be happy to see what can be done to add a targeting mechanism for it.

[martinjt]

Was wondering the same thing. Not sure what's required either, but I think it might be a big job.

[StefH]

I did some quick check last week (before the aspnet/dnx rename). and what I noticed is that the HttpClient was not available, or I could not find it...

[martinjt]

http://stackoverflow.com/questions/27946798/httpclient-in-asp-net-5-0-not-found

Looks like it's been split into a new package.

[ctolkien]

Just bumping this up for visibility, as .Net Core has just hit RC1. Again, no idea what would be involved at this stage. It may be as simple as referencing the split off HttpClient when on dotnet core?

[DandyDev]

I would be interested in this as well!

[jwulf]

+1 for me.

[MikeFoden]

Would be lovely to have this.

[CecilCable]

+1 for me too

[matthewvalimaki]

While directly not problem of this particular project https://github.com/swagger-api/swagger-codegen uses RestSharp and generated code breaks due to RestSharp not supporting .NET Core. Just to be clear: RestSharp is not the only thing that is breaking with code generated.

[jchannon]

Would love to see support. We are porting our large app to CoreCLR and use Restsharp extensively

[Yantrio]

+1 would love to have this in coreclr.

[philjones88]

+1 would be cool to have working on coreclr

[MikeFoden]

Based on the ASP.NET 5 Roadmap I think it's now stable enough to look at.

There is enough of us looking into this now, let's work together to see what we can do to get it working.

[StefH]

Hi all,
I've got it almost compiling by adding some Reflection Extensions and some Helper classes.

However I end up with these missing types:
The type or namespace name 'WebException' could not be found (are you missing a using directive or an assembly reference?)
The type or namespace name 'HttpWebResponse' could not be found (are you missing a using directive or an assembly reference?)
The type or namespace name 'HttpWebRequest' could not be found (are you missing a using directive or an assembly reference?)
The name 'WebRequest' does not exist in the current context RestSharp.Dnx.DNX Core 5.0
The name 'WebExceptionStatus' does not exist in the current context RestSharp.Dnx.DNX Core 5.0

So probably a lot has to be rewritten ?
See also
http://stackoverflow.com/questions/32211541/http-web-request-provider-in-coreclr-dnxcore

If it's required I can commit my work in progress to github.

[sherland]

We need this too.
Maybe you could create a branch for implementing this?

[StefH]

The question is : do we need this, because there is another project https://github.com/FubarDevelopment/restsharp.portable which can be used in dnxcore5. (This project uses the HttpClient instead of WebRequest/WebResponse.

Another possible approauch could be build a class which implements all methods defined in IHttp and internally uses the HttpClient.

Or write a separate RestClient.(Sync/Async) . cs implementation which directly uses the HttpClient

[ctolkien]

I'd say, yes, we do need this. RestSharp is a common dependency on a lot of other API wrappers. If we want to move them all towards running on .Net Core, then having support in RestSharp itself is critical.

From what I can see, the bulk of the work revolves around porting from WebClient to HttpClient ?

[jchannon]

One thing, if the "Portable" version uses HttpClient and the work required is to remove WebClient and replace with HttpClient, why not make the "Portable" project the main project if its going to work on dnxcore50 already?

UPDATE Just realised the portable version is a different project. Wonder if @fubar-coder would be interested in this issue

[fubar-coder]

The RestSharp.Portable project can either use HttpClient or HttpWebRequest since 3.1. I'm willing to help to incorporate the features of RestSharp.Portable into the original RestSharp project, but it's not an easy task due to the portability and the exchangeable HTTP request "engines" (HttpClient/WebRequest).

[jchannon]

Moving forward what are the advantages of keeping multiple engines? HttpClient will work on CoreFX so will automatically work on full .net framework. cc // @hallem

[fubar-coder]

The main reasons were:

• HttpClient behavior is inconsistent across multiple platforms (especially Mono)
• Support for custom HTTP implementations that allow the usage of SOCKS proxies (EDIT: e.g. to allow HTTP requests through the TOR network)

[martinjt]

I think the biggest reason is the dependencies from other applications. Unless you can get them to change to RestSharp.Portable as a dependency (not a great option imho), they may look to move to another completely, or do it purely internally.

Personally, the reason I want to use RestSharp is for things like Mobile (Xamarin and UWP), which I could potentially use RestSharp.Portable for. However, when integrating with some other APIs that have .NET wrappers, they seem to have stuck with RestSharp.

[hallem]

I'd love to support this at some point but there is a lot of work required to do so. Once I have addressed the list of items I have to fix bugs and do some minor enhancements, this will get started.

[sherland]

@hallem: I'm one of those who use a library that is dependent of RestSharp. RestSharp is used by a lot of other libraries, and possibly blocking .net core adoption for other libraries.
As you say, it's quite a lot of work. I won’t be able to help with coding, but doesn't it make sense to make it easy to contribute for those who can?

Btw:
@Haacked wrote an article on how to find dependent nuget packages here: http://haacked.com/archive/2011/02/23/how-to-find-out-which-nuget-packages-depend-on-yours.aspx/
RestSharp is used quite a lot :-)

[StefH]

Initial version has been committed to https://github.com/StefH/RestSharp/tree/master/RestSharp.Dnx however the issues reported by me on Jan 16 are not yet solved.

[jchannon]

Cool!

[DarrelH]

@StefH - I borrowed your references and compile list from your project.json and did the following to get compilable but I'm still doing some testing before it's anything I would commit:

• updated a few reference versions (such as System.Reflection.*)
• changed your reference for System.Net.Http to System.Net.Requests
• dropped all your System.Security references except X509Certificates
• added a reference for System.Security.Cryptography.Algorithms
• added an exclusion for DOTNET5_4 to most of the same places one existed for WINDOWS_UWP except in OAuthTools.cs which was a little different.

Like I said, it's buildable but I'm not certain I trust it yet. Hopefully these will help you out...

[StefH]

Hello @DarrelH.

Creating a dnxcore50 / DOTNET5_4 compatible build is the goal from my exercise, but this is only possible if the HttpWebRequest/HttpWebResponse is completely rewritten to use the new HttpClient. But this means almost a total rewrite from the rest-client, so I think this is not possible.

[eByte23]

@StefH I'll do this, already done for Flurl, but I don't like Flurl as much restsharp.

[ehuna]

+1 for me as well

[bbehrens]

+1 for me as well. We're using RestSharp extensively and would like to be able to run it on .net core

[jforsell]

+1

[helephant]

Important for us too.

[jchannon]

I'm going with Portable Restsharp for now
https://github.com/FubarDevelopment/restsharp.portable/issues/64

On 18 May 2016 at 16:22, Helen Emerson [email protected] wrote:

Important for us too.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/restsharp/RestSharp/issues/664#issuecomment-220061595

[sherland]

In the blog-post .NET Core, a call to action @markrendle writes:

... Since that discussion, a System.Net.Requests package has been added to CoreFX, providing what is essentially a WebRequest-shaped shim around HttpClient, so porting the Storage SDK should be much easier now.

Could this help in porting restsharp as well?

[StefH]

@sherland That's maybe a good workaround for the issues, I'll take a look.

Do you know the nuget package which contains this code?

[igeligel]

@StefH Its included in RC2 of .net core. You can find the docs here.
Edit being a bit more specific. Just include System.Net and you got the references:

using System.Net;

It seems like there is just async support yet. The actual code behind it is in the corefx repository.

[StefH]

dotnet rc2 support added !

See my pull request : https://github.com/restsharp/RestSharp/pull/846

Things still to do:

1. Use ifdef REMOTECERTVALIDATION for RemoteCertificateValidationCallback
2. Some frameworks are missing in project.json
3. SL50 cannot compile yet in rc2 ? Some framework dependencies are missing?.

[CL0SeY]

Great to see some progress on this!

@StefH - I don't mean to nag - but it looks like a lot of whitespace changes were made with your PR - for the sake of keeping the git history clean it might be worthwhile keeping to the standard that was set by the project. Also would make it easier to see what has changed :smiley_cat:

[Yantrio]

you can add the querystring ?w=1 in github to ignore whitespace changes :)

[hallem]

ignoring them is not appropriate. @CL0SeY is correct that those changes shouldn't have been made.

[StefH]

Is there a special formatting standard which is used in this project? And is this easiliy confugurable in vs2015?

[StefH]

OK.
I've created a new pull request (https://github.com/restsharp/RestSharp/pull/847) which does only have the required changes in code, whitespace changes are minimal.

Please have a look.

[BHSPitMonkey]

Microsoft announced .NET Core 1.0 today, so expect interest in this issue to increase!

[sapan-desai]

Yeah for all our previous projects, we have uses RestSharp. With Microsoft releasing .Net Core 1.0 yesterday, we have decided to adopt it for one of the new projects here. First hiccup on the new journey was to find that RestSharp is NOT yet there supporting .Net Core. When can we expect this to be available?

[fubar-coder]

It's not that easy, because tooling is still preview2 instead of rtm. You cannot easily (e.g.) build packages that use the bait-and-switch technique (Output stored under ref instead of lib for - for example - netstandard1.0)

[eByte23]

There is no reason this library can not be ported any, the abstracted "webclient" it uses is once again available. It is very is to target multiple frame works with a project.json format and easy to use ifdefs to define what code to use

[StefH]

I did already create a pullrequest for the rc2.

[kamranayub]

Merging #863 or #847 or #862 would be pretty awesome, guys :+1:

[IvanJosipovic]

This is the only component holding me back from using .Net Core. Anything we can do to help?

[dsaf]

@johnsheehan @hallem Is RestSharp dead?

https://github.com/restsharp/RestSharp/releases
https://github.com/restsharp/RestSharp/pulse

[thedumbtechguy]

I was really hoping to use RestSharp in my net core mvc app. Seems this won't happen.

[dsaf]

@frostymarvelous https://github.com/tmenier/Flurl is not bad, at least for simple scenarios.

[thedumbtechguy]

@dsaf I was going to go with Foobar Restsharp.

Do you have any idea which is better?

[dsaf]

@frostymarvelous hard to say, if you are targeting .NET Core as well then Flurl seems to be more up-to-date, but maybe Foobar is more familiar for Restsharp users? Although both are in active development by the looks of it. Given the trends we will use something else in a year or two anyway :).

[Ettery]

I'd love to see RestSharp working on .NET Core, and be able to use the same library across my projects.

[dsoronda]

+1 for .NET Core
Any news regarding this issue ?

[mguinness]

+1 for me also. Need to use DocuSign, but they have no .NET Core version possibly due to dependency on RestSharp. If there is a reluctance to merge PR https://github.com/restsharp/RestSharp/pull/863, maybe another solution would be to create a new project named RestSharpCore based off that? Would that be a practicable solution?

[fubar-coder]

I'm not sure it this makes sense yet, because the tooling will change significantly with the release of VS2017. Currently supporting .NET Core feels like catching a moving target, because the current preview2 tooling lacks several features and the workarounds aren't supported by the migration tool (yet?).

[CL0SeY]

@mguinness I agree - if we publish a fork for .NET Core using the tooling available today, it will help a lot of people.

I'm using my own version that I have built and modified using some of @zhongzf 's work in order to get me out of trouble in my project. (It was a swagger generated proxy library that was tied to RestSharp.)

Some unknowns in publishing a fork would be:

• What versioning scheme would we use? Would we try and keep the RestSharp versions somewhat, or start from scratch?
• What platforms should be targeted? Should we keep compatibility for the .NET Framework?
• What underlying client should we use? It should be noted that some of the API surface of HttpWebRequest is missing in the initial .NET Core release, including relating to timeout duration. The missing properties will be in the next release of corefx / HttpWebRequest. (Although it's recommended to use HttpClient instead.)

[StefH]

Also, if supporting .net core , which versions should this be?

I think at least netstandard 1.3 , but that one has indeed only httpclient.

The netstandard 1.6 has maybe more APIs, if you want all in easy way, then netstandard 2.0 would be the choice.

The main question is also why we want to use restsharp.

There are many alternatives like unirest.

[tibitoth]

don't bother, RestSharp is dead...

[kamranayub]

If anything, a "bridge" library might be nice--for example, to allow
migrating to a new library like Flurl/Unirest, create a .NET Core library
that exposes the same API surface as RestSharp and translates it to the
other library. There are probably things that may not work/translate but
it'd be a nice step forward and help avoid changing tons of code right away.

On Mon, Mar 6, 2017 at 6:00 AM Tibor Tóth (Tibcsi_) <
[email protected]> wrote:

don't bother, RestSharp is dead...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/restsharp/RestSharp/issues/664#issuecomment-284377740,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAiaa8sifqniZDRDXG1pyQfB_ZIMc74Bks5ri_VUgaJpZM4D1UPt
.

[ViktorHofer]

@totht91 Why do you say that? Is there any announcement that it is no longer maintained?

[jasoncavett]

@ViktorHofer My guess is that @totht91 was saying that because the last release of RestSharp was Aug 26, 2015. In addition, it has had very low activity otherwise and there are a large number of outstanding issues. All things point to a stale project.

[ViktorHofer]

Thanks for pointing out! I will contact the owner

[JvanderStad]

I'm using RestSharp, however I'm thinking of moving on. The project looks dead, PR's are being ignored.

There are 2 suggestions in this thread:

• [x] [Foobar RestSharp](https://github.com/FubarDevelopment/restsharp.portable)
• [x] [Flurl](https://github.com/tmenier/Flurl)

Does anyone have suggestions / forks I should check out?

Maybe I should move this post to a new issue to help people make a wise decision?

[jaredthirsk]

@JvanderStad It's a different class of library, but I'm giving RestEase a shot for type safe awaitable APIs:

• [x] https://github.com/canton7/RestEase
• [x] (inspired by:) https://github.com/paulcbetts/refit

[JvanderStad]

Both looks promising, I like the interface-definition of endpoints

[tibitoth]

@ViktorHofer is there any progress?

[ViktorHofer]

No, projects seems not be maintained. Like you said...

[tibitoth]

Sad. How can we take over the ownership to the community?

[kamranayub]

With the announcement last week of .NET Standard 2.0 and preview tooling available, there is more support for community Nuget packages now. I was able to successfully reference RestSharp in a netstandard2.0 app.

However, trying to execute a request will throw an exception due to the WebRequest attempting to find proxy information, through https://github.com/restsharp/RestSharp/blob/master/RestSharp/Http.Async.cs#L468

This is due to https://github.com/dotnet/corefx/blob/release/2.0.0/src/System.Net.Requests/src/System/Net/SystemWebProxy.cs#L52

at System.Net.SystemWebProxy.GetProxy(Uri destination)\r\n   
at System.Net.ServicePointManager.ProxyAddressIfNecessary(Uri& address, IWebProxy proxy)\r\n   
at System.Net.ServicePointManager.FindServicePoint(Uri address, IWebProxy proxy)\r\n   
at System.Net.HttpWebRequest.get_ServicePoint()\r\n   
at RestSharp.Http.ConfigureAsyncWebRequest(String method, Uri url)\r\n   
at RestSharp.Http.GetStyleMethodInternalAsync(String method, Action`1 callback)

Could try forking to modify this and see how far that gets, I don't have time at the moment.

[dermeister0]

I think it's better to rewrite the library around HttpClient class.

[kamranayub]

It might be better but if someone's looking for a low impact change just enough to get it working, this might be easier. Assuming it'll even work, it'll be a less impactful change to the codebase.

[tibitoth]

We really need to fork this repo by the community. If the repo owner read this comment please give us rights to maintain this project.

[eByte23]

So as everyone knows nothing is happening here so I have started work on port to netstandard 1.6 so it will be .net core 1 and 2 compatible
RestSharper

Only just started all work will be on feature/netstandard1.6
Name change will be to RestSharper.

[qJake]

Still waiting for that .NET Standard build. ;)

Any ETA, or any successful ports/forks that are still maintained as of today?

[StefH]

I'm currently using https://github.com/canton7/RestEase for some projects and this library works perfect and the interface typed design makes it very easy to integrate with DI frameworks.

[Rzpeg]

So, Foobar RestSharp aka Restsharp.Portable is dead as well. So Flurl.Http is the only way now?

[qJake]

@Rzpeg: @StefH had another good one, I think Flurl is more "playful" and RestEase is more "professional". Take your pick. :)

[alexeyzimarev]

@StefH what is the actual state of your interest now? the issue title no longer resembles the .NET landscape. I believe we should only have netstandard20 and that's it. What do you think?

[johnsheehan]

I think this thread is beyond the point of useful. Maybe start a new one for specific questions around the current framework versions available, whatever they are.

[alexeyzimarev]

992