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?

[DonDebonair]

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 notifications@github.com 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: