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. version, чтобы нам не пришлось переходить на новую библиотеку REST.

@qJake Поскольку .NET Standard 2.0 имеет значительно расширенную поверхность API, конечно, HttpWebRequest можно было бы сохранить вместо переключения на HttpClient. Может быть, проблем с прокладкой больше нет?

Почему .NET Standard 2.0? Пожалуйста, подумайте о том, чтобы настроить таргетинг на самую низкую доступную версию.

@mguinness См. этот комментарий в проекте @ dotnet / corefx - HttpWebRequest не является частью .NET Standard, в System.Net.Http.HttpClient .

Пожалуйста, подумайте о поддержке текущей версии UWP. (до обновления Fall Creators Update)

Текущая версия UWP будет означать netstandard1.4. Не уверен, к каким последствиям это приведет, нужно начинать экспериментировать.

@qJake Хорошо, что HttpWebRequest находится в .NET Standard 2.0, ваше утверждение верно только для .NET Standard 1.6 и ниже.

@mguinness О, я понимаю - что ж, тогда это представляет проблему - поскольку RestSharp использует HttpWebRequest / Response, поддерживаем ли мы только .NET Standard 2.0 и придерживаемся этих классов, или мы реорганизуем базовый клиент и переключаемся на HttpClient , что позволяет нам поддерживать старые версии .NET Standard?

Люди хотят 1.4 из-за проблем с текущей версией UWP. NETStandard 2.0 будет поддерживаться только в UWP vNext.

@qJake FWIW, есть также пакет nuget System.Net.Requests , который можно использовать в более ранних версиях .NET Standard.

Привет, ребята, есть какие-нибудь новости или предполагаемое время прибытия? Планирую использовать RestSharp в моем приложении dotnet core 2, и я не хотел бы переключать пакеты.

Работа продолжается. Устаревший материал был удален, но мы, вероятно, также будем участвовать в выпуске JSON.NET. Будьте на связи.

НЗП: https://github.com/alexeyzimarev/restsharp/tree/netstandard

Мне нужно использовать его для AWS Lambda, но при использовании RestSharp.NetCore 105.2.3 AWS возвращает ошибки
- Обнаружено понижение версии пакета: System.Reflection с 4.3.0-preview1-24530-04 на 4.1.0.

Означает, что RestSharp использует 4.1, но AWS поддерживает набор версий 4.3 для .NetCoreApp 1.0.

У нас версия с зависимостью от System.Runtime.Serialization.Primitives.4.3.0-preview1-24530-04?

Мы переходим на ядро ​​.net и только что обнаружили, что не можем ссылаться на RestSharp из стандарта .net 2.0, пакет nuget не может быть установлен.

Пакет RestSharpSigned 105.2.3 был восстановлен с использованием .NETFramework, Version = v4.6.1 вместо целевой платформы проекта .NETStandard, Version = v2.0. Этот пакет может быть не полностью совместим с вашим проектом.
Не удалось восстановить пакет. Откат изменений пакета для

@trampster Я думаю, вы неправильно поняли статус. Официальный пакет RestSharp не поддерживает .NET Standard и последний раз обновлялся в 2015 году. Преобразование, над которым работал Алексейзимарев, еще не опубликовано AFAIK.

Насколько я понимаю, я разместил сообщение, чтобы указать, что на него есть спрос. Также, чтобы показать, что режим совместимости .NET Framework для ссылки на полные библиотеки DLL из .net стандарта 2.0, объявленный Microsoft при выпуске стандарта .net 2.0, здесь не работает. Так что обхода нет, мы заблокированы.

Мы бы предпочли не переходить на другую библиотеку Rest, но при необходимости сделаем это. Это будет зависеть от того, сколько времени займет это преобразование.

Интересно, что на nuget https://www.nuget.org/packages/RestSharp.NetCore есть пакет RestSharp.NetCore с 98 895 загрузками, однако, насколько я могу судить, загрузчик не связан с проектом, поэтому я не знаю если я могу этому доверять.

@trampster Это предупреждение nuget (которое можно подавить), см. Повторное использование существующей библиотеки .NET Framework . Также какова ваша целевая структура в вашем csproj, это netcoreapp2.0 или v4.6.1?

Взгляните еще раз на последнюю строку. Откатил. Впоследствии у меня нет ссылки на RestSharp.

Также, если вы прочтете мой пост, вы увидите, что я пытаюсь использовать его из стандарта .net 2.0, а не из netcore2.0 или v4.6.1.

Также следует отметить, что в предупреждении говорится, что использовалась версия 4.6.1, но пакет Nuget RestSharp не имеет версии 4.6.1.

@trampster Я успешно установил его в приложение .NET Core 2.0 с помощью моста совместимости, но когда я запускаю его, я получаю исключение времени выполнения, которое сводится к использованию HttpWebRequest . У меня не было сбоев при установке пакетов NuGet, так что это странно. 😃

Я тоже сталкиваюсь с этим: \ @alexeyzimarev, чем сообщество может помочь. Нам это нужно, и мы все заблокированы на этом. Я запускаю пакет OAuth2, который использует эту библиотеку, и все также заблокированы от ее использования.

Использование текущего пакета nuget в приложении .NET Core возможно только в том случае, если вы нацеливаетесь на полную платформу.

Я создал новое консольное приложение .NET Core, запустил Install-Package RestSharp -Version 105.2.3 из диспетчера пакетов и добавил в Main следующий код:

`` С #
var client = new RestClient ();
client.BaseUrl = новый Uri ("https://api.github.com/");

var request = new RestRequest ();
request.Resource = "пользователи / restsharp / repos";

var response = client.Execute (запрос);
`` ''

Нацеливание на netcoreapp2.0 даст System.PlatformNotSupportedException: Operation is not supported on this platform. но оно будет работать, если вы измените значение на <TargetFramework>net46</TargetFramework> в csproj.

Мы не ориентируемся на полную структуру

@niemyjski Может быть, попробуйте RestSharp.NetCore, пока вы ждете, пока эта библиотека обновится. Он используется следующими библиотеками, поэтому должен быть достаточно стабильным для использования.

ADH.PushCore
AppVeyorSharp
CoreLib.Web
CouchDB.Client
DocuSign.NetCore
Flip.PomboCorreio.Connector
FluentEmail.Mailgun
GiphyApiClient.NetCore
Домофон. Ядро
IronSphere.Henchmen
MasterCard-Core-Неофициальный
mbank-dotnet
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Интернет-сайты.
толкатель-http-dotnet-core
RepositoryFramework.Api
RepositoryFramework.EntityFramework
RestSharp.Newtonsoft.Json
RestSharp.Newtonsoft.Json.NetCore
Slack.Webhooks.Core
StoneCo.PomboCorreio.Разъем
SwitchAPI.Connector
Syncromatics.Clients.Metro.Api
TransportApi.Sdk.NetCore
Twilio.NetCore
UtilityFramework.Application.Core
UtilityFramework.Services.Iugu.Core

Кто-нибудь знает, кто загрузил RestSharp.NetCore? Я посмотрел там github, и у них нет форка RestSharp. В пакете нет лицензии, насколько я знаю, это вредоносная программа.

Тот, кто когда-либо владеет этим проектом, должен получить право собственности на пространство имен пакета restsharp ... и, вероятно, исключить этот пакет из списка. Я бы, вероятно, посмотрел, содержит ли этот пакет какой-либо вредоносный контент, декомпилировав его

5 октября 2017 г. в 22: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
Домофон. Ядро
IronSphere.Henchmen
MasterCard-Core-Неофициальный
mbank-dotnet
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Интернет-сайты.
толкатель-http-dotnet-core
RepositoryFramework.Api
RepositoryFramework.EntityFramework
RestSharp.Newtonsoft.Json
RestSharp.Newtonsoft.Json.NetCore
Slack.Webhooks.Core
StoneCo.PomboCorreio.Разъем
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 есть ли шанс получить предварительную версию пакета

К сожалению, RESTsharp не работает с Core 2.0. Думаю, он вернулся к HttpClient

@niemyjski Нет, извините. Я меняю WebRequest на HttpClient, и это большое изменение. Причина этого в том, что WebRequest доступен только для netstandard 2.0, а мы хотим поддерживать 1.6.

@niemyjski Я могу опубликовать свои изменения в отдельной ветке, если вы хотите помочь -

Я фактически перешел на netstandard 2.0. netstandard 1.6 кажется слишком трудоемким. Но я все еще хочу использовать HttpClient.

Проверьте это: https://github.com/restsharp/RestSharp/tree/netstandard
PR приветствуются.

@amivit Вы можете

Я меняю WebRequest на HttpClient, и это большое изменение. Причина этого в том, что WebRequest доступен только для netstandard 2.0, а мы хотим поддерживать 1.6.

Это неверное утверждение, поскольку существует пакет nuget System.Net.Requests .

Будет ли сложно сначала придерживаться WebRequest, а затем со временем перейти на HttpClient?

@mguinness Вы пробовали использовать этот пакет? Я сделал.

@mguinness Можно сказать - забудьте 1.6, мы перейдем на 2.0 и сохраним WebRequest. Лично меня это устраивает.

Извините, @alexeyzimarev, у меня нет времени вносить свой вклад. Хотел бы я. Я просто удивлен, что RESTsharp изначально не полагается на HttpClient. Разве это не было улучшением по сравнению с WebClient с 2012 года или .NET 4.5?

@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.Formatters 4.0.0-rc4-24217-03 не был нашел. Было решено приблизительное наилучшее соответствие System.Runtime.Serialization.Formatters 4.3.0-preview1-24530-04.

Запустить приложение пока не пробовал - думаю, не получится.
Итак, RestSharp еще не поддерживает .net core 2.0. Но будет ли это когда-нибудь? Уже есть свидание? Могу ли я помочь в этом (как участник)?

@matthiasburger проверьте ветку netstandard. Я упомянул об этом всего несколькими постами над вашим комментарием.

А пока переходите на 2.0. Всегда можно изменить его позже на http-клиент ... Также
убедитесь, что у вас есть директивы компилятора, чтобы у него были методы синхронизации
(ФРЕЙМВОРК)

Спасибо
-Блейк Немийски

11 октября 2017 г., среда, 6:43, Алексей Зимарев [email protected]
написал:

@matthiasburger https://github.com/matthiasburger проверьте netstandard
ветвь.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/restsharp/RestSharp/issues/992#issuecomment-335782906 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AA-So8akA6MlKfoypWDSAqaElcYBPFoAks5srKnUgaJpZM4PLH2m
.

sry @alexeyzimarev иногда мне нужно все прочитать - отлично. Я смотрю :)

@niemyjski Все директивы pragma удалены. Я не хочу иметь никаких отклонений в зависимости от платформы, фреймворка и т. Д. Это то, что netstandard заявляет для решения, и я собираюсь это использовать.

Итак, теперь ветка netstandard строится как для подписанных, так и для неподписанных. Тем не менее у меня есть четыре неудачных теста (кодирование, декодирование). Интеграционные тесты еще не включены. Надеюсь, я смогу закончить код на этой неделе, но сборка и упаковка потребуют дополнительной работы, чтобы переключиться на DotNetCli.

Хорошо, вроде все работает. Мне пришлось условно проигнорировать два теста из-за неподдерживаемых исключений из HttpListener (интеграция). Ожидайте, что это сработает при использовании с правильным сервером.

Теперь необходимо изменить скрипт сборки, чтобы использовать DotNetCli и прекратить использование nuget.exe.

Продолжайте в том же духе, @alexeyzimarev! Не могу дождаться первого релиза 👍

Пожалуйста, проверьте https://www.nuget.org/packages/RestSharp/106.0.0-alpha0277

Протестировано 106.0.0-alpha0277 в VS2017 и реальных IIS, ориентированных на .NET Core 2.0.

ErrorException: System.PlatformNotSupportedException: операция не поддерживается на этой платформе.
в System.Net.SystemWebProxy.GetProxy (пункт назначения Uri)
в System.Net.ServicePointManager.ProxyAddressIfNeeded (Uri и адрес, прокси IWebProxy)
в System.Net.ServicePointManager.FindServicePoint (адрес Uri, прокси-сервер IWebProxy)
в System.Net.HttpWebRequest.get_ServicePoint ()
в RestSharp.Http.ConfigureWebRequest (метод String, URL-адрес Uri)
в RestSharp.Http.PostPutInternal (метод String)
в RestSharp.Http.AsPost (String httpMethod)
в RestSharp.RestClient.DoExecuteAsPost (IHttp http, метод String)
в RestSharp.RestClient.Execute (запрос IRestRequest, String httpMethod, Func`3 getResponse)

Я знаю, что они добавили много методов IsXYZ сверхурочно, возможно, нам нужно проверить их, прежде чем вызывать эти методы или упаковывать их?

Было бы хорошо запустить эти тесты под Linux, так как я думаю, что он обнаружит гораздо больше проблем, чем в Windows.

@ maciek12305, здесь недостаточно скопировать и вставить исключение, так как я понятия не имею, как вы туда попали.

@niemyjski Я согласен проводить тесты в Linux, но для этого требуется настройка новой сборки CI. Я посмотрю на Трэвиса позже, надеюсь, на следующей неделе.

Похоже на проблему с прокси https://github.com/Azure/azure-iot-sdk-csharp/issues/140

Хорошо, проблема в том, что .NET Core не поддерживает прокси по умолчанию, потому что настройки прокси по умолчанию загружаются из реестра.

Таким образом, он должен работать, если вы не используете прокси, и он выйдет из строя на .NET Core, если используется прокси. На данный момент я добавил класс «прокси по умолчанию», который говорит, что нужно все обойти и перейти напрямую. Если вам нужно использовать прокси - вам нужно будет предоставить его с помощью метода ConfigureProxy .

Пожалуйста, попробуйте последний пакет: https://www.nuget.org/packages/RestSharp/106.0.0-alpha0281

@niemyjski На самом деле интеграционные тесты на Mac проходят нормально. Полагаю, он должен работать и в Linux.

@alexeyzimarev Последний пакет не работал у меня на Win 10. Единственный способ заставить его работать - это включить в свой код следующее:

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

@mguinness, так почему вы сохраняете старое значение (не знаете, что это такое) в переменной proxy ? Думаю, единственная строка, которая может иметь какое-то значение, - это

WebRequest.DefaultWebProxy = null;

Я легко могу добавить это, если это поможет.

@alexeyzimarev Во фреймворке была ошибка, из-за которой "WebRequest.DefaultWebProxy: Set не работает без предыдущего исправления Get".

Теперь я понимаю. Я могу попробовать создать пакет с установкой для свойства Proxy запроса значения 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;

Посмотрите, разные ли эти два?

@qJake Я был бы признателен, если бы кто-нибудь мог отладить для меня :) Я не смогу тратить на это время до следующей недели, буду говорить на конференции.

Доступен новый пакет, в котором проблема с прокси «исправлена» путем присвоения WebRequest.DefaultProxy значения null. Это могло иметь последствия, но я не ожидаю реальных проблем. Обходной путь добавляется только в сборку .NET Standard. Сборка .NET Framework должна работать как раньше.
https://www.nuget.org/packages/RestSharp/106.0.0-alpha0284

Если не будет сообщений о проблемах, я начну готовить релиз.

Здесь довольно положительный ответ. Я играл, пытаясь заставить работать зависимый пакет (Atlassian.JIRA) и предполагая, что я нацелился на стандарт .NET 2.0, тогда все их интеграционные / модульные тесты «просто работали», так что LG TM.

https://bitbucket.org/farmas/atlassian.net-sdk/issues/306/support-for-dotnet-core для потока на этом конце.

Я протестировал его с нашим решением, и оно хорошо работает.

Мы используем его из проектов .net standard 2.0 и проектов .net 4.6.1.

При использовании из .net 4.6.1. Проекты он использует следующие ссылки, которые Visual Studio помечает желтыми восклицательными знаками.
System.Net.Http
System.Runtime.Serialization.Primitives
System.Security.Cryptography.Algorithms
System.Security.Cryptography.Encoding
System.Security.Cryptography.Primitives
System.Security.Cryptography.X509Certificates

Я не уверен, почему это так, но, похоже, это не вызывает никаких проблем.

Единственная небольшая проблема, с которой мы сталкиваемся, заключается в том, что мы используем clickonce для распространения одного из наших инструментов, поэтому мы вынуждены строго именовать все. Однако предварительная версия не имеет строгого названия. Мы использовали версию пакета RestSharpSigned, но ее предварительной версии со стандартной поддержкой .net не существует.

Наличие версии со строгим именем и версии со строгим именем может быть проблематичным в ситуации, когда у вас есть две зависимости: одна зависит от версии со строгим именем, а другая - от версии со строгим именем.

Вместо этого я предлагаю иметь один пакет, который подписан и замораживается до основной версии вашей версии сборки (в SemVer основная версия изменяется только при нарушении совместимости), а затем использовать полный SemVer в вашей FileVersion. Таким образом, у вас есть один пакет nuget, который может использовать каждый (со строгим именем или без него), а замораживание основной версии означает, что перенаправления привязки не требуются. А использование SemVer означает, что каждый точно знает, где он находится с точки зрения совместимости.

Я предлагаю это здесь, потому что переход на стандарт .net может быть подходящим временем для внесения этого изменения.

Мы должны просто подписать пакет по умолчанию и поместить ключ в GitHub. Команда .net рекомендует это, так как это ничему не повредит.

Есть ли PR, что я могу просмотреть изменения?

@niemyjski Я предполагаю, что develop видна всем. Я тоже сделал это веткой по умолчанию.

@niemyjski "Просто" в этом случае не работает. Если хочешь помочь - пожалуйста. Мне пришлось удалить проекты Signed потому что они не могут выполнить сборку всего решения из-за ошибки в nuget.
https://github.com/dotnet/standard/issues/538
https://github.com/NuGet/Home/issues/6038

Так что либо мне нужно будет подождать, пока он будет исправлен, либо мне придется добавить отдельное решение и проекты, а затем включить все файлы вручную, что неприятно.

@alexeyzimarev имеет только один csproj и подпишет его,

Если вы настаиваете на сохранении двух версий (что вызовет проблемы для ваших пользователей), вы все равно можете сделать это с помощью одного csproj через конфигурацию.

Первоначально я сделал это в своем собственном проекте (и он работал), прежде чем я понял, насколько это плохо, если иметь две версии. В основном я добавил группу свойств StrongName. Затем выполните сборку с помощью 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>

Если вы будете ждать решения поднятых вами проблем, вы можете ждать очень долго.

Это решит все ваши проблемы.

Я просто люблю это.

Предложение группы свойств ценно. Я постараюсь оставить две упаковки, иначе это создаст путаницу. Возможно, я ошибаюсь, но лично я бы просто избегал подписания. Но раз уж он вам нужен - попробую сделать пакет с подписанной сборкой.

@niemyjski у вас есть ссылка на "Команда .net рекомендует это"? Мне нужно больше узнать о последствиях и о том, как именно они предлагают это сделать.

Я разговаривал с ними, и я знаю, что они также публично заявили об этом в
форумы и слабина. Это своего рода шутка и ее следует убрать (
https://twitter.com/terrajobst/status/774752534682402817) .. Лучше
просто строго назовите сборку ... Мы строго присваиваем имя всем нашим сборкам и
оставьте подписывающий snk в репо, так как это шутка. Любой, у кого есть шестнадцатеричный редактор
может обойти подписание строгого имени и вредит только тем, кто
подписывать свои пакеты от принятия зависимостей. Вы можете сослаться на сильную
подписанный пакет из неподписанного пакета, так почему бы просто не подписать его все
время.

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

Спасибо
-Блейк Немийски

1 ноября 2017 г., среда, 13:30, Алексей Зимарев [email protected]
написал:

@niemyjski https://github.com/niemyjski у вас есть ссылка на ".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 упоминается:
«Исправлена ​​проблема с прокси в .NET Core»

Не знаю, что это за исправление, но мы по-прежнему сталкиваемся с проблемами при использовании прокси.
До нашего порта .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);

Есть предположения?

Спасибо,
Фред

У вас есть рабочий код для .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;

Я обновился с 106.1.0 до 106.2.0 на .NET Core 2.0, и это сообщение начало появляться:

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

Как упоминалось другими, это сообщение, похоже, создается System.Net.SystemWebproxy.GetProxy, но в моем случае я вообще не настраиваю прокси явно, внутри он выполняет свои собственные операции и генерирует исключение при каждом запросе, который я делаю.

Я вернулся к 106.1.0, и это исправило его, так что что-то изменилось в 106.2.0, где настройки прокси должны быть каким-то образом явными?

@voicebooth, об этом сообщается в # 1061