938

Oferecer suporte ao .NET Standard 2.0 significaria oferecer suporte a todas estas plataformas :

• .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 (lançamento ainda este ano)

Ao executar RestSharp usando o shim de compatibilidade com versões anteriores , ele funciona na maior parte, há apenas problemas com a classe subjacente usada para invocar as chamadas HTTP - se o cliente HTTP foi trocado pelo novo HttpClient , ele deve funcionar.

Em uma nota pessoal, usamos RestSharp um pouco aqui em nosso escritório, e já estamos trabalhando em novas soluções baseadas em nuvem que são executadas usando ASP.NET Core, então realmente gostaríamos de ver RestSharp atualizado com o .NET mais recente versão para que não tenhamos que mudar para uma nova biblioteca REST.

@qJake Como o .NET Standard 2.0 tem uma superfície de API amplamente expandida, certamente HttpWebRequest poderia ser mantido em vez de alternar para HttpClient. Talvez os problemas que você teve com o shim não estejam mais presentes?

Por que .NET Standard 2.0? Considere atingir a versão mais baixa disponível.

@mguinness Veja este comentário no projeto @ dotnet / corefx - HttpWebRequest não faz parte do .NET Standard, mas System.Net.Http.HttpClient faz.

Considere oferecer suporte à versão atual UWP também. (antes da atualização dos criadores de outono)

A versão atual do UWP significaria netstandard1.4. Não tenho certeza de quais consequências isso vai trazer, preciso começar a experimentar.

@qJake Well HttpWebRequest está em .NET Standard 2.0, sua afirmação só é verdadeira para .NET Standard 1.6 e anteriores.

@mguinness Oh, entendo - bem, isso apresenta um desafio, então - uma vez que RestSharp usa HttpWebRequest / Response, oferecemos suporte apenas para .NET Standard 2.0 e permanecemos com essas classes, ou refatoramos o cliente subjacente e mudamos para HttpClient , permitindo-nos oferecer suporte a versões mais antigas do .NET Standard?

As pessoas querem 1.4 devido a problemas com a versão atual do UWP. NETStandard 2.0 só será compatível com UWP vNext.

@qJake FWIW, há também o pacote nuget System.Net.Requests que pode ser usado em versões anteriores do .NET Standard.

Ei pessoal, alguma atualização ou HEC sobre isso? Estou planejando usar RestSharp em meu aplicativo dotnet core 2 e não gostaria de trocar de pacote.

É um trabalho em andamento. O material legado foi removido, mas provavelmente também teremos que trazer o JSON.NET para o lançamento. Fique ligado.

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

Preciso usá-lo para AWS Lambda, mas ao usar RestSharp.NetCore 105.2.3 AWS retorna erros
- Downgrade do pacote detectado: System.Reflection de 4.3.0-preview1-24530-04 para 4.1.0.

Significa que RestSharp está usando 4.1, mas a AWS suporta o conjunto de versão 4.3, para .NetCoreApp 1.0.

Temos uma versão com dependência de System.Runtime.Serialization.Primitives.4.3.0-preview1-24530-04?

Estamos migrando para o núcleo .net e acabamos de descobrir que não podemos fazer referência ao RestSharp do padrão .net 2.0, pois o pacote nuget não consegue instalar.

O pacote 'RestSharpSigned 105.2.3' foi restaurado usando '.NETFramework, Version = v4.6.1' em vez da estrutura de destino do projeto '.NETStandard, Version = v2.0'. Este pacote pode não ser totalmente compatível com o seu projeto.
A restauração do pacote falhou. Revertendo alterações de pacote para

@trampster Acho que você entendeu mal o status. O pacote RestSharp oficial não oferece suporte ao .NET Standard e foi atualizado pela última vez em 2015. A conversão que está sendo trabalhada por alexeyzimarev ainda não foi publicada AFAIK.

Eu entendo, estava postando para ajudar a indicar que há demanda para isso. Também para mostrar que o modo de compatibilidade do .NET Framework para referenciar .net dlls completos do .net padrão 2.0, conforme anunciado pela Microsoft ao lançar .net padrão 2.0, não está funcionando aqui. Portanto, não há solução, estamos bloqueados.

Preferiríamos não ter que mudar para outra biblioteca Rest, mas o faremos se precisarmos. Vai depender de quanto tempo levará essa conversão.

Curiosamente, há um pacote RestSharp.NetCore no nuget https://www.nuget.org/packages/RestSharp.NetCore com 98.895 downloads, no entanto, pelo que posso dizer, o uploader não está associado ao projeto, então eu não sei se eu puder confiar.

@trampster Esse é um aviso de nuget (que pode ser suprimido), consulte Reutilizando uma biblioteca .NET Framework existente . Além disso, qual é a sua estrutura de destino em seu csproj, é netcoreapp2.0 ou v4.6.1?

Dê uma segunda olhada na última linha. Ele rolou de volta. Depois disso, não tenho nenhuma referência ao RestSharp.

Além disso, se você ler minha postagem, verá que estou tentando usá-lo a partir do .net padrão 2.0 e não do netcore2.0 ou v4.6.1.

Também deve ser observado que o aviso diz que a v4.6.1 foi usada, mas o pacote nuget RestSharp não tem a v4.6.1

@trampster Eu instalei com sucesso em um aplicativo .NET Core 2.0 usando a ponte de compatibilidade, mas quando vou executá-lo, recebo uma exceção de tempo de execução que se resume a um uso de HttpWebRequest . Não obtive nenhuma falha de instalação do pacote NuGet, o que é estranho. 😃

Também estou encontrando: \ @alexeyzimarev como a comunidade pode ajudar. Precisamos disso e estamos todos bloqueados nisso. Eu executo o pacote OAuth2 que usa essa biblioteca e todos estão impedidos de usar isso também.

Usar o pacote nuget atual em um aplicativo .NET Core só é possível se você direcionar a estrutura completa.

Eu criei um novo aplicativo de console .NET Core, executei Install-Package RestSharp -Version 105.2.3 no Gerenciador de Pacotes e adicionei o seguinte código ao Principal:

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

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

var resposta = cliente.Executar (solicitação);
`` `

A segmentação de netcoreapp2.0 resultará em System.PlatformNotSupportedException: Operation is not supported on this platform. mas funcionará se você alterar para <TargetFramework>net46</TargetFramework> no csproj.

Não estamos almejando a estrutura completa

@niemyjski Talvez tente RestSharp.NetCore enquanto espera a atualização desta biblioteca. Ele está sendo usado pelas seguintes bibliotecas, portanto deve ser estável o suficiente para uso.

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

Alguém sabe quem é o uploader do RestSharp.NetCore? Eu olhei lá no github e eles não têm um fork do RestSharp. Não há licença listada no pacote, pelo que sei, é malicioso.

Quem quer que seja o proprietário deste projeto deve buscar a propriedade do namespace do pacote restsharp ... e provavelmente remover esse pacote. Provavelmente veria se esse pacote contém algum conteúdo malicioso descompilando-o

Em 5 de outubro de 2017 às 22h57,

@niemyjski (https://github.com/niemyjski) Talvez tente RestSharp.NetCore (https://www.nuget.org/packages/RestSharp.NetCore/) enquanto espera que esta biblioteca seja atualizada. Ele está sendo usado pelas seguintes bibliotecas, portanto deve ser estável o suficiente para uso.

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

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub (https://github.com/restsharp/RestSharp/issues/992#issuecomment-334651808) ou ignore o tópico (https://github.com/notifications/unsubscribe-auth / AA-So9HrYQHV5nlV1m7W7eY-y_F5cBqqks5spaUXgaJpZM4PLH2m).

@alexeyzimarev existe alguma chance de conseguir um pacote nuget de pré-lançamento hoje? Mesmo que seja uma versão beta e todos os testes estejam funcionando, algumas outras coisas podem mudar.

RESTsharp triste não funciona com Core 2.0. Acho que está de volta ao HttpClient

@niemyjski Não, desculpe. Estou mudando WebRequest para HttpClient e esta é uma grande mudança. A razão para isso é que WebRequest está disponível apenas para netstandard 2.0 e queremos oferecer suporte a 1.6.

@niemyjski posso publicar minhas alterações em um branch separado se você quiser ajudar-

Na verdade, mudei para o netstandard 2.0 agora. netstandard 1.6 parece ser muito trabalhoso. Mas ainda quero usar o HttpClient.

Confira: https://github.com/restsharp/RestSharp/tree/netstandard
PRs bem-vindos.

@amivit Você pode contribuir com um pouco do seu tempo para que isso aconteça, certo?

Estou mudando WebRequest para HttpClient e esta é uma grande mudança. A razão para isso é que WebRequest está disponível apenas para netstandard 2.0 e queremos oferecer suporte a 1.6.

Essa é uma declaração incorreta, pois existe o pacote nuget System.Net.Requests .

Seria difícil inicialmente manter o WebRequest e depois fazer a transição para o HttpClient ao longo do tempo?

@mguinness Você já tentou usar este pacote? Eu fiz.

@mguinness Podemos dizer - esqueça o 1.6, vamos para o 2.0 e mantemos o WebRequest. Pessoalmente, estou bem com isso.

Desculpe @alexeyzimarev , não tenho tempo para contribuir. Eu desejo. Estou surpreso que o RESTsharp não dependa do HttpClient para começar. Não tem sido uma melhoria disponível em relação ao WebClient desde 2012 ou .NET 4.5?

@amivit Provavelmente um caso de se não está quebrado, não conserte.

Desculpe por apenas mimimi aqui: rofl:
mas depois de atualizar meu aplicativo cliente para .net core 2.0, recebo alguns avisos sobre RestSharp:

aviso NU1603: RestSharp.NetCore 105.2.3 depende de System.Runtime.Serialization.Formatters (> = 4.0.0-rc4-24217-03), mas System.Runtime.Serialization.Formatters 4.0.0-rc4-24217-03 não era encontrado. Uma melhor correspondência aproximada de System.Runtime.Serialization.Formatters 4.3.0-preview1-24530-04 foi resolvida.

Não tentei executar o aplicativo agora - acho que não vai funcionar.
Portanto, RestSharp ainda não suporta .net core 2.0. Mas, será que algum dia? Já existe uma data? Posso ajudar aqui para que isso aconteça (como colaborador)?

@matthiasburger verifique o ramo padrão da rede. Mencionei isso apenas alguns posts acima do seu comentário.

Vá com 2.0 por enquanto. Sempre pode alterá-lo mais tarde para ser cliente http ... Também
certifique-se de ter as diretivas do compilador para que ele tenha os métodos de sincronização
(ESTRUTURA)

Obrigado
-Blake Niemyjski

Na quarta-feira, 11 de outubro de 2017 às 6h43, Alexey Zimarev [email protected]
escreveu:

@matthiasburger https://github.com/matthiasburger verifique o netstandard
filial.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/restsharp/RestSharp/issues/992#issuecomment-335782906 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AA-So8akA6MlKfoypWDSAqaElcYBPFoAks5srKnUgaJpZM4PLH2m
.

sry @alexeyzimarev às vezes eu deveria ler tudo - ótimo. Eu dou uma olhada nisso :)

@niemyjski Todas as diretivas pragma foram removidas. Não quero ter desvios por plataforma, framework, etc. Isso é o que o netstandard declara resolver e vou usar.

Ok, então netstandard branch agora é compilado para assinados e não assinados. Ainda tenho quatro testes que falham (codificação, decodificação). Testes de integração ainda não incluídos. Espero poder terminar o código esta semana, mas construir e empacotar exigirá um pouco mais de trabalho para mudar para DotNetCli.

Ok, tudo parece funcionar. Tive que ignorar condicionalmente dois testes por causa de exceções sem suporte do HttpListener (integração). Espere que funcione quando usado com um servidor adequado.

Agora, o script de construção precisa ser alterado para usar DotNetCli e parar de usar nuget.exe

Continue com o excelente trabalho @alexeyzimarev! Mal posso esperar pelo primeiro lançamento 👍

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

Testado 106.0.0-alpha0277 no VS2017 e IIS real voltado para .NET Core 2.0

ErrorException: System.PlatformNotSupportedException: a operação não é suportada nesta plataforma.
em System.Net.SystemWebProxy.GetProxy (destino Uri)
em System.Net.ServicePointManager.ProxyAddressIfNecessary (Uri e endereço, proxy IWebProxy)
em System.Net.ServicePointManager.FindServicePoint (endereço Uri, proxy IWebProxy)
em System.Net.HttpWebRequest.get_ServicePoint ()
em RestSharp.Http.ConfigureWebRequest (método String, url Uri)
em RestSharp.Http.PostPutInternal (método String)
em RestSharp.Http.AsPost (String httpMethod)
em RestSharp.RestClient.DoExecuteAsPost (IHttp http, método String)
em RestSharp.RestClient.Execute (solicitação IRestRequest, String httpMethod, Func`3 getResponse)

Eu sei que eles adicionaram muitos métodos IsXYZ ao longo do tempo, talvez precisemos verificá-los antes de chamar esses métodos ou envolvê-los?

Seria bom começar a executar esses testes no Linux, pois acho que encontraria muito mais problemas do que no Windows.

@ maciek12305 não é suficiente copiar e colar uma exceção aqui, pois não tenho ideia de como você chegou lá.

@niemyjski : Concordo com a execução de testes no Linux, mas isso requer a configuração de um novo build de CI. Olharei para Travis mais tarde, espero que na próxima semana.

Parece um problema com o proxy https://github.com/Azure/azure-iot-sdk-csharp/issues/140

Ok, o problema é que o .NET Core não oferece suporte ao proxy padrão porque as configurações do proxy padrão são carregadas do registro.

Portanto, ele deve funcionar se você não usar o proxy e travará no .NET Core se o proxy for usado. Por enquanto, adicionei a classe "proxy padrão", que diz para ignorar tudo e ir diretamente. Se você tiver que usar proxy - você terá que fornecê-lo usando o método ConfigureProxy .

Tente o pacote mais recente: https://www.nuget.org/packages/RestSharp/106.0.0-alpha0281

@niemyjski Na verdade, os testes de integração passam bem no Mac. Portanto, deve funcionar no Linux também, suponho.

@alexeyzimarev O pacote mais recente não funcionou para mim no Win 10. A única maneira de fazê-lo funcionar era incluir o seguinte em meu código:

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

@mguinness, então por que você mantém o valor antigo (não tenho certeza do que é) na variável proxy ? Acho que a única linha que pode fazer alguma diferença é a

WebRequest.DefaultWebProxy = null;

Posso adicioná-lo facilmente se isso ajudar.

@alexeyzimarev Houve um bug na estrutura que confirma "WebRequest.DefaultWebProxy: Set não funciona sem um Get anterior" correções.

Eu entendo agora. Posso tentar fazer um pacote definindo a propriedade Proxy de solicitação como nula em vez de manipular o padrão.

@mguinness o novo pacote foi lançado, obrigado por ajudar!

@mavanmanen você pode tentar este também, com UWP? https://www.nuget.org/packages/RestSharp/106.0.0-alpha0282

Com a versão 106.0.0-alpha0282 o mesmo erro "Operação não suportada nesta plataforma."

@remiskaune você tentou incluir essas linhas em seu código?

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

Obrigado. Agora funciona com essas linhas na versão 106.0.0-alpha0282.

Portanto, a questão é por que não funciona sem, já que incluí essas linhas no código RestSharp ...

Talvez WebRequest tenha um escopo diferente? É uma classe estática ou instanciada?

Você pode descobrir criando um aplicativo de amostra e, em seu aplicativo de amostra, verifique:

WebRequest.DefaultWebProxy

E também expor algum método para RestSharp enviar o valor que está vendo (para fins de depuração) - por exemplo:

public IWebProxy GetCurrentProxy() => WebRequest.DefaultWebProxy;

Veja se os dois são diferentes?

@qJake Eu agradeceria se alguém pudesse depurar para mim :) Não poderei gastar nenhum tempo nisso até a próxima semana, estarei falando em uma conferência.

Um novo pacote está disponível onde o problema do proxy é "corrigido" atribuindo WebRequest.DefaultProxy a nulo. Isso pode ter causado consequências, mas não espero problemas reais. A solução alternativa só é adicionada à montagem do .NET Standard. A montagem do .NET Framework deve funcionar como antes.
https://www.nuget.org/packages/RestSharp/106.0.0-alpha0284

Se não houver problemas relatados, começarei a preparar o lançamento.

Resposta bastante positiva aqui. Eu estava tentando fazer um pacote dependente funcionar (Atlassian.JIRA) e presumindo que eu visava ao padrão .NET 2.0, então todos os seus testes de integração / unidade "funcionaram", então LGTM.

https://bitbucket.org/farmas/atlassian.net-sdk/issues/306/support-for-dotnet-core para o tópico nessa extremidade.

Eu testei em nossa solução e funciona bem.

Estamos usando em projetos .net padrão 2.0 e projetos .net 4.6.1

Quando usado a partir do .net 4.6.1. projetos ele puxa nas seguintes referências, que o Visual Studio marca com pontos de exclamação amarelos.
System.Net.Http
System.Runtime.Serialization.Primitives
System.Security.Cryptography.Algorithms
System.Security.Cryptography.Encoding
System.Security.Cryptography.Primitives
System.Security.Cryptography.X509Certificates

Não sei por que isso acontece, no entanto, não parece causar problemas.

O único problema menor que temos é que usamos clickonce para distribuir uma de nossas ferramentas, então somos forçados a nomear tudo. No entanto, a versão de pré-lançamento não tem um nome forte. Temos usado a versão RestSharpSigned do pacote, mas não existe uma versão de pré-lançamento com suporte ao padrão .net.

Ter uma versão com nome forte e uma versão com nome não forte pode ser problemático na situação em que você tem duas dependências, uma que depende da versão com nome forte e outra que depende da versão com nome não forte.

Em vez disso, sugiro ter um pacote que está assinado e congelando na versão principal de sua versão do assembly (em SemVer, a versão principal muda apenas quando você quebra a compatibilidade) e, em seguida, usando SemVer completo em seu FileVersion. Desta forma, você tem um pacote nuget que todos podem usar (nome forte ou não) e o congelamento da versão principal significa que os redirecionamentos de ligação não são necessários. E usar o SemVer significa que todos sabem exatamente onde estão em termos de compatibilidade.

Sugiro isso aqui porque a mudança para o padrão .net pode ser um bom momento para fazer essa mudança.

Devemos apenas assinar o pacote por padrão e colocar a chave no GitHub. A equipe .net recomenda isso porque não prejudica nada.

Existe um PR que eu possa ver as mudanças?

@niemyjski Presumo que o develop seja visível para todos. Eu o tornei um branch padrão também.

@niemyjski "Just" não funciona neste caso. Se você quiser ajudar - por favor, ajude. Tive que remover Signed projetos porque eles falham em toda a construção da solução devido a um bug no nuget.
https://github.com/dotnet/standard/issues/538
https://github.com/NuGet/Home/issues/6038

Portanto, ou terei de esperar até que seja corrigido ou terei que adicionar uma solução e projetos separados e, em seguida, incluir todos os arquivos manualmente, o que é desagradável.

@alexeyzimarev tenha apenas um csproj e assine-o. Congele o número da versão do assembly (para a versão principal) para evitar problemas de redirecionamento de ligação. Use SemVer padrão para nuget e versão de arquivo. Isso resolverá todos os seus problemas.

Se você insistir em manter duas versões (o que causará problemas para seus usuários), você ainda pode fazer isso com um único csproj por meio da configuração.

Eu fiz isso originalmente em meu próprio projeto (e funcionou) antes de perceber como era ruim ter duas versões. Basicamente, adicionei um grupo de propriedades StrongName. Em seguida, crie com 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>

Se você esperar por uma solução para os problemas levantados, pode demorar muito.

Isso resolverá todos os seus problemas.

Eu simplesmente amo isso.

A sugestão do grupo de propriedades é valiosa. Vou tentar manter dois pacotes, caso contrário, criará confusão. Posso estar errado, mas, pessoalmente, evito assinar. Mas já que você precisa - vou tentar fazer um pacote com um assembly assinado.

@niemyjski , você tem um link para "A equipe .net recomenda isso"? Preciso saber mais sobre as consequências e como exatamente eles sugerem fazer isso.

Conversei com eles e sei que também disseram isso publicamente em
fóruns e folga. É uma espécie de piada e deve ser removido (
https://twitter.com/terrajobst/status/774752534682402817) .. É melhor
apenas nomear fortemente a assembleia ... Nós damos um nome forte a todas as nossas assembleias e
deixe o sinal de assinatura no repositório, pois é uma piada. Qualquer pessoa com um editor hexadecimal
pode ignorar a assinatura de nome forte e só prejudica aqueles que são obrigados a
assine seus pacotes de assumir dependências. Você pode fazer referência a um forte
pacote assinado de um pacote não assinado, então por que não apenas assinar tudo
Tempo.

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

Obrigado
-Blake Niemyjski

Na quarta-feira, 1 de novembro de 2017 às 13h30, Alexey Zimarev [email protected]
escreveu:

@niemyjski https://github.com/niemyjski você tem um link para "The .net
equipe recomenda isso "? Preciso saber mais sobre as consequências e como
exatamente eles sugerem fazer isso.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/restsharp/RestSharp/issues/992#issuecomment-341197289 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AA-So94xh-jiEMniw0D2QaGQPgT9zfBfks5syLjDgaJpZM4PLH2m
.

Ok, vou apenas assinar.

Ele é lançado. https://www.nuget.org/packages/RestSharp/106.0.0

Você deve criar uma tag de lançamento aqui no github. :)

Etiquetado

As notas da versão para 106.1.0 mencionam:
"Corrigido o problema de proxy no .NET Core"

Não temos certeza do que essa correção cobre, mas ainda estamos enfrentando problemas para usar o proxy.
Antes de nossa porta .NET Core 2.0 (vinda do .NET Framework 4.6.1), instanciamos o cliente assim e funcionou perfeitamente.

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

Usar o mesmo código no projeto .NET Core 2.0 nos dá o seguinte erro de resposta:

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

O código que dispara a solicitação é assim:

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

Alguma ideia?

Valeu,
Fred

Você tem um código funcional para .NET Core 2.0?

Porque se você checar o stacktrace, verá que esta não é a nossa exceção, mas a exceção do .NET quando ele tentou obter um proxy padrão.

Sim, você está certo @alexeyzimarev , a exceção é atually lançada em System.Net.SystemWebProxy.GetProxy, fui rápido no gatilho. :)

Para outras pessoas que enfrentam o mesmo problema, você pode especificar explicitamente qual proxy usar desta forma:

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

Eu atualizei de 106.1.0 para 106.2.0 no .NET Core 2.0 e esta mensagem começou a aparecer:

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

Conforme mencionado por outros, esta mensagem parece ser gerada por System.Net.SystemWebproxy.GetProxy, mas no meu caso, não estou configurando explicitamente um proxy, internamente ele está fazendo suas próprias operações e lançando uma exceção em cada solicitação que faço.

Voltei para 106.1.0 e isso corrigiu, então algo mudou em 106.2.0 onde as configurações de proxy precisam ser explícitas de alguma forma?

@voicebooth isso é relatado em # 1061