938

Supporting .NET Standard 2.0 would mean supporting all of these platforms:

• .NET Framework 4.6.1
• .NET Core 2.0
• Mono 5.4
• Xamarin.iOS 10.14
• Xamarin.Mac 3.8
• Xamarin.Android 7.5
• UWP vNext (shipping later this year)

When running RestSharp using the backwards compatibility shim, it works for the most part, there are just issues with the underlying class used to invoke the HTTP calls - if the HTTP client were switched out with the new HttpClient, it should work.

On a personal note, we use RestSharp quite a bit here in our office, and we are already working on new cloud-based solutions that run using ASP.NET Core, so we would really like to see RestSharp brought up to the latest .NET version so that we won't have to switch to a new REST library.

@qJake Since .NET Standard 2.0 has a vastly expanded API surface, surely HttpWebRequest could be retained instead of switching to HttpClient. Maybe the issues you experienced with the shim are no longer present?

Why .NET Standard 2.0? Please consider to target the lowest available version.

@mguinness See this comment in the @dotnet/corefx project - HttpWebRequest is not part of .NET Standard, but System.Net.Http.HttpClient is.

Please consider to support UWP current version too. (before Fall Creators Update)

UWP current version would mean netstandard1.4. I am not sure what consequences this will bring, need to start experimenting.

@qJake Well HttpWebRequest is in .NET Standard 2.0, your assertion is only true for .NET Standard 1.6 and below.

@mguinness Oh, I see - well that presents a challenge, then - since RestSharp uses HttpWebRequest/Response, do we support only .NET Standard 2.0 and stick with those classes, or do we refactor the underlying client and switch to HttpClient, allowing us to support older versions of .NET Standard?

People want 1.4 due to issues with current version of UWP. NETStandard 2.0 will only be supported in UWP vNext.

@qJake FWIW, there's also the System.Net.Requests nuget package that can be used in earlier versions of .NET Standard.

Hey guys, any update or ETA on this? Planning on using RestSharp on my dotnet core 2 app and I would not like to switch packages.

It is work in progress. Legacy stuff has been removed but we will probably have co bring JSON.NET to the release as well. Stay tuned.

WIP: https://github.com/alexeyzimarev/restsharp/tree/netstandard

I need to use it for AWS Lambda, but when using RestSharp.NetCore 105.2.3 AWS return errors
--Detected package downgrade: System.Reflection from 4.3.0-preview1-24530-04 to 4.1.0.

Means RestSharp is using 4.1 but AWS support 4.3 version set, for .NetCoreApp 1.0.

Do we a version with dependency on System.Runtime.Serialization.Primitives.4.3.0-preview1-24530-04?

We are moving to .net core and have just found that we can't reference RestSharp from .net standard 2.0 the nuget package fails to install.

Package 'RestSharpSigned 105.2.3' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Package restore failed. Rolling back package changes for

@trampster I think you misunderstand the status. The official RestSharp package doesn't support .NET Standard and was last updated in 2015. The conversion being worked on by alexeyzimarev hasn't been published yet AFAIK.

I understand, I was posting to help indicate there is demand for it. Also to show that the .NET Framework compatibility mode for referencing .net full dlls from .net standard 2.0 as announced by Microsoft when releasing .net standard 2.0 is not working here. So there is no work around, we are blocked.

We would prefer not to have to shift to another Rest library, but we will if we need to. It will depend on how long this conversion will take.

Interestingly there is a RestSharp.NetCore package on nuget https://www.nuget.org/packages/RestSharp.NetCore with 98,895 downloads, however as far as I can tell the uploader is not associated with the project so I don't know if I can trust it.

@trampster That's a nuget warning (which can be supressed), see Reusing an existing .NET Framework library. Also what is your target framework in your csproj, is it netcoreapp2.0 or v4.6.1?

Take a second look at the last line. It rolled it back. Afterwards I have no reference to RestSharp.

Also if you read my post will see I'm trying to use it from .net standard 2.0 not netcore2.0 or v4.6.1.

It should also be noted that the warning says v4.6.1 was used but the RestSharp nuget package doesn't have v4.6.1

@trampster I have installed it successfully into a .NET Core 2.0 app using the compatibility bridge, but when I go to run it I get a runtime exception that boils down to a usage of HttpWebRequest. I did not get any NuGet package install failures, so that's weird. 😃

I'm also running into this :\ @alexeyzimarev how can the community help. We need this and are all blocked on this. I run the OAuth2 package which uses this library and everyone is blocked from using that as well.

Using the current nuget package in a .NET Core app is only possible if you target the full framework.

I created a new .NET Core console app, ran Install-Package RestSharp -Version 105.2.3 from Package Manager and added following code into Main:

```C#
var client = new RestClient();
client.BaseUrl = new Uri("https://api.github.com/");

var request = new RestRequest();
request.Resource = "users/restsharp/repos";

var response = client.Execute(request);
```

Targeting netcoreapp2.0 will give System.PlatformNotSupportedException: Operation is not supported on this platform. but it will work if you change to <TargetFramework>net46</TargetFramework> in csproj.

We are not targeting the full framework

@niemyjski Maybe try RestSharp.NetCore while you wait for this library to get updated. It's being used by the following libraries so it should be stable enough for use.

ADH.PushCore
AppVeyorSharp
CoreLib.Web
CouchDB.Client
DocuSign.NetCore
Flip.PomboCorreio.Connector
FluentEmail.Mailgun
GiphyApiClient.NetCore
Intercom.Core
IronSphere.Henchmen
MasterCard-Core-Unofficial
mbank-dotnet
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Onlinesites.ShopFacilBradesco
pusher-http-dotnet-core
RepositoryFramework.Api
RepositoryFramework.EntityFramework
RestSharp.Newtonsoft.Json
RestSharp.Newtonsoft.Json.NetCore
Slack.Webhooks.Core
StoneCo.PomboCorreio.Connector
SwitchAPI.Connector
Syncromatics.Clients.Metro.Api
TransportApi.Sdk.NetCore
Twilio.NetCore
UtilityFramework.Application.Core
UtilityFramework.Services.Iugu.Core

Does anyone know who the uploader of RestSharp.NetCore is? I looked at there github and they don't have a fork of RestSharp. There is no license listed on the package, for all I know it's malicious.

Who ever owns this project should seek ownership of the restsharp package namespace... and probably get that package delisted. I’d probably see if that package contains any malicious content by decompiling it

On Oct 5, 2017 at 10:57 PM,

@niemyjski (https://github.com/niemyjski) Maybe try RestSharp.NetCore (https://www.nuget.org/packages/RestSharp.NetCore/) while you wait for this library to get updated. It's being used by the following libraries so it should be stable enough for use.

ADH.PushCore
AppVeyorSharp
CoreLib.Web
CouchDB.Client
DocuSign.NetCore
Flip.PomboCorreio.Connector
FluentEmail.Mailgun
GiphyApiClient.NetCore
Intercom.Core
IronSphere.Henchmen
MasterCard-Core-Unofficial
mbank-dotnet
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Onlinesites.ShopFacilBradesco
pusher-http-dotnet-core
RepositoryFramework.Api
RepositoryFramework.EntityFramework
RestSharp.Newtonsoft.Json
RestSharp.Newtonsoft.Json.NetCore
Slack.Webhooks.Core
StoneCo.PomboCorreio.Connector
SwitchAPI.Connector
Syncromatics.Clients.Metro.Api
TransportApi.Sdk.NetCore
Twilio.NetCore
UtilityFramework.Application.Core
UtilityFramework.Services.Iugu.Core

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (https://github.com/restsharp/RestSharp/issues/992#issuecomment-334651808), or mute the thread (https://github.com/notifications/unsubscribe-auth/AA-So9HrYQHV5nlV1m7W7eY-y_F5cBqqks5spaUXgaJpZM4PLH2m).

@alexeyzimarev is there any chance of getting a prerelease nuget package out there today? Even if it's a beta and all tests working but some other things may change.

Sad RESTsharp doesn't work with Core 2.0. Guess it's back to HttpClient

@niemyjski No, sorry. I am changing WebRequest to HttpClient and this is a big change. The reason for this is that WebRequest is only available for netstandard 2.0 and we want to support 1.6.

@niemyjski I can publish my changes to a separate branch if you want to help-

I actually switched to netstandard 2.0 now. netstandard 1.6 seems to be too much work. But I still want to use HttpClient.

Check this out: https://github.com/restsharp/RestSharp/tree/netstandard
PRs welcome.

@amivit You can contribute some of your time to make it happen, right?

I am changing WebRequest to HttpClient and this is a big change. The reason for this is that WebRequest is only available for netstandard 2.0 and we want to support 1.6.

That's an incorrect statement as there is the System.Net.Requests nuget package.

Would it be difficult to initially stick with WebRequest and then transition to HttpClient over time?

@mguinness Have you tried using this package? I did.

@mguinness We can say - forget 1.6, we go for 2.0 and we keep WebRequest. I am personally fine with that.

Sorry @alexeyzimarev I don't have the time to contribute. I wish. I'm just surprised RESTsharp isn't relying on HttpClient to begin with. Hasn't it been an available improvement over WebClient since 2012 or .NET 4.5?

@amivit Probably a case of if it ain't broke, don't fix it.

Sorry for just mimimi here :rofl:
but after upgrading my client-application to .net core 2.0 I get a few warnings about RestSharp:

warning NU1603: RestSharp.NetCore 105.2.3 depends on System.Runtime.Serialization.Formatters (>= 4.0.0-rc4-24217-03) but System.Runtime.Serialization.Formatters 4.0.0-rc4-24217-03 was not found. An approximate best match of System.Runtime.Serialization.Formatters 4.3.0-preview1-24530-04 was resolved.

I didn't try to execute the application for now - I guess it won't work.
So, RestSharp doesn't support .net core 2.0 yet. But, will it some day? Is there already a date? Can I help here to make this happen (as a contributor)?

@matthiasburger check the netstandard branch. I mentioned this just a couple of posts above your comment.

Go with 2.0 for now. Can always change it later to be http client... Also
make sure you have the compiler directives to make it have the sync methods
(FRAMEWORK)

Thanks
-Blake Niemyjski

On Wed, Oct 11, 2017 at 6:43 AM, Alexey Zimarev notifications@github.com
wrote:

@matthiasburger https://github.com/matthiasburger check the netstandard
branch.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/restsharp/RestSharp/issues/992#issuecomment-335782906,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-So8akA6MlKfoypWDSAqaElcYBPFoAks5srKnUgaJpZM4PLH2m
.

sry @alexeyzimarev sometimes I should read everything - great. I take a look at it :)

@niemyjski All pragma directives are removed. I do not want to have any deviations per platform, framework, etc. This is what netstandard declares to solve and I am going to use it.

Ok, so netstandard branch now builds for both signed and unsigned. Still I have four tests that fail (encoding, decoding). Integration tests not included yet. Hopefully I can finish the code this week but build and pack will require some more work to switch to DotNetCli.

Ok, all seems to work. I had to conditionally ignore two tests because of unsupported exceptions from the HttpListener (integration). Expect it to work though when used with a proper server.

Now build script needs to be changed to use DotNetCli and stop using nuget.exe

Keep up the great work @alexeyzimarev! Can't wait for the first release 👍

Please test https://www.nuget.org/packages/RestSharp/106.0.0-alpha0277

Tested 106.0.0-alpha0277 in VS2017 & real IIS targeting .NET Core 2.0

ErrorException: System.PlatformNotSupportedException: Operation is not supported on this platform.
at System.Net.SystemWebProxy.GetProxy(Uri destination)
at System.Net.ServicePointManager.ProxyAddressIfNecessary(Uri& address, IWebProxy proxy)
at System.Net.ServicePointManager.FindServicePoint(Uri address, IWebProxy proxy)
at System.Net.HttpWebRequest.get_ServicePoint()
at RestSharp.Http.ConfigureWebRequest(String method, Uri url)
at RestSharp.Http.PostPutInternal(String method)
at RestSharp.Http.AsPost(String httpMethod)
at RestSharp.RestClient.DoExecuteAsPost(IHttp http, String method)
at RestSharp.RestClient.Execute(IRestRequest request, String httpMethod, Func`3 getResponse)

I know they added a lot of IsXYZ methods overtime, perhaps we need to be checking those before calling these methods or wrapping them?

It would be good to start running these tests under Linux as I think it would find lots more issues than on Windows.

@maciek12305 it is not enough to copy-paste an exception here since I have no idea how you got there.

@niemyjski I agree about running tests on Linux but this requires setting up a new CI build. I will look at Travis later on, hopefully next week.

Seems like an issue with proxy https://github.com/Azure/azure-iot-sdk-csharp/issues/140

Ok, the issue is that .NET Core does not support default proxy because settings for default proxy are loaded from registry.

So, it should work if you do not use proxy and it will crash on .NET Core if proxy is used. For now I added the "default proxy" class, which says to bypass everything and go directly. If you have to use proxy - you will have to provide it using ConfigureProxy method.

Please try the latest package: https://www.nuget.org/packages/RestSharp/106.0.0-alpha0281

@niemyjski Actually integration tests pass fine on Mac. So it should work on Linux too, I suppose.

@alexeyzimarev The latest package didn't work for me on Win 10. The only way for me to get it working was to include the following in my code:

C# //https://github.com/dotnet/corefx/commit/6acd74dda7bc4f585d2c4006da4a8b2deb0261ad var proxy = WebRequest.DefaultWebProxy; WebRequest.DefaultWebProxy = null;

@mguinness so why do you keep the old value (not sure what it is) in the proxy variable? I guess the only line, which can make any difference is the

WebRequest.DefaultWebProxy = null;

I can easily add it if this will help.

@alexeyzimarev There was a bug in the framework which commit "WebRequest.DefaultWebProxy: Set doesn't work without a previous Get" fixes.

I understand now. I can try making a package with setting the request Proxy property to null instead of manipulating the default one.

@mguinness the new package is out, thanks for helping!

@mavanmanen can you try this one too, with UWP? https://www.nuget.org/packages/RestSharp/106.0.0-alpha0282

With version 106.0.0-alpha0282 the same error "Operation is not supported on this platform."

@remiskaune have you tried to include these lines in your code?

var proxy = WebRequest.DefaultWebProxy;
WebRequest.DefaultWebProxy = null;

Thanks. It works now with this lines on version 106.0.0-alpha0282.

So the question is why doesn't it work without, since I included these lines in RestSharp code...

Perhaps WebRequest has a different scope? Is it a static class or instanced?

You could find out by making a sample app, and in your sample app, check:

WebRequest.DefaultWebProxy

And also exposing some method for RestSharp to send the value it is seeing (for debugging purposes) - e.g.:

public IWebProxy GetCurrentProxy() => WebRequest.DefaultWebProxy;

See if the two are different?

@qJake I would appreciate if someone can debug for me :) I will not be able to spend any time on this until next week, will be speaking at a conference.

New package is available where the proxy issue is "fixed" by assigning the WebRequest.DefaultProxy to null. This might have consequenced but I do not expect real issues. The workaround is only added to .NET Standard assembly. .NET Framework assembly should work as before.
https://www.nuget.org/packages/RestSharp/106.0.0-alpha0284

If there will be no issues reported, I will start preparing the release.

Fairly positive response here. I was playing around trying to get a dependent package working (Atlassian.JIRA) and assuming I targeted .NET standard 2.0 then all their integration/unit tests "just worked" so LGTM.

https://bitbucket.org/farmas/atlassian.net-sdk/issues/306/support-for-dotnet-core for the thread at that end.

I have tested it against our solution, and it works well.

We are using it from .net standard 2.0 projects and .net 4.6.1 projects

When used from the .net 4.6.1. projects it pulls in the following references, which visual studio marks with yellow exclamation marks.
System.Net.Http
System.Runtime.Serialization.Primitives
System.Security.Cryptography.Algorithms
System.Security.Cryptography.Encoding
System.Security.Cryptography.Primitives
System.Security.Cryptography.X509Certificates

I'm not sure why this is, however it does not seem to cause any issues.

The one minor issue we have is that we use clickonce to distribute one of our tools so we are forced to strong name everything. However the prerelease version is not strong named. We have been using the RestSharpSigned version of the package but there is no prerelease version of that with .net standard support.

Having a strong named and non strong named version can be problematic in the situation where you have two dependencies one which depends on the strong named version and one which relies on the non strong named version.

Instead of this I suggest having one package which is signed and freezing to the major version of you assembly version (in SemVer the major version only changes when you break compatibility) then using full SemVer on your FileVersion. This way you have one nuget package that everyone can use (strong named or not) and the major version freeze means that binding redirects are not required. And using SemVer means that everyone knows exactly where they stand in terms of compatibility.

I suggest this here because the switch to .net standard might be a good time to make this change.

We should just sign the package by default and put the key in GitHub , The .net team recommends this as it doesn't hurt anything.

Is there a PR that I can view the changes?

@niemyjski I assume the develop branch is visible for all. I made it a default branch too.

@niemyjski "Just" does not work in this case. If you want to help - please do. I had to remove Signed projects because they fail the whole solution build due to a bug in nuget.
https://github.com/dotnet/standard/issues/538
https://github.com/NuGet/Home/issues/6038

So either I will need to wait until it is fixed, or I have to add a separate solution and projects, and then include all files manually, which is nasty.

@alexeyzimarev just have one csproj and sign it, Freeze the assembly version number (to major version) to avoid binding redirect issues. Use standard SemVer for nuget and file version. This will solve all your problems.

If you insist on keeping two versions (which will cause issues for your users) then you can still do this with a single csproj via configuration.

I did this originally in my own project (and it worked) before I realized how broken it was to have two versions. Basically I added a StrongName property group. Then build with dotnet build -c StrongName

<PropertyGroup Condition="'$(Configuration)'=='StrongName'">
    <PackageId>Jsonics.StrongName</PackageId>
    <NetStandardImplicitPackageVersion>1.6.1</NetStandardImplicitPackageVersion>
    <PackageVersion>0.1.0-alpha</PackageVersion>
    <Optimize>true</Optimize>
    <AssemblyOriginatorKeyFile>Jsonics.snk</AssemblyOriginatorKeyFile>
    <SignAssembly>true</SignAssembly>
    <PublicSign Condition="'$(OS)' != 'Windows_NT'">true</PublicSign>
</PropertyGroup>

If you wait for a fix to the issues you raised then you could be waiting a long time.

This will solve all your problems.

I just love it.

The property group suggestion is valuable. I will try to keep two packages, otherwise it will create confusion. I might be wrong but personally I would just avoid signing. But since you need it - I will try to make a package with a signed assembly.

@niemyjski do you have a link to "The .net team recommends this"? I need to know more about consequences and how exactly they suggest doing this.

I've talked with them and I know that they've also said it publicly in
forums and slack. It's kind of a joke and should be removed (
https://twitter.com/terrajobst/status/774752534682402817).. It's better to
just strong name the assembly... We strong name all our assemblies and
leave the signing snk in the repo as it's a joke. Anyone with a hex editor
can bypass strong name signing and it only hurts those who are required to
sign their packages from taking on dependencies. You can reference a strong
signed package from an unsigned package so why not just sign it all the
time.

https://github.com/FoundatioFx/Foundatio/blob/master/src/Foundatio/Foundatio.csproj

Thanks
-Blake Niemyjski

On Wed, Nov 1, 2017 at 1:30 PM, Alexey Zimarev notifications@github.com
wrote:

@niemyjski https://github.com/niemyjski do you have a link to "The .net
team recommends this"? I need to know more about consequences and how
exactly they suggest doing this.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/restsharp/RestSharp/issues/992#issuecomment-341197289,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-So94xh-jiEMniw0D2QaGQPgT9zfBfks5syLjDgaJpZM4PLH2m
.

Ok, I will just sign it.

It is released. https://www.nuget.org/packages/RestSharp/106.0.0

You shoud create a release tag in here at github. :)

Tagged

The release notes for 106.1.0 mentions:
"Fixed the proxy issue on .NET Core"

Not sure what that fix covers, but we're still facing problems using the proxy.
Prior our .NET Core 2.0 port (coming from .NET Framework 4.6.1), we instanstiated the client like this and it worked like a charm.

 _restClient = new RestClient(DanskStatistikApi)
 {
         Proxy = WebRequest.GetSystemWebProxy()
 };
 _restClient.Proxy.Credentials = CredentialCache.DefaultCredentials;

Using the same code in the .NET Core 2.0 project gives us following response error:

System.PlatformNotSupportedException: Operation is not supported on this platform.

The code firing the request looks like this:

var taskCompletion = new TaskCompletionSource<IRestResponse>();
var asyncHandle = _restClient.ExecuteAsync(request, r => taskCompletion.SetResult(r));
var response = (RestResponse)(await taskCompletion.Task);

Any thoughts?

Thx,
Fred

Do you have a working code for .NET Core 2.0?

Bacause if you chck the stacktrace, you will see that this is not our exception but .NET exception when it tried to get a default proxy.

Yes, you're right @alexeyzimarev, the exception is atually thrown at System.Net.SystemWebProxy.GetProxy, I was to quick on the trigger. :)

For others encountering the same problem, you can explicitly specify what Proxy to use like this:

var restClient = new RestClient(DanskStatistikApi)
{
     Proxy = new System.Net.WebProxy("your-proxy-url-goes-here", 8080)
};
restClient.Proxy.Credentials = CredentialCache.DefaultCredentials;

I've upgraded from 106.1.0 to 106.2.0 on .NET Core 2.0 and this message has started popping up:

System.PlatformNotSupportedException: Operation is not supported on this platform.

As mentioned by others, this message seems to be generated by System.Net.SystemWebproxy.GetProxy, but in my instance I am not explicitly configuring a proxy at all, internally it's doing its own operations and throwing an exception on every request I make.

I've revered back to 106.1.0 and this has fixed it, so has something change in 106.2.0 where the proxy settings need to be explicit in some way?

@voicebooth this is reported in #1061