938

Admitir .NET Standard 2.0 significaría admitir 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 (se enviará a finales de este año)

Cuando se ejecuta RestSharp usando la corrección de compatibilidad con versiones anteriores , funciona en su mayor parte, solo hay problemas con la clase subyacente utilizada para invocar las llamadas HTTP; si el cliente HTTP se cambió con el nuevo HttpClient , debería funcionar.

En una nota personal, usamos RestSharp bastante aquí en nuestra oficina, y ya estamos trabajando en nuevas soluciones basadas en la nube que se ejecutan con ASP.NET Core, por lo que realmente nos gustaría ver RestSharp actualizado a la última versión de .NET versión para que no tengamos que cambiar a una nueva biblioteca REST.

@qJake Dado que .NET Standard 2.0 tiene una superficie de API muy expandida, seguramente HttpWebRequest podría retenerse en lugar de cambiar a HttpClient. ¿Quizás los problemas que experimentó con la cuña ya no están presentes?

¿Por qué .NET Standard 2.0? Considere apuntar a la versión más baja disponible.

@mguinness Vea este comentario en el proyecto @ dotnet / corefx : HttpWebRequest no es parte de .NET Standard, pero System.Net.Http.HttpClient sí lo es.

Considere también admitir la versión actual de UWP. (antes de Fall Creators Update)

La versión actual de UWP significaría netstandard1.4. No estoy seguro de qué consecuencias traerá esto, necesito comenzar a experimentar.

@qJake Bueno, HttpWebRequest está en .NET Standard 2.0, su afirmación solo es cierta para .NET Standard 1.6 y versiones anteriores.

@mguinness Oh, ya veo, bueno, eso presenta un desafío, entonces, dado que RestSharp usa HttpWebRequest / Response, ¿admitimos solo .NET Standard 2.0 y nos quedamos con esas clases, o refactorizamos el cliente subyacente y cambiamos a HttpClient , lo que nos permite admitir versiones anteriores de .NET Standard?

La gente quiere 1.4 debido a problemas con la versión actual de UWP. NETStandard 2.0 solo será compatible con UWP vNext.

@qJake FWIW, también existe el paquete nuget System.Net.Requests que se puede usar en versiones anteriores de .NET Standard.

Hola chicos, ¿alguna actualización o ETA sobre esto? Planeo usar RestSharp en mi aplicación dotnet core 2 y no me gustaría cambiar de paquete.

Es un trabajo en progreso. Se han eliminado las cosas heredadas, pero probablemente también tendremos que llevar JSON.NET al lanzamiento. Manténganse al tanto.

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

Necesito usarlo para AWS Lambda, pero cuando uso RestSharp.NetCore 105.2.3 AWS devuelve errores
- Degradación de paquete detectada: System.Reflection de 4.3.0-preview1-24530-04 a 4.1.0.

Significa que RestSharp está usando 4.1 pero AWS admite el conjunto de versiones 4.3, para .NetCoreApp 1.0.

¿Tenemos una versión con dependencia de System.Runtime.Serialization.Primitives.4.3.0-preview1-24530-04?

Nos estamos moviendo a .net core y acabamos de descubrir que no podemos hacer referencia a RestSharp desde .net estándar 2.0, el paquete nuget no se instala.

El paquete 'RestSharpSigned 105.2.3' se restauró utilizando '.NETFramework, Version = v4.6.1' en lugar del marco de destino del proyecto '.NETStandard, Version = v2.0'. Es posible que este paquete no sea totalmente compatible con su proyecto.
Falló la restauración del paquete. Deshacer cambios de paquete para

@trampster Creo que malinterpretas el estado. El paquete oficial RestSharp no es compatible con .NET Standard y se actualizó por última vez en 2015. La conversión en la que está trabajando alexeyzimarev aún no se ha publicado AFAIK.

Entiendo, estaba publicando para ayudar a indicar que hay demanda. También para mostrar que el modo de compatibilidad de .NET Framework para hacer referencia a .net full dlls de .net estándar 2.0 como lo anunció Microsoft al lanzar .net estándar 2.0 no funciona aquí. Así que no hay solución, estamos bloqueados.

Preferiríamos no tener que cambiarnos a otra biblioteca de Rest, pero lo haremos si es necesario. Dependerá de cuánto tiempo llevará esta conversión.

Curiosamente, hay un paquete RestSharp.NetCore en nuget https://www.nuget.org/packages/RestSharp.NetCore con 98,895 descargas, sin embargo, por lo que puedo decir, el cargador no está asociado con el proyecto, así que no lo sé si puedo confiar en él.

@trampster Esa es una advertencia nuget (que se puede suprimir), consulte Reutilización de una biblioteca de .NET Framework existente . Además, ¿cuál es su marco de destino en su csproj, es netcoreapp2.0 o v4.6.1?

Eche un segundo vistazo a la última línea. Lo hizo retroceder. Posteriormente no tengo ninguna referencia a RestSharp.

Además, si lee mi publicación, verá que estoy tratando de usarlo desde .net estándar 2.0, no netcore2.0 o v4.6.1.

También debe tenerse en cuenta que la advertencia dice que se usó v4.6.1 pero el paquete nuget RestSharp no tiene v4.6.1

@trampster Lo instalé correctamente en una aplicación .NET Core 2.0 usando el puente de compatibilidad, pero cuando voy a ejecutarlo, obtengo una excepción de tiempo de ejecución que se reduce a un uso de HttpWebRequest . No obtuve ningún error de instalación del paquete NuGet, así que eso es extraño. 😃

También me encuentro con esto: \ @alexeyzimarev, ¿cómo puede ayudar la comunidad? Necesitamos esto y todos estamos bloqueados en esto. Ejecuto el paquete OAuth2 que usa esta biblioteca y todos tienen bloqueado el uso de eso también.

El uso del paquete nuget actual en una aplicación .NET Core solo es posible si tiene como destino el marco completo.

Creé una nueva aplicación de consola .NET Core, ejecuté Install-Package RestSharp -Version 105.2.3 desde Package Manager y agregué el siguiente código en Main:

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

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

var respuesta = cliente.Execute (solicitud);
''

Apuntar a netcoreapp2.0 dará System.PlatformNotSupportedException: Operation is not supported on this platform. pero funcionará si cambia a <TargetFramework>net46</TargetFramework> en csproj.

No estamos apuntando al marco completo

@niemyjski Tal vez pruebe RestSharp.NetCore mientras espera que esta biblioteca se actualice. Está siendo utilizado por las siguientes bibliotecas, por lo que debería ser lo suficientemente estable para su uso.

ADH.PushCore
AppVeyorSharp
CoreLib.Web
CouchDB.Client
DocuSign.NetCore
Flip.PomboCorreio.Connector
FluentEmail.Mailgun
GiphyApiClient.NetCore
Intercomunicador Core
Esfera de hierro, secuaces
MasterCard-Core-no oficial
mbank-dotnet
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Sitios en línea.ShopFacilBradesco
empujador-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

¿Alguien sabe quién es el cargador de RestSharp.NetCore? Miré allí github y no tienen una bifurcación de RestSharp. No hay ninguna licencia en el paquete, por lo que sé, es maliciosa.

Quien sea el propietario de este proyecto debería buscar la propiedad del espacio de nombres del paquete restsharp ... y probablemente eliminar ese paquete de la lista. Probablemente vería si ese paquete contiene algún contenido malicioso al descompilarlo

El 5 de octubre de 2017 a las 22:57,

@niemyjski (https://github.com/niemyjski) Tal vez pruebe RestSharp.NetCore (https://www.nuget.org/packages/RestSharp.NetCore/) mientras espera que esta biblioteca se actualice. Está siendo utilizado por las siguientes bibliotecas, por lo que debería ser lo suficientemente estable para su uso.

ADH.PushCore
AppVeyorSharp
CoreLib.Web
CouchDB.Client
DocuSign.NetCore
Flip.PomboCorreio.Connector
FluentEmail.Mailgun
GiphyApiClient.NetCore
Intercomunicador Core
Esfera de hierro, secuaces
MasterCard-Core-no oficial
mbank-dotnet
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Sitios en línea.ShopFacilBradesco
empujador-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

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub (https://github.com/restsharp/RestSharp/issues/992#issuecomment-334651808), o silencie el hilo (https://github.com/notifications/unsubscribe-auth / AA-So9HrYQHV5nlV1m7W7eY-y_F5cBqqks5spaUXgaJpZM4PLH2m).

@alexeyzimarev, ¿hay alguna posibilidad de obtener un paquete nuget de presentación hoy? Incluso si es una versión beta y todas las pruebas funcionan, pero algunas otras cosas pueden cambiar.

Sad RESTsharp no funciona con Core 2.0. Supongo que ha vuelto a HttpClient

@niemyjski No, lo siento. Estoy cambiando WebRequest a HttpClient y este es un gran cambio. La razón de esto es que WebRequest solo está disponible para netstandard 2.0 y queremos ser compatible con 1.6.

@niemyjski Puedo publicar mis cambios en una rama separada si quieres ayudar-

De hecho, cambié a netstandard 2.0 ahora. netstandard 1.6 parece ser demasiado trabajo. Pero todavía quiero usar HttpClient.

Mira esto: https://github.com/restsharp/RestSharp/tree/netstandard
Los RP son bienvenidos.

@amivit Puedes aportar algo de tu tiempo para que esto suceda, ¿verdad?

Estoy cambiando WebRequest a HttpClient y este es un gran cambio. La razón de esto es que WebRequest solo está disponible para netstandard 2.0 y queremos ser compatible con 1.6.

Esa es una declaración incorrecta, ya que existe el paquete nuget System.Net.Requests .

¿Sería difícil seguir inicialmente con WebRequest y luego hacer la transición a HttpClient con el tiempo?

@mguinness ¿Ha intentado utilizar este paquete? Yo hice.

@mguinness Podemos decir: olvídate de 1.6, optamos por 2.0 y mantenemos WebRequest. Personalmente estoy bien con eso.

Lo siento @alexeyzimarev , no tengo tiempo para contribuir. Deseo. Me sorprende que RESTsharp no se base en HttpClient para empezar. ¿No ha sido una mejora disponible sobre WebClient desde 2012 o .NET 4.5?

@amivit Probablemente se

Perdón por mimimi aquí: rofl:
pero después de actualizar mi aplicación cliente a .net core 2.0, recibo algunas advertencias sobre RestSharp:

advertencia NU1603: RestSharp.NetCore 105.2.3 depende de System.Runtime.Serialization.Formatters (> = 4.0.0-rc4-24217-03) pero System.Runtime.Serialization.Formatters 4.0.0-rc4-24217-03 no fue fundar. Se resolvió una mejor coincidencia aproximada de System.Runtime.Serialization.Formatters 4.3.0-preview1-24530-04.

No intenté ejecutar la aplicación por ahora, supongo que no funcionará.
Por lo tanto, RestSharp aún no es compatible con .net core 2.0. Pero, ¿lo será algún día? ¿Ya hay una cita? ¿Puedo ayudar aquí para que esto suceda (como colaborador)?

@matthiasburger revisa la rama netstandard. Mencioné esto solo un par de publicaciones arriba de tu comentario.

Vaya con 2.0 por ahora. Siempre se puede cambiar más tarde para ser cliente http ... También
asegúrese de tener las directivas del compilador para que tenga los métodos de sincronización
(ESTRUCTURA)

Gracias
-Blake Niemyjski

El miércoles, 11 de octubre de 2017 a las 6:43 a.m., Alexey Zimarev [email protected]
escribió:

@matthiasburger https://github.com/matthiasburger verifique el netstandard
rama.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/restsharp/RestSharp/issues/992#issuecomment-335782906 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AA-So8akA6MlKfoypWDSAqaElcYBPFoAks5srKnUgaJpZM4PLH2m
.

sry @alexeyzimarev a veces debería leer todo - genial. Le echo un vistazo :)

@niemyjski Se eliminan todas las directivas pragma. No quiero tener desviaciones por plataforma, framework, etc. Esto es lo que netstandard declara resolver y lo voy a utilizar.

Ok, entonces netstandard branch ahora se compila tanto para firmado como para no firmado. Aún tengo cuatro pruebas que fallan (codificación, decodificación). Pruebas de integración aún no incluidas. Con suerte, puedo terminar el código esta semana, pero la compilación y el paquete requerirán un poco más de trabajo para cambiar a DotNetCli.

Ok, todo parece funcionar. Tuve que ignorar condicionalmente dos pruebas debido a excepciones no admitidas de HttpListener (integración). Sin embargo, espere que funcione cuando se usa con un servidor adecuado.

Ahora se debe cambiar el script de compilación para usar DotNetCli y dejar de usar nuget.exe

¡Sigan con el gran trabajo @alexeyzimarev! No puedo esperar por el primer lanzamiento 👍

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

Probado 106.0.0-alpha0277 en VS2017 e IIS real dirigido a .NET Core 2.0

ErrorException: System.PlatformNotSupportedException: la operación no es compatible con esta plataforma.
en System.Net.SystemWebProxy.GetProxy (destino Uri)
en System.Net.ServicePointManager.ProxyAddressIfNeeded (Uri y dirección, proxy IWebProxy)
en System.Net.ServicePointManager.FindServicePoint (dirección Uri, proxy IWebProxy)
en System.Net.HttpWebRequest.get_ServicePoint ()
en RestSharp.Http.ConfigureWebRequest (método String, url Uri)
en RestSharp.Http.PostPutInternal (método String)
en RestSharp.Http.AsPost (String httpMethod)
en RestSharp.RestClient.DoExecuteAsPost (IHttp http, método String)
en RestSharp.RestClient.Execute (solicitud IRestRequest, String httpMethod, Func`3 getResponse)

Sé que agregaron muchos métodos IsXYZ con el tiempo, ¿quizás debemos verificarlos antes de llamar a estos métodos o envolverlos?

Sería bueno comenzar a ejecutar estas pruebas en Linux, ya que creo que encontraría muchos más problemas que en Windows.

@ maciek12305 no es suficiente copiar y pegar una excepción aquí, ya que no tengo idea de cómo llegaste allí.

@niemyjski Estoy de acuerdo con ejecutar pruebas en Linux, pero esto requiere configurar una nueva compilación de CI. Veré a Travis más adelante, con suerte la semana que viene.

Parece un problema con el proxy https://github.com/Azure/azure-iot-sdk-csharp/issues/140

Ok, el problema es que .NET Core no es compatible con el proxy predeterminado porque la configuración del proxy predeterminado se carga desde el registro.

Por lo tanto, debería funcionar si no usa proxy y se bloqueará en .NET Core si se usa proxy. Por ahora agregué la clase "proxy predeterminado", que dice omitir todo e ir directamente. Si tiene que utilizar un proxy, deberá proporcionarlo mediante el método ConfigureProxy .

Pruebe el paquete más reciente: https://www.nuget.org/packages/RestSharp/106.0.0-alpha0281

@niemyjski En realidad, las pruebas de integración pasan bien en Mac. Así que también debería funcionar en Linux, supongo.

@alexeyzimarev El último paquete no me funcionó en Win 10. La única forma de hacerlo funcionar era incluir lo siguiente en mi código:

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

@mguinness, entonces, ¿por qué mantiene el valor anterior (no estoy seguro de cuál es) en la variable proxy ? Supongo que la única línea que puede marcar la diferencia es la

WebRequest.DefaultWebProxy = null;

Puedo agregarlo fácilmente si esto ayuda.

@alexeyzimarev Hubo un error en el marco que confirma "WebRequest.DefaultWebProxy: Set no funciona sin correcciones previas de Get".

Entiendo ahora. Puedo intentar hacer un paquete estableciendo la propiedad de proxy de solicitud en nula en lugar de manipular la predeterminada.

@mguinness, el nuevo paquete está disponible, ¡gracias por ayudar!

@mavanmanen, ¿puedes probar este también con UWP? https://www.nuget.org/packages/RestSharp/106.0.0-alpha0282

Con la versión 106.0.0-alpha0282, el mismo error "La operación no es compatible con esta plataforma".

@remiskaune, ¿ ha intentado incluir estas líneas en su código?

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

Gracias. Ahora funciona con estas líneas en la versión 106.0.0-alpha0282.

Entonces, la pregunta es por qué no funciona sin, ya que incluí estas líneas en el código RestSharp ...

¿Quizás WebRequest tiene un alcance diferente? ¿Es una clase estática o instanciada?

Puede averiguarlo creando una aplicación de muestra y, en su aplicación de muestra, verifique:

WebRequest.DefaultWebProxy

Y también exponer algún método para que RestSharp envíe el valor que está viendo (con fines de depuración), por ejemplo:

public IWebProxy GetCurrentProxy() => WebRequest.DefaultWebProxy;

¿Ves si los dos son diferentes?

@qJake Agradecería que alguien pudiera

Hay un nuevo paquete disponible donde el problema del proxy se "arregla" asignando WebRequest.DefaultProxy a nulo. Esto podría haber tenido consecuencias, pero no espero problemas reales. La solución alternativa solo se agrega al ensamblado de .NET Standard. El ensamblado de .NET Framework debería funcionar como antes.
https://www.nuget.org/packages/RestSharp/106.0.0-alpha0284

Si no se informan problemas, comenzaré a preparar el lanzamiento.

Respuesta bastante positiva aquí. Estaba jugando tratando de hacer funcionar un paquete dependiente (Atlassian.JIRA) y asumiendo que apunté al estándar 2.0 de .NET, entonces todas sus pruebas de integración / unidad "simplemente funcionaron", así que LGTM.

https://bitbucket.org/farmas/atlassian.net-sdk/issues/306/support-for-dotnet-core para el hilo en ese extremo.

Lo he probado con nuestra solución y funciona bien.

Lo estamos usando desde proyectos .net estándar 2.0 y proyectos .net 4.6.1

Cuando se usa desde .net 4.6.1. proyecta que extrae las siguientes referencias, que Visual Studio marca con signos de exclamación amarillos.
System.Net.Http
System.Runtime.Serialization.Primitives
Sistema.Seguridad.Criptografía.Algoritmos
System.Security.Cryptography.Encoding
System.Security.Cryptography.Primitives
System.Security.Cryptography.X509Certificates

No estoy seguro de por qué es así, sin embargo, no parece causar ningún problema.

El único problema menor que tenemos es que usamos un clic una vez para distribuir una de nuestras herramientas, por lo que nos vemos obligados a nombrar todo de manera segura. Sin embargo, la versión preliminar no tiene un nombre seguro. Hemos estado usando la versión RestSharpSigned del paquete, pero no hay una versión preliminar de eso con soporte estándar .net.

Tener una versión con nombre fuerte y sin nombre fuerte puede ser problemático en la situación en la que tiene dos dependencias, una que depende de la versión con nombre fuerte y otra que depende de la versión con nombre no fuerte.

En lugar de esto, sugiero tener un paquete que esté firmado y congelado en la versión principal de su versión de ensamblaje (en SemVer, la versión principal solo cambia cuando se rompe la compatibilidad) y luego use SemVer completo en su FileVersion. De esta manera, tiene un paquete nuget que todos pueden usar (con nombre seguro o no) y la congelación de la versión principal significa que no se requieren redirecciones vinculantes. Y usar SemVer significa que todos saben exactamente dónde se encuentran en términos de compatibilidad.

Sugiero esto aquí porque el cambio al estándar .net podría ser un buen momento para realizar este cambio.

Deberíamos firmar el paquete por defecto y poner la clave en GitHub. El equipo de .net recomienda esto ya que no hace daño a nada.

¿Existe un PR que pueda ver los cambios?

@niemyjski Asumo que la rama develop es visible para todos. También la convertí en una rama predeterminada.

@niemyjski "Just" no funciona en este caso. Si quieres ayudar, hazlo. Tuve que eliminar los proyectos Signed porque fallan en la compilación completa de la solución debido a un error en nuget.
https://github.com/dotnet/standard/issues/538
https://github.com/NuGet/Home/issues/6038

Entonces, o tendré que esperar hasta que se solucione, o tengo que agregar una solución y proyectos separados, y luego incluir todos los archivos manualmente, lo cual es desagradable.

@alexeyzimarev solo tenga un csproj y fírmelo. Congele el número de versión del ensamblado (a la versión principal) para evitar problemas de redireccionamiento vinculantes. Utilice SemVer estándar para nuget y versión de archivo. Esto solucionará todos tus problemas.

Si insiste en mantener dos versiones (lo que causará problemas a sus usuarios), aún puede hacerlo con un solo csproj a través de la configuración.

Hice esto originalmente en mi propio proyecto (y funcionó) antes de darme cuenta de lo roto que era tener dos versiones. Básicamente, agregué un grupo de propiedades StrongName. Luego compile con 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>

Si espera una solución a los problemas que planteó, es posible que esté esperando mucho tiempo.

Esto solucionará todos tus problemas.

Simplemente me encanta.

La sugerencia del grupo de propiedades es valiosa. Intentaré mantener dos paquetes, de lo contrario creará confusión. Puede que me equivoque, pero personalmente evitaría firmar. Pero como lo necesita, intentaré hacer un paquete con un ensamblaje firmado.

@niemyjski , ¿tienes un enlace a "El equipo de .net recomienda esto"? Necesito saber más sobre las consecuencias y cómo sugieren exactamente hacer esto.

He hablado con ellos y sé que también lo han dicho públicamente en
foros y holgura. Es una especie de broma y debería eliminarse (
https://twitter.com/terrajobst/status/774752534682402817) .. Es mejor
solo nombre fuerte la asamblea ... Damos un nombre fuerte a todas nuestras asambleas y
deje el snk de firma en el repositorio ya que es una broma. Cualquiera con un editor hexadecimal
puede eludir la firma de un nombre fuerte y solo lastima a aquellos que están obligados a
firmar sus paquetes para que no asuman dependencias. Puede hacer referencia a un fuerte
paquete firmado de un paquete sin firmar, así que ¿por qué no firmarlo todo el
tiempo.

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

Gracias
-Blake Niemyjski

El miércoles 1 de noviembre de 2017 a la 1:30 p.m., Alexey Zimarev [email protected]
escribió:

@niemyjski https://github.com/niemyjski ¿tiene un enlace a "The .net
equipo recomienda esto "? Necesito saber más sobre las consecuencias y cómo
exactamente sugieren hacer esto.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/restsharp/RestSharp/issues/992#issuecomment-341197289 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AA-So94xh-jiEMniw0D2QaGQPgT9zfBfks5syLjDgaJpZM4PLH2m
.

Ok, solo lo firmaré.

Se lanza. https://www.nuget.org/packages/RestSharp/106.0.0

Debes crear una etiqueta de lanzamiento aquí en github. :)

Etiquetado

Las notas de la versión para 106.1.0 mencionan:
"Se solucionó el problema del proxy en .NET Core"

No estoy seguro de lo que cubre esa solución, pero todavía tenemos problemas al usar el proxy.
Antes de nuestro puerto .NET Core 2.0 (que viene de .NET Framework 4.6.1), instauramos el cliente de esta manera y funcionó a las mil maravillas.

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

Usar el mismo código en el proyecto .NET Core 2.0 nos da el siguiente error de respuesta:

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

El código que activa la solicitud tiene este aspecto:

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

¿Alguna idea?

Gracias,
Fred

¿Tiene un código que funcione para .NET Core 2.0?

Porque si revisa el stacktrace, verá que esta no es nuestra excepción, sino la excepción de .NET cuando intentó obtener un proxy predeterminado.

Sí, tienes razón @alexeyzimarev , la excepción se lanza en System.Net.SystemWebProxy.GetProxy, fui rápido en el gatillo. :)

Para otros que se encuentren con el mismo problema, puede especificar explícitamente qué Proxy usar de esta manera:

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

Actualicé de 106.1.0 a 106.2.0 en .NET Core 2.0 y este mensaje ha comenzado a aparecer:

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

Como lo mencionaron otros, este mensaje parece ser generado por System.Net.SystemWebproxy.GetProxy, pero en mi caso no estoy configurando explícitamente un proxy en absoluto, internamente está haciendo sus propias operaciones y lanzando una excepción en cada solicitud que hago.

He reverenciado de nuevo a 106.1.0 y esto lo ha solucionado, entonces, ¿ha cambiado algo en 106.2.0 donde la configuración del proxy debe ser explícita de alguna manera?

@voicebooth esto se informa en el # 1061