938

La prise en charge de .NET Standard 2.0 signifierait la prise en charge de toutes ces plates -

• .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 (expédition plus tard cette année)

Lors de l'exécution de RestSharp à l'aide du shim de compatibilité descendante , cela fonctionne pour la plupart, il y a juste des problèmes avec la classe sous-jacente utilisée pour appeler les appels HTTP - si le client HTTP était désactivé avec le nouveau HttpClient , cela devrait fonctionner.

Sur une note personnelle, nous utilisons beaucoup RestSharp ici dans notre bureau, et nous travaillons déjà sur de nouvelles solutions basées sur le cloud qui s'exécutent avec ASP.NET Core, nous aimerions donc vraiment voir RestSharp mis à jour avec la dernière version de .NET. version afin que nous n'ayons pas à passer à une nouvelle bibliothèque REST.

@qJake Étant donné que .NET Standard 2.0 a une surface d'API considérablement étendue, HttpWebRequest pourrait sûrement être conservé au lieu de passer à HttpClient. Peut-être que les problèmes que vous avez rencontrés avec la cale ne sont plus présents ?

Pourquoi .NET Standard 2.0 ? Veuillez envisager de cibler la version la plus basse disponible.

@mguinness Voir ce commentaire dans le projet @dotnet/corefx - HttpWebRequest ne fait pas partie de .NET Standard, mais System.Net.Http.HttpClient l' est.

Veuillez également envisager de prendre en charge la version actuelle d'UWP. (avant la mise à jour des créateurs d'automne)

La version actuelle d'UWP signifierait netstandard1.4. Je ne suis pas sûr des conséquences que cela entraînera, il faut commencer à expérimenter.

@qJake Eh bien, HttpWebRequest est dans .NET Standard 2.0, votre affirmation n'est vraie que pour .NET Standard 1.6 et inférieur.

@mguinness Oh, je vois - eh bien, cela présente un défi, alors - puisque RestSharp utilise HttpWebRequest/Response, prenons-nous en charge uniquement .NET Standard 2.0 et restons-nous avec ces classes, ou refactorisons-nous le client sous-jacent et passons à HttpClient , nous permettant de prendre en charge les anciennes versions de .NET Standard ?

Les gens veulent 1.4 en raison de problèmes avec la version actuelle d'UWP. NETStandard 2.0 ne sera pris en charge que dans UWP vNext.

@qJake FWIW, il existe également le package nuget System.Net.Requests qui peut être utilisé dans les versions antérieures de .NET Standard.

Hé les gars, une mise à jour ou un ETA à ce sujet ? Je prévois d'utiliser RestSharp sur mon application dotnet core 2 et je ne voudrais pas changer de package.

C'est un travail en cours. Les éléments hérités ont été supprimés, mais nous devrons probablement également apporter JSON.NET à la version. Restez à l'écoute.

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

Je dois l'utiliser pour AWS Lambda, mais lors de l'utilisation de RestSharp.NetCore 105.2.3 AWS renvoie des erreurs
--Rétrogradation du package détectée : System.Reflection de 4.3.0-preview1-24530-04 à 4.1.0.

Signifie que RestSharp utilise 4.1 mais AWS prend en charge l'ensemble de versions 4.3, pour .NetCoreApp 1.0.

Avons-nous une version avec dépendance sur System.Runtime.Serialization.Primitives.4.3.0-preview1-24530-04 ?

Nous passons au noyau .net et venons de découvrir que nous ne pouvons pas référencer RestSharp à partir de la norme .net 2.0, le package nuget ne parvient pas à s'installer.

Le package 'RestSharpSigned 105.2.3' a été restauré à l'aide de '.NETFramework,Version=v4.6.1' au lieu du framework cible du projet '.NETStandard,Version=v2.0'. Ce package peut ne pas être entièrement compatible avec votre projet.
La restauration du package a échoué. Annulation des modifications de package pour

@trampster Je pense que vous comprenez mal le statut. Le package officiel RestSharp ne prend pas en charge .NET Standard et a été mis à jour pour la dernière fois en 2015. La conversion sur laquelle travaille Alexeyzimarev n'a pas encore été publiée AFAIK.

Je comprends, je postais pour aider à indiquer qu'il y a une demande pour cela. Pour montrer également que le mode de compatibilité .NET Framework pour référencer les dll complètes .net à partir de la norme .net 2.0 annoncée par Microsoft lors de la publication de la norme .net 2.0 ne fonctionne pas ici. Il n'y a donc pas de contournement, nous sommes bloqués.

Nous préférerions ne pas avoir à passer à une autre bibliothèque Rest, mais nous le ferons si nous en avons besoin. Cela dépendra du temps que prendra cette conversion.

Fait intéressant, il existe un package RestSharp.NetCore sur nuget https://www.nuget.org/packages/RestSharp.NetCore avec 98 895 téléchargements, mais pour autant que je sache, le téléchargeur n'est pas associé au projet, donc je ne sais pas si je peux lui faire confiance.

@trampster C'est un avertissement nuget (qui peut être supprimé), consultez Réutilisation d'une bibliothèque .NET Framework existante . Quel est également votre framework cible dans votre csproj, est-ce netcoreapp2.0 ou v4.6.1 ?

Jetez un deuxième coup d'œil à la dernière ligne. Il l'a fait reculer. Après, je n'ai aucune référence à RestSharp.

De plus, si vous lisez mon message, vous verrez que j'essaie de l'utiliser à partir de la norme .net 2.0 et non de netcore2.0 ou v4.6.1.

Il convient également de noter que l'avertissement indique que la version 4.6.1 a été utilisée mais que le package nuget RestSharp n'a pas la version 4.6.1

@trampster Je l'ai installé avec succès dans une application .NET Core 2.0 à l'aide du pont de compatibilité, mais lorsque je l'exécute, je reçois une exception d'exécution qui se résume à une utilisation de HttpWebRequest . Je n'ai eu aucun échec d'installation de package NuGet, donc c'est bizarre. ??

Je rencontre également ceci :\ @alexeyzimarev comment la communauté peut-elle aider. Nous en avons besoin et nous sommes tous bloqués là-dessus. J'exécute le package OAuth2 qui utilise cette bibliothèque et tout le monde est également empêché de l'utiliser.

L'utilisation du package nuget actuel dans une application .NET Core n'est possible que si vous ciblez le framework complet.

J'ai créé une nouvelle application de console .NET Core, exécuté Install-Package RestSharp -Version 105.2.3 partir du gestionnaire de packages et ajouté le code suivant dans Main :

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

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

var réponse = client.Execute(request);
```

Le ciblage de netcoreapp2.0 vous donnera System.PlatformNotSupportedException: Operation is not supported on this platform. mais cela fonctionnera si vous passez à <TargetFramework>net46</TargetFramework> dans csproj.

Nous ne ciblons pas le cadre complet

@niemyjski Essayez peut-être RestSharp.NetCore pendant que vous attendez que cette bibliothèque soit mise à jour. Il est utilisé par les bibliothèques suivantes, il devrait donc être suffisamment stable pour être utilisé.

ADH.PushCore
AppVeyorSharp
CoreLib.Web
CouchDB.Client
DocuSign.NetCore
Flip.PomboCorreio.Connector
Courriel Courant.Mailgun
GiphyApiClient.NetCore
Intercom.Core
IronSphere.Sbires
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
Sites en ligne.ShopFacilBradesco
pusher-http-dotnet-core
RéférentielFramework.Api
RéférentielFramework.EntityFramework
RestSharp.Newtonsoft.Json
RestSharp.Newtonsoft.Json.NetCore
Slack.Webhooks.Core
Connecteur StoneCo.PomboCorreio.
SwitchAPI.Connector
Syncromatics.Clients.Metro.Api
TransportApi.Sdk.NetCore
Twilio.NetCore
UtilitaireFramework.Application.Core
UtilitaireFramework.Services.Iugu.Core

Est-ce que quelqu'un sait qui est le téléchargeur de RestSharp.NetCore ? J'ai regardé github et ils n'ont pas de fork de RestSharp. Il n'y a pas de licence répertoriée sur l'emballage, pour autant que je sache, c'est malveillant.

Quiconque possède ce projet devrait demander la propriété de l'espace de noms du package restsharp ... et probablement faire radier ce package. Je verrais probablement si ce paquet contient du contenu malveillant en le décompilant

Le 5 oct. 2017 à 22:57,

@niemyjski (https://github.com/niemyjski) Essayez peut-être RestSharp.NetCore (https://www.nuget.org/packages/RestSharp.NetCore/) pendant que vous attendez que cette bibliothèque soit mise à jour. Il est utilisé par les bibliothèques suivantes, il devrait donc être suffisamment stable pour être utilisé.

ADH.PushCore
AppVeyorSharp
CoreLib.Web
CouchDB.Client
DocuSign.NetCore
Flip.PomboCorreio.Connector
Courriel Courant.Mailgun
GiphyApiClient.NetCore
Intercom.Core
IronSphere.Sbires
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
Sites en ligne.ShopFacilBradesco
pusher-http-dotnet-core
RéférentielFramework.Api
RéférentielFramework.EntityFramework
RestSharp.Newtonsoft.Json
RestSharp.Newtonsoft.Json.NetCore
Slack.Webhooks.Core
Connecteur StoneCo.PomboCorreio.
SwitchAPI.Connector
Syncromatics.Clients.Metro.Api
TransportApi.Sdk.NetCore
Twilio.NetCore
UtilitaireFramework.Application.Core
UtilitaireFramework.Services.Iugu.Core

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub (https://github.com/restsharp/RestSharp/issues/992#issuecomment-334651808), ou coupez le fil (https://github.com/notifications/unsubscribe-auth /AA-So9HrYQHV5nlV1m7W7eY-y_F5cBqqks5spaUXgaJpZM4PLH2m).

@alexeyzimarev y a-t-il une chance d'obtenir un package nuget préliminaire aujourd'hui ? Même s'il s'agit d'une version bêta et que tous les tests fonctionnent, d'autres choses peuvent changer.

Triste RESTsharp ne fonctionne pas avec Core 2.0. Je suppose que c'est de retour à HttpClient

@niemyjski Non, désolé. Je change WebRequest en HttpClient et c'est un grand changement. La raison en est que WebRequest n'est disponible que pour netstandard 2.0 et que nous souhaitons prendre en charge la version 1.6.

@niemyjski Je peux publier mes modifications dans une branche distincte si vous voulez aider-

En fait, je suis passé à netstandard 2.0 maintenant. netstandard 1.6 semble être trop de travail. Mais je veux toujours utiliser HttpClient.

Vérifiez ceci : https://github.com/restsharp/RestSharp/tree/netstandard
PR bienvenus.

@amivit Vous pouvez

Je change WebRequest en HttpClient et c'est un grand changement. La raison en est que WebRequest n'est disponible que pour netstandard 2.0 et que nous souhaitons prendre en charge la version 1.6.

C'est une déclaration incorrecte car il existe le package nuget System.Net.Requests.

Serait-il difficile de s'en tenir initialement à WebRequest, puis de passer à HttpClient au fil du temps ?

@mguinness Avez-vous essayé d'utiliser ce package ? J'ai fait.

@mguinness On peut dire - oubliez 1.6, on opte pour 2.0 et on garde WebRequest. Je suis personnellement d'accord avec ça.

Désolé @alexeyzimarev je n'ai pas le temps de contribuer. Je souhaite que. Je suis juste surpris que RESTsharp ne s'appuie pas sur HttpClient pour commencer. N'est-ce pas une amélioration disponible par rapport à WebClient depuis 2012 ou .NET 4.5 ?

@amivit Probablement un cas où si ce n'est pas cassé, ne le

Désolé pour juste mimimi ici :rofl:
mais après la mise à niveau de mon application cliente vers .net core 2.0, je reçois quelques avertissements concernant RestSharp :

avertissement NU1603 : RestSharp.NetCore 105.2.3 dépend de System.Runtime.Serialization.Formatters (>= 4.0.0-rc4-24217-03) mais System.Runtime.Serialization.Formatters 4.0.0-rc4-24217-03 n'était pas trouvé. Une meilleure correspondance approximative de System.Runtime.Serialization.Formatters 4.3.0-preview1-24530-04 a été résolue.

Je n'ai pas essayé d'exécuter l'application pour l'instant - je suppose que cela ne fonctionnera pas.
Ainsi, RestSharp ne prend pas encore en charge .net core 2.0. Mais, le sera-t-il un jour ? Y a-t-il déjà un rendez-vous ? Puis-je aider ici pour que cela se produise (en tant que contributeur) ?

@matthiasburger vérifie la branche netstandard. Je l'ai mentionné juste quelques messages au-dessus de votre commentaire.

Allez avec 2.0 pour l'instant. Peut toujours le changer plus tard pour être client http... Aussi
assurez-vous d'avoir les directives du compilateur pour qu'il ait les méthodes de synchronisation
(CADRE)

Merci
-Blake Niemyjski

Le mercredi 11 octobre 2017 à 6h43, Alexey Zimarev [email protected]
a écrit:

@matthiasburger https://github.com/matthiasburger vérifier le netstandard
branche.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/restsharp/RestSharp/issues/992#issuecomment-335782906 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AA-So8akA6MlKfoypWDSAqaElcYBPfoAks5srKnUgaJpZM4PLH2m
.

sry @alexeyzimarev parfois je devrais tout lire - super. Je regarde ça :)

@niemyjski Toutes les directives pragma sont supprimées. Je ne veux pas avoir d'écarts par plate-forme, framework, etc. C'est ce que netstandard déclare résoudre et je vais l'utiliser.

Ok, donc la branche netstandard est maintenant construite pour les signatures et les non signées. J'ai quand même quatre tests qui échouent (encodage, décodage). Les tests d'intégration ne sont pas encore inclus. J'espère pouvoir terminer le code cette semaine, mais la construction et le pack nécessiteront un peu plus de travail pour passer à DotNetCli.

Ok, tout semble fonctionner. J'ai dû ignorer conditionnellement deux tests en raison d'exceptions non prises en charge du HttpListener (intégration). Attendez-vous à ce qu'il fonctionne lorsqu'il est utilisé avec un serveur approprié.

Maintenant, le script de construction doit être modifié pour utiliser DotNetCli et arrêter d'utiliser nuget.exe

Continuez votre excellent travail @alexeyzimarev ! J'ai hâte de la première version 👍

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

Testé 106.0.0-alpha0277 dans VS2017 et réel IIS ciblant .NET Core 2.0

ErrorException : System.PlatformNotSupportedException : l'opération n'est pas prise en charge sur cette plate-forme.
à System.Net.SystemWebProxy.GetProxy (destination Uri)
à System.Net.ServicePointManager.ProxyAddressIfNecessary (adresse Uri&, proxy IWebProxy)
à System.Net.ServicePointManager.FindServicePoint (adresse Uri, proxy IWebProxy)
à System.Net.HttpWebRequest.get_ServicePoint()
à RestSharp.Http.ConfigureWebRequest (méthode String, URL Uri)
à RestSharp.Http.PostPutInternal (méthode String)
à RestSharp.Http.AsPost(String httpMethod)
à RestSharp.RestClient.DoExecuteAsPost (IHttp http, méthode String)
à RestSharp.RestClient.Execute (demande IRestRequest, chaîne httpMethod, Func`3 getResponse)

Je sais qu'ils ont ajouté de nombreuses méthodes IsXYZ au fil du temps, nous devons peut-être les vérifier avant d'appeler ces méthodes ou de les envelopper ?

Ce serait bien de commencer à exécuter ces tests sous Linux car je pense que cela trouverait beaucoup plus de problèmes que sous Windows.

@ maciek12305 il ne suffit pas de copier-coller une exception ici car je n'ai aucune idée de comment vous y êtes arrivé.

@niemyjski Je suis d'accord pour exécuter des tests sur Linux mais cela nécessite la configuration d'une nouvelle version de CI. Je regarderai Travis plus tard, j'espère la semaine prochaine.

Cela ressemble à un problème avec le proxy https://github.com/Azure/azure-iot-sdk-csharp/issues/140

D'accord, le problème est que .NET Core ne prend pas en charge le proxy par défaut car les paramètres du proxy par défaut sont chargés à partir du registre.

Ainsi, cela devrait fonctionner si vous n'utilisez pas de proxy et il se bloquera sur .NET Core si un proxy est utilisé. Pour l'instant j'ai ajouté la classe "proxy par défaut", qui dit de tout contourner et d'y aller directement. Si vous devez utiliser un proxy, vous devrez le fournir en utilisant la méthode ConfigureProxy .

Veuillez essayer le dernier package : https://www.nuget.org/packages/RestSharp/106.0.0-alpha0281

@niemyjski En fait, les tests d'intégration passent bien sur Mac. Cela devrait donc fonctionner aussi sous Linux, je suppose.

@alexeyzimarev Le dernier package n'a pas fonctionné pour moi sur Win 10. La seule façon pour moi de le faire fonctionner était d'inclure ce qui suit dans mon code :

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

@mguinness alors pourquoi gardez-vous l'ancienne valeur (pas sûr de ce que c'est) dans la variable proxy ? Je suppose que la seule ligne qui peut faire une différence est la

WebRequest.DefaultWebProxy = null;

Je peux facilement l'ajouter si cela peut aider.

@alexeyzimarev Il y avait un bogue dans le framework qui commit "WebRequest.DefaultWebProxy: Set ne fonctionne pas sans un précédent Get".

Je comprends maintenant. Je peux essayer de créer un package en définissant la propriété proxy de la demande sur null au lieu de manipuler celle par défaut.

@mguinness le nouveau package est sorti, merci de votre aide !

@mavanmanen pouvez-vous essayer celui-ci aussi, avec UWP ? https://www.nuget.org/packages/RestSharp/106.0.0-alpha0282

Avec la version 106.0.0-alpha0282, la même erreur "L'opération n'est pas prise en charge sur cette plate-forme".

@remiskaune as-tu essayé d'inclure ces lignes dans ton code ?

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

Merci. Il fonctionne maintenant avec ces lignes sur la version 106.0.0-alpha0282.

Donc la question est pourquoi ça ne marche pas sans, puisque j'ai inclus ces lignes dans le code RestSharp...

Peut-être que WebRequest a une portée différente ? Est-ce une classe statique ou instanciée ?

Vous pouvez le découvrir en créant un exemple d'application, et dans votre exemple d'application, vérifiez :

WebRequest.DefaultWebProxy

Et également exposer une méthode pour que RestSharp envoie la valeur qu'il voit (à des fins de débogage) - par exemple :

public IWebProxy GetCurrentProxy() => WebRequest.DefaultWebProxy;

Voir si les deux sont différents ?

@qJake J'apprécierais que quelqu'un puisse déboguer pour moi :) Je ne pourrai pas y consacrer de temps avant la semaine prochaine, je prendrai la parole lors d'une conférence.

Un nouveau package est disponible où le problème de proxy est "réparé" en attribuant le WebRequest.DefaultProxy à null. Cela a pu avoir des conséquences mais je ne m'attends pas à de vrais problèmes. La solution de contournement est uniquement ajoutée à l'assembly .NET Standard. L'assembly .NET Framework devrait fonctionner comme avant.
https://www.nuget.org/packages/RestSharp/106.0.0-alpha0284

Si aucun problème n'est signalé, je commencerai à préparer la version.

Réponse assez positive ici. Je jouais en essayant de faire fonctionner un package dépendant (Atlassian.JIRA) et en supposant que j'ai ciblé la norme .NET 2.0, puis tous leurs tests d'intégration/unités "ont fonctionné", donc LGTM.

https://bitbucket.org/farmas/atlassian.net-sdk/issues/306/support-for-dotnet-core pour le fil à cette extrémité.

Je l'ai testé par rapport à notre solution, et cela fonctionne bien.

Nous l'utilisons à partir de projets .net standard 2.0 et de projets .net 4.6.1

Lorsqu'il est utilisé depuis le .net 4.6.1. projets, il extrait les références suivantes, que Visual Studio marque avec des points d'exclamation jaunes.
System.Net.Http
System.Runtime.Serialization.Primitives
Système.Sécurité.Algorithmes.de.cryptographie
Système.Sécurité.Cryptographie.Encodage
Système.Sécurité.Cryptographie.Primitives
System.Security.Cryptography.X509Certificats

Je ne sais pas pourquoi, mais cela ne semble pas poser de problèmes.

Le seul problème mineur que nous avons est que nous utilisons clickonce pour distribuer l'un de nos outils, nous sommes donc obligés de tout nommer fort. Cependant, la version préliminaire n'a pas de nom fort. Nous avons utilisé la version RestSharpSigned du package, mais il n'y a pas de version préliminaire de celle-ci avec le support standard .net.

Avoir une version à nom fort et une version à nom non fort peut être problématique dans le cas où vous avez deux dépendances, l'une qui dépend de la version à nom fort et l'autre qui repose sur la version à nom non fort.

Au lieu de cela, je suggère d'avoir un package signé et gelé sur la version principale de votre version d'assemblage (dans SemVer, la version principale ne change que lorsque vous rompez la compatibilité), puis d'utiliser la version complète de SemVer sur votre FileVersion. De cette façon, vous disposez d'un package nuget que tout le monde peut utiliser (nom fort ou non) et le gel de la version majeure signifie que les redirections de liaison ne sont pas nécessaires. Et l'utilisation de SemVer signifie que tout le monde sait exactement où il se situe en termes de compatibilité.

Je le suggère ici car le passage à la norme .net pourrait être le bon moment pour effectuer ce changement.

Nous devrions simplement signer le package par défaut et mettre la clé dans GitHub , l'équipe .net le recommande car cela ne fait rien de mal.

Y a-t-il un PR que je peux voir les changements ?

@niemyjski Je suppose que la branche develop est visible pour tous. J'en ai aussi fait une branche par défaut.

@niemyjski "Just" ne fonctionne pas dans ce cas. Si vous voulez aider, faites-le. J'ai dû supprimer des projets Signed car ils échouent dans toute la construction de la solution en raison d'un bogue dans nuget.
https://github.com/dotnet/standard/issues/538
https://github.com/NuGet/Home/issues/6038

Donc, soit je dois attendre que cela soit corrigé, soit je dois ajouter une solution et des projets distincts, puis inclure tous les fichiers manuellement, ce qui est désagréable.

@alexeyzimarev n'a qu'un seul csproj et le signe, fige le numéro de version de l'assembly (vers la version majeure) pour éviter les problèmes de redirection de liaison. Utilisez SemVer standard pour le nuget et la version du fichier. Cela résoudra tous vos problèmes.

Si vous insistez pour conserver deux versions (ce qui causera des problèmes à vos utilisateurs), vous pouvez toujours le faire avec un seul csproj via la configuration.

Je l'ai fait à l'origine dans mon propre projet (et cela a fonctionné) avant de réaliser à quel point il était cassé d'avoir deux versions. Fondamentalement, j'ai ajouté un groupe de propriétés StrongName. Ensuite, construisez avec 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 vous attendez une solution aux problèmes que vous avez soulevés, vous pourriez attendre longtemps.

Cela résoudra tous vos problèmes.

J'adore.

La suggestion de groupe de propriétés est précieuse. Je vais essayer de garder deux packages, sinon cela créera de la confusion. Je me trompe peut-être, mais personnellement, j'éviterais simplement de signer. Mais puisque vous en avez besoin, je vais essayer de faire un package avec un assemblage signé.

@niemyjski avez-vous un lien vers « L'équipe .net le recommande » ? J'ai besoin d'en savoir plus sur les conséquences et comment exactement ils suggèrent de le faire.

J'ai parlé avec eux et je sais qu'ils l'ont également dit publiquement dans
forums et slack. C'est une sorte de blague et devrait être supprimé (
https://twitter.com/terrajobst/status/774752534682402817).. Il vaut mieux
juste un nom fort pour l'assemblage... Nous nommons fort tous nos assemblages et
laissez le snk de signature dans le dépôt car c'est une blague. N'importe qui avec un éditeur hexadécimal
peut contourner la signature de nom fort et cela ne blesse que ceux qui sont tenus de
signer leurs paquets de prendre des dépendances. Vous pouvez référencer un fort
paquet signé à partir d'un paquet non signé alors pourquoi ne pas simplement le signer tout le
temps.

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

Merci
-Blake Niemyjski

Le mer. 1 nov. 2017 à 13h30, Alexey Zimarev [email protected]
a écrit:

@niemyjski https://github.com/niemyjski avez-vous un lien vers "Le .net
l'équipe recommande ceci"? J'ai besoin d'en savoir plus sur les conséquences et comment
exactement ils suggèrent de faire cela.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/restsharp/RestSharp/issues/992#issuecomment-341197289 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AA-So94xh-jiEMniw0D2QaGQPgT9zfBfks5syLjDgaJpZM4PLH2m
.

Ok, je vais juste le signer.

Il est libéré. https://www.nuget.org/packages/RestSharp/106.0.0

Vous devez créer une étiquette de version ici sur github. :)

Tagué

Les notes de version de 106.1.0 mentionnent :
"Correction du problème de proxy sur .NET Core"

Je ne sais pas ce que couvre ce correctif, mais nous rencontrons toujours des problèmes lors de l'utilisation du proxy.
Avant notre port .NET Core 2.0 (provenant de .NET Framework 4.6.1), nous avons instancié le client comme ceci et cela a fonctionné à merveille.

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

L'utilisation du même code dans le projet .NET Core 2.0 nous donne l'erreur de réponse suivante :

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

Le code déclenchant la requête ressemble à ceci :

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

Des pensées?

THX,
Fred

Avez-vous un code fonctionnel pour .NET Core 2.0 ?

Parce que si vous vérifiez le stacktrace, vous verrez que ce n'est pas notre exception mais l'exception .NET lorsqu'il a essayé d'obtenir un proxy par défaut.

Oui, vous avez raison @alexeyzimarev , l'exception est normalement lancée à System.Net.SystemWebProxy.GetProxy, j'étais trop rapide sur le déclencheur. :)

Pour les autres personnes rencontrant le même problème, vous pouvez spécifier explicitement quel proxy utiliser comme ceci :

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

J'ai mis à niveau de 106.1.0 à 106.2.0 sur .NET Core 2.0 et ce message a commencé à apparaître :

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

Comme mentionné par d'autres, ce message semble être généré par System.Net.SystemWebproxy.GetProxy, mais dans mon cas, je ne configure pas du tout explicitement un proxy, en interne, il effectue ses propres opérations et lance une exception à chaque demande que je fais.

Je suis revenu à 106.1.0 et cela l'a corrigé, donc quelque chose a-t-il changé dans 106.2.0 où les paramètres de proxy doivent être explicites d'une manière ou d'une autre?

@voicebooth ceci est rapporté dans #1061