938

Die Unterstützung von .NET Standard 2.0 würde bedeuten, dass alle diese Plattformen unterstützt werden :

• .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 (Versand später in diesem Jahr)

Wenn RestSharp mit dem Abwärtskompatibilitäts-Shim ausgeführt wird , funktioniert es größtenteils, es gibt nur Probleme mit der zugrunde liegenden Klasse, die zum Aufrufen der HTTP-Aufrufe verwendet wird - wenn der HTTP-Client mit dem neuen HttpClient ausgetauscht wurde , sollte es funktionieren.

Persönlich verwenden wir RestSharp hier in unserem Büro ziemlich oft und arbeiten bereits an neuen Cloud-basierten Lösungen, die mit ASP.NET Core ausgeführt werden Version, damit wir nicht zu einer neuen REST-Bibliothek wechseln müssen.

@qJake Da .NET Standard 2.0 eine stark erweiterte API-Oberfläche hat, könnte HttpWebRequest sicherlich beibehalten werden, anstatt zu HttpClient zu wechseln. Vielleicht sind die Probleme, die Sie mit dem Shim hatten, nicht mehr vorhanden?

Warum .NET-Standard 2.0? Bitte beachten Sie, dass Sie die niedrigste verfügbare Version auswählen.

@mguinness Siehe diesen Kommentar im @dotnet/corefx- Projekt - HttpWebRequest ist nicht Teil von .NET Standard, aber System.Net.Http.HttpClient ist Teil von .NET Standard.

Bitte denken Sie daran, auch die aktuelle UWP-Version zu unterstützen. (vor dem Fall Creators Update)

Die aktuelle UWP-Version würde netstandard1.4 bedeuten. Ich bin mir nicht sicher, welche Konsequenzen dies mit sich bringen wird, ich muss mit dem Experimentieren beginnen.

@qJake Nun, HttpWebRequest ist in .NET Standard 2.0 enthalten, Ihre Behauptung gilt nur für .NET Standard 1.6 und darunter.

@mguinness Oh, ich HttpClient , damit wir ältere Versionen von .NET Standard unterstützen können?

Die Leute wollen 1.4 aufgrund von Problemen mit der aktuellen Version von UWP. NETStandard 2.0 wird nur in UWP vNext unterstützt.

@qJake FWIW, es gibt auch das System.Net.Requests- Nuget-Paket, das in früheren Versionen von .NET Standard verwendet werden kann.

Hey Leute, gibt es ein Update oder eine ETA dazu? Ich plane die Verwendung von RestSharp in meiner Dotnet Core 2-App und möchte keine Pakete wechseln.

Es ist in Arbeit. Legacy-Zeug wurde entfernt, aber wir werden wahrscheinlich auch JSON.NET mit in die Veröffentlichung bringen. Bleiben Sie dran.

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

Ich muss es für AWS Lambda verwenden, aber bei Verwendung von RestSharp.NetCore 105.2.3 geben AWS Fehler zurück
--Erkanntes Paket-Downgrade: System.Reflection von 4.3.0-preview1-24530-04 auf 4.1.0.

Bedeutet, dass RestSharp 4.1 verwendet, aber AWS die Version 4.3 unterstützt, für .NetCoreApp 1.0.

Haben wir eine Version mit Abhängigkeit von System.Runtime.Serialization.Primitives.4.3.0-preview1-24530-04?

Wir wechseln zu .net Core und haben gerade festgestellt, dass wir nicht auf RestSharp vom .net-Standard 2.0 verweisen können. Das Nuget-Paket kann nicht installiert werden.

Das Paket 'RestSharpSigned 105.2.3' wurde mit '.NETFramework,Version=v4.6.1' anstelle des Projektziel-Frameworks '.NETStandard,Version=v2.0' wiederhergestellt. Dieses Paket ist möglicherweise nicht vollständig mit Ihrem Projekt kompatibel.
Paketwiederherstellung fehlgeschlagen. Paketänderungen rückgängig machen für

@trampster Ich glaube, du

Ich verstehe, ich habe gepostet, um darauf hinzuweisen, dass eine Nachfrage besteht. Auch um zu zeigen, dass der .NET Framework-Kompatibilitätsmodus zum Verweisen auf vollständige .net-DLLs aus dem .net-Standard 2.0, wie von Microsoft bei der Veröffentlichung des .net-Standards 2.0 angekündigt, hier nicht funktioniert. Es gibt also keine Umgehung, wir sind blockiert.

Wir würden es vorziehen, nicht in eine andere Rest-Bibliothek wechseln zu müssen, aber wir werden es tun, wenn es nötig ist. Es hängt davon ab, wie lange diese Konvertierung dauert.

Interessanterweise gibt es ein RestSharp.NetCore-Paket auf nuget https://www.nuget.org/packages/RestSharp.NetCore mit 98.895 Downloads, aber soweit ich das beurteilen kann, ist der Uploader nicht mit dem Projekt verbunden, also weiß ich es nicht wenn ich darauf vertrauen kann.

@trampster Das ist eine Nuget-Warnung (die unterdrückt werden kann), siehe Wiederverwenden einer vorhandenen .NET Framework-Bibliothek . Was ist auch Ihr Zielframework in Ihrem csproj, ist es netcoreapp2.0 oder v4.6.1?

Schauen Sie sich die letzte Zeile noch einmal an. Es rollte es zurück. Danach habe ich keinen Hinweis auf RestSharp.

Auch wenn Sie meinen Beitrag lesen, werden Sie sehen, dass ich versuche, ihn vom .net-Standard 2.0 zu verwenden, nicht von netcore2.0 oder v4.6.1.

Es sollte auch beachtet werden, dass die Warnung besagt, dass v4.6.1 verwendet wurde, aber das RestSharp-Nuget-Paket nicht über v4.6.1 verfügt

@trampster Ich habe es mit der Kompatibilitätsbrücke erfolgreich in einer .NET Core 2.0-App installiert, aber wenn ich es ausführen HttpWebRequest . Ich habe keine Fehler bei der Installation des NuGet-Pakets erhalten, das ist also seltsam. 😃

Ich stoße auch darauf: \

Die Verwendung des aktuellen Nuget-Pakets in einer .NET Core-App ist nur möglich, wenn Sie auf das vollständige Framework abzielen.

Ich habe eine neue .NET Core-Konsolen-App erstellt, Install-Package RestSharp -Version 105.2.3 vom Paket-Manager ausgeführt und folgenden Code in Main hinzugefügt:

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

var-Anfrage = neuer RestRequest();
request.Resource = "users/restsharp/repos";

var-Antwort = client.Execute(request);
```

Die Ausrichtung auf netcoreapp2.0 ergibt System.PlatformNotSupportedException: Operation is not supported on this platform. aber es funktioniert, wenn Sie in csproj zu <TargetFramework>net46</TargetFramework> wechseln.

Wir zielen nicht auf den vollständigen Rahmen ab

@niemyjski Vielleicht versuchen Sie es mit RestSharp.NetCore, während Sie darauf warten, dass diese Bibliothek aktualisiert wird. Es wird von den folgenden Bibliotheken verwendet, daher sollte es stabil genug für die Verwendung sein.

ADH.PushCore
AppVeyorSharp
CoreLib.Web
CouchDB.Client
DocuSign.NetCore
Flip.PomboCorreio.Connector
FluentEmail.Mailgun
GiphyApiClient.NetCore
Intercom.Core
IronSphere.Handlanger
MasterCard-Core-Inoffiziell
mbank-dotnet
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Onlineseiten.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

Weiß jemand, wer der Uploader von RestSharp.NetCore ist? Ich habe mir dort github angesehen und sie haben keine Gabel von RestSharp. Auf dem Paket ist keine Lizenz aufgeführt, soweit ich weiß, dass es bösartig ist.

Wer auch immer dieses Projekt besitzt, sollte sich um den Besitz des restsharp-Paketnamensraums bemühen ... und dieses Paket wahrscheinlich entfernen. Ich würde wahrscheinlich sehen, ob dieses Paket schädliche Inhalte enthält, indem ich es dekompiliere

Am 5. Oktober 2017 um 22:57 Uhr,

@niemyjski (https://github.com/niemyjski) Vielleicht versuchen Sie es mit RestSharp.NetCore (https://www.nuget.org/packages/RestSharp.NetCore/), während Sie darauf warten, dass diese Bibliothek aktualisiert wird. Es wird von den folgenden Bibliotheken verwendet, daher sollte es stabil genug für die Verwendung sein.

ADH.PushCore
AppVeyorSharp
CoreLib.Web
CouchDB.Client
DocuSign.NetCore
Flip.PomboCorreio.Connector
FluentEmail.Mailgun
GiphyApiClient.NetCore
Intercom.Core
IronSphere.Handlanger
MasterCard-Core-Inoffiziell
mbank-dotnet
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Onlineseiten.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

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an (https://github.com/restsharp/RestSharp/issues/992#issuecomment-334651808) oder schalten Sie den Thread stumm (https://github.com/notifications/unsubscribe-auth /AA-So9HrYQHV5nlV1m7W7eY-y_F5cBqqks5spaUXgaJpZM4PLH2m).

@alexeyzimarev Gibt es eine Chance, heute ein Prerelease-Nuget-Paket zu bekommen? Auch wenn es eine Beta ist und alle Tests funktionieren, aber einige andere Dinge können sich ändern.

Leider funktioniert RESTsharp nicht mit Core 2.0. Schätze, es ist zurück zu HttpClient

@niemyjski Nein, tut mir leid. Ich ändere WebRequest zu HttpClient und das ist eine große Änderung. Der Grund dafür ist, dass WebRequest nur für Netstandard 2.0 verfügbar ist und wir 1.6 unterstützen wollen.

@niemyjski Ich kann meine Änderungen in einem separaten Branch veröffentlichen, wenn Sie helfen möchten-

Ich bin jetzt tatsächlich auf Netstandard 2.0 umgestiegen. netstandard 1.6 scheint zu viel Arbeit zu sein. Aber ich möchte immer noch HttpClient verwenden.

Schau dir das an: https://github.com/restsharp/RestSharp/tree/netstandard
PRs willkommen.

@amivit Du kannst etwas von deiner Zeit dazu beitragen, dass es passiert, oder?

Ich ändere WebRequest zu HttpClient und das ist eine große Änderung. Der Grund dafür ist, dass WebRequest nur für Netstandard 2.0 verfügbar ist und wir 1.6 unterstützen wollen.

Dies ist eine falsche Aussage, da das Nuget-Paket

Wäre es schwierig, zunächst bei WebRequest zu bleiben und dann im Laufe der Zeit auf HttpClient umzusteigen?

@mguinness Haben Sie versucht, dieses Paket zu verwenden? Ich tat.

@mguinness Wir können sagen - vergiss 1.6, wir entscheiden uns für 2.0 und behalten WebRequest. Damit komme ich persönlich gut zurecht.

Entschuldigung @alexeyzimarev, ich habe keine Zeit, etwas beizutragen. Ich wünsche. Ich bin nur überrascht, dass sich RESTsharp nicht von Anfang an auf HttpClient verlässt. Ist es nicht seit 2012 oder .NET 4.5 eine verfügbare Verbesserung gegenüber WebClient?

@amivit Wahrscheinlich ein Fall, wenn es nicht kaputt ist, repariere es nicht.

Sorry, dass ich hier nur mimimie :rofl:
aber nach dem Upgrade meiner Client-Anwendung auf .net core 2.0 erhalte ich einige Warnungen zu RestSharp:

Warnung NU1603: RestSharp.NetCore 105.2.3 hängt von System.Runtime.Serialization.Formatters (>= 4.0.0-rc4-24217-03) ab, aber System.Runtime.Serialization.Formatters 4.0.0-rc4-24217-03 war nicht gefunden. Eine ungefähre beste Übereinstimmung von System.Runtime.Serialization.Formatters 4.3.0-preview1-24530-04 wurde aufgelöst.

Ich habe vorerst nicht versucht, die Anwendung auszuführen - ich denke, es wird nicht funktionieren.
RestSharp unterstützt .net Core 2.0 noch nicht. Aber wird es eines Tages? Gibt es schon ein Datum? Kann ich hier helfen, dies zu ermöglichen (als Mitwirkender)?

@matthiasburger überprüfe den netstandard-Zweig. Ich habe dies nur ein paar Beiträge über Ihrem Kommentar erwähnt.

Gehen Sie jetzt mit 2.0. Kann es später jederzeit ändern, um ein HTTP-Client zu sein ... Auch
Stellen Sie sicher, dass Sie über die Compiler-Direktiven verfügen, um die Synchronisierungsmethoden zu verwenden
(RAHMEN)

Vielen Dank
-Blake Niemyjski

Am Mittwoch, 11. Oktober 2017 um 6:43 Uhr, Alexey Zimarev [email protected]
schrieb:

@matthiasburger https://github.com/matthiasburger check the netstandard
Zweig.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/restsharp/RestSharp/issues/992#issuecomment-335782906 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AA-So8akA6MlKfoypWDSAqaElcYBPFoAks5srKnUgaJpZM4PLH2m
.

sry @alexeyzimarev manchmal sollte ich alles lesen -

@niemyjski Alle Pragma-Direktiven werden entfernt. Ich möchte keine Abweichungen pro Plattform, Framework usw. haben. Dies ist, was netstandard zu lösen erklärt und ich werde es verwenden.

Ok, also wird der netstandard Zweig jetzt sowohl für signierte als auch für unsignierte erstellt. Immer noch habe ich vier Tests, die fehlschlagen (Encodieren, Decodieren). Integrationstests noch nicht enthalten. Hoffentlich kann ich den Code diese Woche fertigstellen, aber Build und Pack erfordern noch etwas mehr Arbeit, um zu DotNetCli zu wechseln.

Okay, alles scheint zu funktionieren. Ich musste zwei Tests wegen nicht unterstützter Ausnahmen vom HttpListener (Integration) bedingt ignorieren. Erwarten Sie jedoch, dass es funktioniert, wenn es mit einem richtigen Server verwendet wird.

Jetzt muss das Build-Skript geändert werden, um DotNetCli zu verwenden und nuget.exe nicht mehr zu verwenden

Mach weiter so @alexeyzimarev! Kann die erste Veröffentlichung kaum erwarten

Bitte testen Sie https://www.nuget.org/packages/RestSharp/106.0.0-alpha0277

Getestet 106.0.0-alpha0277 in VS2017 und echtem IIS für .NET Core 2.0

ErrorException: System.PlatformNotSupportedException: Der Vorgang wird auf dieser Plattform nicht unterstützt.
bei System.Net.SystemWebProxy.GetProxy(Uri-Ziel)
at System.Net.ServicePointManager.ProxyAddressIfNecessary(Uri& Adresse, IWebProxy-Proxy)
at System.Net.ServicePointManager.FindServicePoint(Uri-Adresse, IWebProxy-Proxy)
bei System.Net.HttpWebRequest.get_ServicePoint()
at RestSharp.Http.ConfigureWebRequest(String-Methode, Uri-URL)
at RestSharp.Http.PostPutInternal(String-Methode)
at RestSharp.Http.AsPost(String httpMethod)
at RestSharp.RestClient.DoExecuteAsPost(IHttp http, String-Methode)
at RestSharp.RestClient.Execute(IRestRequest request, String httpMethod, Func`3 getResponse)

Ich weiß, dass sie im Laufe der Zeit viele IsXYZ-Methoden hinzugefügt haben. Vielleicht müssen wir diese überprüfen, bevor wir diese Methoden aufrufen oder umschließen?

Es wäre gut, diese Tests unter Linux auszuführen, da ich denke, dass dabei viel mehr Probleme auftreten würden als unter Windows.

@ maciek12305 Es reicht nicht aus, hier eine Ausnahme zu kopieren und

@niemyjski Ich stimme der Ausführung von Tests unter Linux zu, dies erfordert jedoch das Einrichten eines neuen CI-

Scheint ein Problem mit dem Proxy zu sein https://github.com/Azure/azure-iot-sdk-csharp/issues/140

Ok, das Problem ist, dass .NET Core den Standardproxy nicht unterstützt, da die Einstellungen für den Standardproxy aus der Registrierung geladen werden.

Es sollte also funktionieren, wenn Sie keinen Proxy verwenden, und es stürzt unter .NET Core ab, wenn ein Proxy verwendet wird. Fürs Erste habe ich die Klasse "Standard-Proxy" hinzugefügt, die besagt, dass alles umgangen und direkt gestartet werden soll. Wenn Sie einen Proxy verwenden müssen, müssen Sie ihn mit der Methode ConfigureProxy bereitstellen.

Bitte versuchen Sie das neueste Paket: https://www.nuget.org/packages/RestSharp/106.0.0-alpha0281

@niemyjski Tatsächlich bestehen Integrationstests auf dem Mac

@alexeyzimarev Das neueste Paket hat bei mir unter Win 10 nicht funktioniert. Die einzige Möglichkeit für mich, es zum

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

@mguinness also warum behalten Sie den alten Wert (nicht sicher, was er ist) in der Variablen proxy ? Ich denke, die einzige Zeile, die einen Unterschied machen kann, ist die

WebRequest.DefaultWebProxy = null;

Ich kann es leicht hinzufügen, wenn das hilft.

@alexeyzimarev Es gab einen Fehler im Framework, der "WebRequest.DefaultWebProxy: Set funktioniert nicht ohne vorheriges Get" festschreibt.

Ich verstehe jetzt. Ich kann versuchen, ein Paket zu erstellen, indem ich die Anforderungs-Proxy-Eigenschaft auf null setze, anstatt die Standardeinstellung zu manipulieren.

@mguinness das neue Paket ist da, danke für die Hilfe!

@mavanmanen kannst du das auch mit UWP versuchen? https://www.nuget.org/packages/RestSharp/106.0.0-alpha0282

Mit Version 106.0.0-alpha0282 der gleiche Fehler "Operation wird auf dieser Plattform nicht unterstützt."

@remiskaune haben Sie versucht, diese Zeilen in Ihren Code aufzunehmen?

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

Vielen Dank. Es funktioniert jetzt mit diesen Zeilen auf Version 106.0.0-alpha0282.

Die Frage ist also, warum es ohne nicht funktioniert, da ich diese Zeilen in den RestSharp-Code eingefügt habe ...

Hat WebRequest vielleicht einen anderen Umfang? Ist es eine statische Klasse oder eine Instanz?

Sie können dies herausfinden, indem Sie eine Beispiel-App erstellen und in Ihrer Beispiel-App Folgendes überprüfen:

WebRequest.DefaultWebProxy

Und auch eine Methode für RestSharp verfügbar zu machen, um den angezeigten Wert zu senden (für Debugging-Zwecke) - zB:

public IWebProxy GetCurrentProxy() => WebRequest.DefaultWebProxy;

Sehen Sie, ob die beiden unterschiedlich sind?

@qJake Ich würde mich aufwenden können, werde auf einer Konferenz sprechen.

Ein neues Paket ist verfügbar, bei dem das Proxy-Problem "behoben" ist, indem WebRequest.DefaultProxy null zugewiesen wird. Dies könnte Konsequenzen haben, aber ich erwarte keine echten Probleme. Die Problemumgehung wird nur der .NET Standard-Assembly hinzugefügt. Die .NET Framework-Assembly sollte wie zuvor funktionieren.
https://www.nuget.org/packages/RestSharp/106.0.0-alpha0284

Wenn keine Probleme gemeldet werden, werde ich mit der Vorbereitung der Veröffentlichung beginnen.

Ziemlich positive Resonanz hier. Ich spielte herum und versuchte, ein abhängiges Paket zum Laufen zu bringen (Atlassian.JIRA) und nahm an, dass ich auf den .NET-Standard 2.0 abzielte, dann "funktionierten" alle Integrations- / Unit-Tests "einfach", also LGTM.

https://bitbucket.org/farmas/atlassian.net-sdk/issues/306/support-for-dotnet-core für den Thread an diesem Ende.

Ich habe es mit unserer Lösung getestet und es funktioniert gut.

Wir verwenden es aus .net Standard 2.0-Projekten und .net 4.6.1-Projekten

Bei Verwendung aus dem .net 4.6.1. Projekte zieht es in den folgenden Referenzen, die Visual Studio mit gelben Ausrufezeichen markiert.
System.Net.Http
System.Runtime.Serialization.Primitives
System.Sicherheit.Kryptographie.Algorithmen
System.Security.Cryptography.Encoding
System.Security.Cryptography.Primitives
System.Security.Cryptography.X509Zertifikate

Ich bin mir nicht sicher, warum das so ist, aber es scheint keine Probleme zu verursachen.

Das einzige kleine Problem, das wir haben, ist, dass wir Clickonce verwenden, um eines unserer Tools zu verteilen, sodass wir gezwungen sind, alles mit einem starken Namen zu versehen. Allerdings ist die Vorabversion nicht stark benannt. Wir haben die RestSharpSigned-Version des Pakets verwendet, aber es gibt keine Vorabversion davon mit .net-Standardunterstützung.

Es kann problematisch sein, eine stark benannte und eine nicht stark benannte Version zu haben, wenn Sie zwei Abhängigkeiten haben, eine davon abhängig von der stark benannten Version und eine, die von der nicht stark benannten Version abhängig ist.

Stattdessen schlage ich vor, ein Paket zu haben, das signiert ist und auf die Hauptversion Ihrer Assemblyversion einfriert (in SemVer ändert sich die Hauptversion nur, wenn Sie die Kompatibilität unterbrechen) und dann den vollständigen SemVer auf Ihrer FileVersion zu verwenden. Auf diese Weise haben Sie ein Nuget-Paket, das jeder verwenden kann (mit starkem Namen oder nicht) und das Einfrieren der Hauptversion bedeutet, dass keine Bindungsweiterleitungen erforderlich sind. Und mit SemVer weiß jeder genau, wo er in Sachen Kompatibilität steht.

Ich schlage dies hier vor, weil der Wechsel zum .net-Standard ein guter Zeitpunkt sein könnte, um diese Änderung vorzunehmen.

Wir sollten das Paket einfach standardmäßig signieren und den Schlüssel in GitHub ablegen. Das .net-Team empfiehlt dies, da es nicht schadet.

Gibt es eine PR, in der ich die Änderungen einsehen kann?

@niemyjski Ich develop für alle sichtbar ist. Ich habe es auch zu einem Standardzweig gemacht.

@niemyjski "Einfach" funktioniert in diesem Fall nicht. Wenn Sie helfen möchten - tun Sie es bitte. Ich musste Signed Projekte entfernen, weil der gesamte Lösungsbuild aufgrund eines Fehlers in Nuget fehlgeschlagen ist.
https://github.com/dotnet/standard/issues/538
https://github.com/NuGet/Home/issues/6038

Also muss ich entweder warten, bis es behoben ist, oder ich muss eine separate Lösung und Projekte hinzufügen und dann alle Dateien manuell einschließen, was unangenehm ist.

@alexeyzimarev haben nur ein csproj und signieren es, Frieren Sie die Assembly-Versionsnummer (auf die Hauptversion) ein, um Probleme mit der Bindungsweiterleitung zu vermeiden. Verwenden Sie Standard-SemVer für Nuget- und Dateiversionen. Dies wird alle Ihre Probleme lösen.

Wenn Sie darauf bestehen, zwei Versionen beizubehalten (was für Ihre Benutzer Probleme bereiten wird), können Sie dies immer noch mit einem einzigen csproj über die Konfiguration tun.

Ich habe dies ursprünglich in meinem eigenen Projekt gemacht (und es funktionierte), bevor mir klar wurde, wie kaputt es war, zwei Versionen zu haben. Grundsätzlich habe ich eine StrongName-Eigenschaftsgruppe hinzugefügt. Dann bauen Sie mit 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>

Wenn Sie auf eine Lösung der von Ihnen angesprochenen Probleme warten, können Sie lange warten.

Dies wird alle Ihre Probleme lösen.

Ich liebe es einfach.

Der Vorschlag für die Eigenschaftsgruppe ist wertvoll. Ich werde versuchen, zwei Pakete zu behalten, sonst wird es Verwirrung stiften. Ich könnte mich irren, aber ich persönlich würde es vermeiden, zu unterschreiben. Aber da Sie es brauchen - werde ich versuchen, ein Paket mit einer signierten Assembly zu erstellen.

@niemyjski hast du einen Link zu "Das .net-Team empfiehlt dies"? Ich muss mehr über die Konsequenzen wissen und wie genau sie dies vorschlagen.

Ich habe mit ihnen gesprochen und ich weiß, dass sie es auch öffentlich gesagt haben in
Foren und locker. Es ist ein Witz und sollte entfernt werden (
https://twitter.com/terrajobst/status/774752534682402817).. Es ist besser zu
nur einen starken Namen für die Baugruppe... Wir geben allen unseren Baugruppen einen starken Namen und
Lassen Sie den Signier-Snk im Repo, da es ein Witz ist. Jeder mit einem Hex-Editor
kann starke Namenssignaturen umgehen und es schadet nur denen, die dazu verpflichtet sind
ihre Pakete signieren, damit sie keine Abhängigkeiten annehmen. Sie können auf eine starke verweisen
signiertes Paket von einem unsignierten Paket, warum also nicht einfach alles unterschreiben
Zeit.

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

Vielen Dank
-Blake Niemyjski

Am Mi., 1. November 2017 um 13:30 Uhr, Alexey Zimarev [email protected]
schrieb:

@niemyjski https://github.com/niemyjski hast du einen Link zu "The .net
Team empfiehlt dies"? Ich muss mehr über die Konsequenzen wissen und wie?
genau sie schlagen vor, dies zu tun.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/restsharp/RestSharp/issues/992#issuecomment-341197289 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AA-So94xh-jiEMniw0D2QaGQPgT9zfBfks5syLjDgaJpZM4PLH2m
.

Okay, ich unterschreibe es einfach.

Es ist freigegeben. https://www.nuget.org/packages/RestSharp/106.0.0

Sie sollten hier bei github ein Release-Tag erstellen. :)

Markiert

In den Versionshinweisen zu 106.1.0 wird Folgendes erwähnt:
"Das Proxy-Problem in .NET Core behoben"

Ich bin mir nicht sicher, was dieser Fix abdeckt, aber wir haben immer noch Probleme bei der Verwendung des Proxys.
Vor unserer .NET Core 2.0-Portierung (von .NET Framework 4.6.1) haben wir den Client so instanziiert und es funktionierte wie ein Zauber.

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

Die Verwendung des gleichen Codes im .NET Core 2.0-Projekt führt zu folgendem Antwortfehler:

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

Der Code, der die Anfrage auslöst, sieht so aus:

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

Irgendwelche Gedanken?

Danke,
Fred

Haben Sie einen funktionierenden Code für .NET Core 2.0?

Wenn Sie den Stacktrace überprüfen, werden Sie feststellen, dass dies nicht unsere Ausnahme ist, sondern die .NET-Ausnahme, wenn versucht wurde, einen Standard-Proxy zu erhalten.

Ja, du hast recht @alexeyzimarev , die Ausnahme wird atually bei System.Net.SystemWebProxy.GetProxy geworfen, ich war zu schnell am Trigger. :)

Für andere, die auf das gleiche Problem stoßen, können Sie explizit angeben, welcher Proxy wie folgt verwendet werden soll:

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

Ich habe auf .NET Core 2.0 von 106.1.0 auf 106.2.0 aktualisiert und diese Meldung wird angezeigt:

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

Wie von anderen erwähnt, scheint diese Nachricht von System.Net.SystemWebproxy.GetProxy generiert zu werden, aber in meinem Fall konfiguriere ich keinen Proxy explizit, intern führt er seine eigenen Operationen durch und löst bei jeder von mir gestellten Anfrage eine Ausnahme aus.

Ich habe wieder auf 106.1.0 zurückgegriffen und dies hat es behoben, also hat sich in 106.2.0 etwas geändert, wo die Proxy-Einstellungen in irgendeiner Weise explizit sein müssen?

@voicebooth dies wird in #1061 gemeldet