938

.NET Standard 2.0をサポートするということは、これらすべてのプラットフォームをサポートすることを意味し

• .NET Framework 4.6.1
• .NET Core 2.0
• モノ5.4
• Xamarin.iOS 10.14
• Xamarin.Mac 3.8
• Xamarin.Android 7.5
• UWP vNext（今年後半に出荷）

下位互換性シムを使用してRestSharpを実行すると、ほとんどの場合機能します。HTTP呼び出しを呼び出すために使用される基になるクラスに問題があるだけです。HTTPクライアントが新しいHttpClientに切り替えられた場合は、機能するはずです。

個人的なメモとして、私たちはここオフィスでRestSharpをかなり使用しており、ASP.NET Coreを使用して実行される新しいクラウドベースのソリューションにすでに取り組んでいるため、RestSharpが最新の.NETに組み込まれることを本当に望んでいます。新しいRESTライブラリに切り替える必要がないようにバージョンを設定します。

@qJake .NET Standard 2.0のAPIサーフェスは大幅に拡張されているため、HttpClientに切り替える代わりに、確実にHttpWebRequestを保持できます。 シムで経験した問題はもう存在しないのでしょうか？

なぜ.NETStandard 2.0なのですか？ 利用可能な最低バージョンをターゲットにすることを検討してください。

@mguinness @ dotnet / corefxプロジェクトのこのコメントを参照してください-HttpWebRequestはSystem.Net.Http.HttpClientは含まれています。

UWPの現在のバージョンもサポートすることを検討してください。 （Fall Creators Updateの前）

UWPの現在のバージョンはnetstandard1.4を意味します。 これがどのような結果をもたらすかはわかりません。実験を開始する必要があります。

@qJakeまあHttpWebRequestは

@mguinnessああ、HttpClient切り替えるのでしょうか

UWPの現在のバージョンに問題があるため、人々は1.4を望んでいます。 NETStandard 2.0は、UWPvNextでのみサポートされます。

@qJake FWIW、以前のバージョンの.NETStandardで使用できるSystem.Net.Requestsnugetパッケージもあります。

やあみんな、これに関するアップデートやETAはありますか？ dotnet core 2アプリでRestSharpを使用することを計画していて、パッケージを切り替えたくありません。

仕掛品です。 レガシーなものは削除されましたが、おそらくJSON.NETもリリースに持ち込む予定です。 乞うご期待。

WIP： https ：

AWS Lambdaに使用する必要がありますが、RestSharp.NetCore 105.2.3AWSを使用するとエラーが返されます
-検出されたパッケージのダウングレード：4.3.0からのSystem.Reflection-preview1-24530-04から4.1.0。

RestSharpは4.1を使用していますが、AWSは.NetCoreApp1.0に対して4.3バージョンセットをサポートしています。

System.Runtime.Serialization.Primitives.4.3.0-preview1-24530-04に依存するバージョンはありますか？

.netコアに移行しましたが、.net標準2.0からRestSharpを参照できないことがわかりました。nugetパッケージのインストールに失敗します。

パッケージ「RestSharpSigned105.2.3」は、プロジェクトターゲットフレームワーク「.NETStandard、Version = v2.0」の代わりに「.NETFramework、Version = v4.6.1」を使用して復元されました。 このパッケージは、プロジェクトと完全に互換性がない可能性があります。
パッケージの復元に失敗しました。 のパッケージ変更のロールバック

@trampsterあなたはステータスを誤解していると思います。 公式のRestSharpパッケージは.NETStandardをサポートしておらず、最終更新日は2015年です。alexeyzimarevが取り組んでいる変換はまだ公開されていません。

私はそれに対する需要があることを示すのを助けるために投稿していたことを理解しています。 また、.net Standard2.0のリリース時にMicrosoftが発表した.netStandard2.0から.netフルdllを参照するための.NETFramework互換モードがここでは機能しないことを示します。 したがって、回避策はなく、ブロックされます。

別のRestライブラリに移行する必要はありませんが、必要に応じて移行します。 これは、この変換にかかる時間によって異なります。

興味深いことに、nuget https://www.nuget.org/packages/RestSharp.NetCoreに98,895ダウンロードのRestSharp.NetCoreパッケージがありますが、アップローダーがプロジェクトに関連付けられていないことがわかる限り、わかりません。私がそれを信頼できれば。

@trampsterこれは（抑制される可能性のある）Nuget警告です。既存の.NETFramework

最後の行をもう一度見てください。 それをロールバックしました。 その後、RestSharpへの参照はありません。

また、私の投稿を読むと、netcore2.0やv4.6.1ではなく.net標準2.0から使用しようとしていることがわかります。

警告にはv4.6.1が使用されたと記載されていますが、RestSharpnugetパッケージにはv4.6.1が含まれていないことにも注意してください。

@trampster互換性ブリッジを使用してHttpWebRequest使用量に要約されるランタイム例外が発生します。 NuGetパッケージのインストールに失敗しなかったので、それは奇妙です。 😃

私もこれに遭遇しています：\

.NET Coreアプリで現在のnugetパッケージを使用できるのは、完全なフレームワークをターゲットにしている場合のみです。

新しい.NETCoreコンソールアプリを作成し、パッケージマネージャーからInstall-Package RestSharp -Version 105.2.3を実行して、次のコードを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）;
`` `

netcoreapp2.0をターゲットにするとSystem.PlatformNotSupportedException: Operation is not supported on this platform.が得られますが、csprojで<TargetFramework>net46</TargetFramework>に変更すると機能します。

完全なフレームワークを対象としていません

@niemyjskiこのライブラリが更新されるのを待つ間、 RestSharp.NetCoreを試してみてください。 以下のライブラリで使用されているため、十分に安定して使用できるはずです。

ADH.PushCore
AppVeyorSharp
CoreLib.Web
CouchDB.Client
DocuSign.NetCore
Flip.PomboCorreio.Connector
FluentEmail.Mailgun
GiphyApiClient.NetCore
Intercom.Core
IronSphere.Henchmen
MasterCard-コア-非公式
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
プッシャー-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

RestSharp.NetCoreのアップローダーが誰であるか知っている人はいますか？ 私はそこでgithubを見ましたが、RestSharpのフォークがありません。 パッケージにはライセンスが記載されていません。悪意があることはわかっています。

このプロジェクトを所有している人は、restsharpパッケージの名前空間の所有権を探す必要があります...そしておそらくそのパッケージを上場廃止にする必要があります。 逆コンパイルすることで、そのパッケージに悪意のあるコンテンツが含まれているかどうかを確認できます。

2017年10月5日午後10時57分、

@niemyjski （https://github.com/niemyjski）このライブラリが更新されるのを待つ間、RestSharp.NetCore（https://www.nuget.org/packages/RestSharp.NetCore/）を試してみてください。 以下のライブラリで使用されているため、十分に安定して使用できるはずです。

ADH.PushCore
AppVeyorSharp
CoreLib.Web
CouchDB.Client
DocuSign.NetCore
Flip.PomboCorreio.Connector
FluentEmail.Mailgun
GiphyApiClient.NetCore
Intercom.Core
IronSphere.Henchmen
MasterCard-コア-非公式
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
プッシャー-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

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHub（https://github.com/restsharp/RestSharp/issues/992#issuecomment-334651808）で表示するか、スレッドをミュートします（https://github.com/notifications/unsubscribe-auth / AA-So9HrYQHV5nlV1m7W7eY-y_F5cBqqks5spaUXgaJpZM4PLH2m）。

@alexeyzimarevは、プレリリースのnugetパッケージを今日入手する可能性はありますか？ ベータ版であり、すべてのテストが機能している場合でも、他のいくつかの点が変更される可能性があります。

悲しいRESTsharpはCore2.0では動作しません。 HttpClientに戻ったと思います

@niemyjskiいいえ、ごめんなさい。 WebRequestをHttpClientに変更していますが、これは大きな変更です。 これは、WebRequestがnetstandard 2.0でのみ使用可能であり、1.6をサポートしたいためです。

@niemyjski支援が必要な場合は、変更を別のブランチに公開できます-

私は実際にnetstandard2.0に切り替えました。 netstandard1.6は手間がかかりすぎるようです。 しかし、私はまだHttpClientを使用したいと思います。

これをチェックしてください： //github.com/restsharp/RestSharp/tree/netstandard
PRは大歓迎です。

@amivitあなたはそれを実現するためにあなたの時間のいくらかを貢献することができますよね？

WebRequestをHttpClientに変更していますが、これは大きな変更です。 これは、WebRequestがnetstandard 2.0でのみ使用可能であり、1.6をサポートしたいためです。

System.Net.Requests nugetパッケージがあるため、これは誤ったステートメントです。

最初はWebRequestを使い続けてから、時間の経過とともにHttpClientに移行するのは難しいでしょうか。

@mguinnessこのパッケージを使ってみましたか？ やった。

@mguinness言うことができます

申し訳ありませんが@alexeyzimarev貢献する時間がありません。 私は望む。 RESTsharpがそもそもHttpClientに依存していないことに驚いています。 2012年または.NET4.5以降、WebClientよりも改善されていませんか？

@amivitおそらく、壊れていない場合は、修正しないでください。

ここでミミミだけでごめんなさい：rofl：
しかし、クライアントアプリケーションを.net core 2.0にアップグレードした後、RestSharpに関するいくつかの警告が表示されます。

警告NU1603：RestSharp.NetCore 105.2.3はSystem.Runtime.Serialization.Formatters（> = 4.0.0-rc4-24217-03）に依存していますが、System.Runtime.Serialization.Formatters4.0.0-rc4-24217-03は依存していませんでした見つかった。 System.Runtime.Serialization.Formatters4.3.0-preview1-24530-04のおおよそのベストマッチが解決されました。

私は今のところアプリケーションを実行しようとしませんでした-私はそれが機能しないと思います。
そのため、RestSharpはまだ.net Core2.0をサポートしていません。 しかし、いつかはそうなるのでしょうか。 すでに日付はありますか？ これを実現するために（寄稿者として）ここで支援できますか？

@matthiasburgerはnetstandardブランチをチェックします。 私はあなたのコメントの上にこれをほんの数件の投稿で述べました。

今のところ2.0で行ってください。 後でいつでもhttpクライアントに変更できます...また
syncメソッドを持たせるためのコンパイラ指令があることを確認してください
（フレームワーク）

ありがとう
-Blake Niemyjski

6時43分AMで水曜日、2017年10月11日には、アレクセイZimarev [email protected]
書きました：

@matthiasburgerhttps ： //github.com/matthiasburgerネットスタンダードを確認してください
ブランチ。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/restsharp/RestSharp/issues/992#issuecomment-335782906 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AA-So8akA6MlKfoypWDSAqaElcYBPFoAks5srKnUgaJpZM4PLH2m
。

sry @ alexeyzimarev時々私はすべてを読む必要があります-素晴らしい。 私はそれを見てみます:)

@niemyjskiすべてのプラグマディレクティブが削除されます。 プラットフォームやフレームワークなどごとに偏差が生じたくないのです。これはnetstandardが解決することを宣言しているものであり、これを使用します。

さて、 netstandardブランチは、署名付きと署名なしの両方でビルドされるようになりました。 それでも失敗する4つのテストがあります（エンコード、デコード）。 統合テストはまだ含まれていません。 今週コードを完成させることができれば幸いですが、ビルドとパックを行うには、DotNetCliに切り替えるためにさらに作業が必要になります。

わかりました、すべてうまくいくようです。 HttpListener（統合）からのサポートされていない例外のため、条件付きで2つのテストを無視する必要がありました。 適切なサーバーで使用すると、動作することを期待してください。

ここで、ビルドスクリプトを変更して、DotNetCliを使用し、nuget.exeの使用を停止する必要があります。

素晴らしい仕事を続けてください@alexeyzimarev！ 最初のリリースが待ちきれません👍

https://www.nuget.org/packages/RestSharp/106.0.0-alpha0277をテストして

VS2017および.NETCore2.0を対象とする実際のIISで106.0.0-alpha0277をテストしました

ErrorException：System.PlatformNotSupportedException：このプラットフォームでは操作はサポートされていません。
System.Net.SystemWebProxy.GetProxy（Uri宛先）で
System.Net.ServicePointManager.ProxyAddressIfNecessary（Uri＆アドレス、IWebProxyプロキシ）で
System.Net.ServicePointManager.FindServicePoint（Uriアドレス、IWebProxyプロキシ）で
System.Net.HttpWebRequest.get_ServicePoint（）で
RestSharp.Http.ConfigureWebRequest（Stringメソッド、Uri url）で
RestSharp.Http.PostPutInternal（Stringメソッド）で
RestSharp.Http.AsPost（String httpMethod）で
RestSharp.RestClient.DoExecuteAsPost（IHttp http、Stringメソッド）で
RestSharp.RestClient.Execute（IRestRequest request、String httpMethod、Func`3 getResponse）で

彼らが時間の経過とともに多くのIsXYZメソッドを追加したことを私は知っています、おそらくこれらのメソッドを呼び出すか、それらをラップする前にそれらをチェックする必要がありますか？

Linuxでこれらのテストを実行し始めると、Windowsよりも多くの問題が見つかると思います。

@ maciek12305どうやってそこに

@niemyjski Linuxでテストを実行することに同意しますが、これには新しいCIビルドをセットアップする必要があります。 後で、できれば来週、Travisを見ていきます。

プロキシの問題のようですhttps://github.com/Azure/azure-iot-sdk-csharp/issues/140

問題は、デフォルトプロキシの設定がレジストリから読み込まれるため、.NETCoreがデフォルトプロキシをサポートしていないことです。

したがって、プロキシを使用しない場合は機能するはずであり、プロキシを使用すると.NETCoreでクラッシュします。 今のところ、すべてをバイパスして直接移動するという「デフォルトプロキシ」クラスを追加しました。 プロキシを使用する必要がある場合は、 ConfigureProxyメソッドを使用してプロキシを提供する必要があります。

最新のパッケージをお試しください： https ：

@niemyjski実際、統合テストはMacで問題なく合格します。 したがって、Linuxでも機能するはずです。

@alexeyzimarev最新のパッケージは

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

@mguinnessでは、なぜ古い値（それが何であるかわからない）をproxy変数に保持するのですか？ 違いを生むことができる唯一の行は

WebRequest.DefaultWebProxy = null;

これが助けになるなら、私はそれを簡単に追加することができます。

@alexeyzimarevフレームワークに「WebRequest.DefaultWebProxy：以前のGetがないとセットが機能しない」という修正をコミットするバグがありました。

今、私は分かる。 デフォルトのプロキシプロパティを操作する代わりに、リクエストのプロキシプロパティをnullに設定してパッケージを作成してみることができます。

@mguinness新しいパッケージが出ました、助けてくれてありがとう！

@mavanmanen UWPでこれも試してみませんか？ https://www.nuget.org/packages/RestSharp/106.0.0-alpha0282

バージョン106.0.0-alpha0282では、同じエラー「このプラットフォームでは操作はサポートされていません。」

@remiskauneこれらの行をコードに

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

ありがとう。 バージョン106.0.0-alpha0282でこの行で動作するようになりました。

だから問題は、RestSharpコードにこれらの行を含めたので、なぜそれなしでは機能しないのかということです...

おそらくWebRequestのスコープは異なりますか？ それは静的クラスですか、それともインスタンス化されていますか？

サンプルアプリを作成することで確認できます。サンプルアプリで、次のことを確認してください。

WebRequest.DefaultWebProxy

また、RestSharpが表示している値を送信するためのメソッドを公開します（デバッグ目的で）-例：

public IWebProxy GetCurrentProxy() => WebRequest.DefaultWebProxy;

2つが異なるかどうかを確認しますか？

@qJake誰かが私のためにデバッグしてくれれば

WebRequest.DefaultProxyをnullに割り当てることにより、プロキシの問題が「修正」された新しいパッケージが利用可能です。 これは結果をもたらしたかもしれませんが、私は実際の問題を期待していません。 回避策は、.NET標準アセンブリにのみ追加されます。 .NETFrameworkアセンブリは以前と同じように機能するはずです。
https://www.nuget.org/packages/RestSharp/106.0.0-alpha0284

問題が報告されない場合は、リリースの準備を開始します。

ここでかなり肯定的な反応。 私は依存パッケージ（Atlassian.JIRA）を機能させようとして遊んでいましたが、.NET標準2.0をターゲットにした場合、すべての統合/単体テストは「機能した」のでLGTMでした。

その最後のスレッドについては、 https：//bitbucket.org/farmas/atlassian.net-sdk/issues/306/support-for-dotnet-core 。

私はそれを私たちのソリューションに対してテストしました、そしてそれはうまくいきます。

.net標準2.0プロジェクトと.net4.6.1プロジェクトから使用しています

.net4.6.1から使用する場合。 ビジュアルスタジオが黄色の感嘆符でマークする次の参照をプルするプロジェクト。
System.Net.Http
System.Runtime.Serialization.Primitives
System.Security.Cryptography.Algorithms
System.Security.Cryptography.Encoding
System.Security.Cryptography.Primitives
System.Security.Cryptography.X509Certificates

理由はわかりませんが、問題はないようです。

私たちが抱えている小さな問題の1つは、clickonceを使用してツールの1つを配布しているため、すべてに強い名前を付ける必要があることです。 ただし、プレリリースバージョンは厳密な名前ではありません。 パッケージのRestSharpSignedバージョンを使用していますが、.net標準をサポートするプレリリースバージョンはありません。

強い名前付きバージョンと強い名前なしバージョンがあると、強い名前付きバージョンに依存する依存関係と、強い名前なしバージョンに依存する依存関係が2つある状況で問題が発生する可能性があります。

これの代わりに、署名されてアセンブリバージョンのメジャーバージョンにフリーズする1つのパッケージを用意し（SemVerでは、互換性が失われた場合にのみメジャーバージョンが変更されます）、FileVersionで完全なSemVerを使用することをお勧めします。 このようにして、誰もが使用できる1つのnugetパッケージ（強い名前が付けられているかどうかに関係なく）があり、メジャーバージョンのフリーズは、バインディングリダイレクトが不要であることを意味します。 また、SemVerを使用するということは、互換性の観点から、誰もが自分の立場を正確に把握していることを意味します。

.net標準への切り替えは、この変更を行うのに適した時期である可能性があるため、ここでこれをお勧めします。

デフォルトでパッケージに署名し、キーをGitHubに配置する必要があります。.netチームは、何も害を及ぼさないため、これをお勧めします。

変更を確認できるPRはありますか？

@niemyjski developブランチがすべての人に表示されると思います。 私もそれをデフォルトのブランチにしました。

この場合、 @ niemyjski 「Just」は機能しません。 あなたが助けたいなら-してください。 nugetのバグが原因でソリューションのビルド全体が失敗するため、 Signedプロジェクトを削除する必要がありました。
https://github.com/dotnet/standard/issues/538
https://github.com/NuGet/Home/issues/6038

したがって、修正されるまで待つか、別のソリューションとプロジェクトを追加してから、すべてのファイルを手動で含める必要があります。これは厄介です。

@alexeyzimarevには

2つのバージョンを維持することを主張する場合（ユーザーに問題が発生します）、構成を介して1つのcsprojでこれを行うことができます。

2つのバージョンがあることがどれほど壊れているかに気付く前に、私はもともと自分のプロジェクトでこれを行いました（そしてそれは機能しました）。 基本的に、StrongNameプロパティグループを追加しました。 次に、dotnet build -cStrongNameを使用してビルドします

<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>

提起した問題の修正を待つ場合は、長い間待つ可能性があります。

これはあなたのすべての問題を解決します。

私はそれが大好きです。

プロパティグループの提案は貴重です。 私は2つのパッケージを保持しようとします。そうしないと、混乱が生じます。 私は間違っているかもしれませんが、個人的には署名を避けます。 しかし、あなたはそれを必要としているので、私は署名されたアセンブリでパッケージを作ろうとします。

@niemyjski 「.netチームがこれをお勧めします」へのリンクはありますか？ 私は結果について、そして彼らがこれを行うことをどのように正確に示唆しているかについてもっと知る必要があります。

私は彼らと話をしました、そして私は彼らがそれを公に言ったことも知っています
フォーラムとたるみ。 これは一種の冗談であり、削除する必要があります（
https://twitter.com/terrajobst/status/774752534682402817）..
アセンブリに強い名前を付けます...すべてのアセンブリに強い名前を付けます
冗談なので、署名snkをリポジトリに残します。 16進エディタを持っている人
強い名前の署名をバイパスすることができ、それは必要な人だけを傷つけます
パッケージに依存関係を持たないように署名します。 あなたは強いを参照することができます
署名されていないパッケージから署名されたパッケージなので、すべてに署名してみませんか
時間。

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

ありがとう
-Blake Niemyjski

午後1時30分水曜日、2017年11月1日には、アレクセイZimarev [email protected]
書きました：

@niemyjski https://github.com/niemyjski "The.netへのリンクはありますか
チームはこれをお勧めします」？私は結果とその方法についてもっと知る必要があります
まさに彼らはこれを行うことを提案しています。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/restsharp/RestSharp/issues/992#issuecomment-341197289 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AA-So94xh-jiEMniw0D2QaGQPgT9zfBfks5syLjDgaJpZM4PLH2m
。

はい、署名します。

リリースされました。 https://www.nuget.org/packages/RestSharp/106.0.0

ここgithubでリリースタグを作成する必要があります。 :)

タグ付き

106.1.0のリリースノートには次のように記載されています。
「.NETCoreのプロキシの問題を修正しました」

その修正が何をカバーするかはわかりませんが、プロキシの使用にはまだ問題があります。
.NET Core 2.0ポート（.NET Framework 4.6.1から提供）の前は、このようにクライアントをインスタンス化し、それは魅力のように機能しました。

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

.NET Core 2.0プロジェクトで同じコードを使用すると、次の応答エラーが発生します。

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

リクエストを発行するコードは次のようになります。

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

何かご意見は？

THX、
フレッド

.NET Core 2.0の動作するコードはありますか？

スタックトレースをチェックすると、これは例外ではなく、デフォルトのプロキシを取得しようとしたときの.NET例外であることがわかります。

はい、その通りです@alexeyzimarev 、例外は通常System.Net.SystemWebProxy.GetProxyでスローされます、私はトリガーをすばやく実行しました。 :)

同じ問題が発生している他のユーザーの場合、次のように使用するプロキシを明示的に指定できます。

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

.NET Core 2.0で106.1.0から106.2.0にアップグレードしましたが、次のメッセージが表示され始めました。

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

他の人が述べたように、このメッセージはSystem.Net.SystemWebproxy.GetProxyによって生成されたようですが、私のインスタンスでは、プロキシを明示的に構成していません。内部的には独自の操作を実行し、要求するたびに例外をスローします。

106.1.0に戻って、これで修正されたので、プロキシ設定を何らかの方法で明示する必要がある106.2.0で何か変更がありますか？

@voiceboothこれは＃1061で報告されています