938

Mendukung .NET Standard 2.0 berarti mendukung semua platform ini :

• .NET Framework 4.6.1
• .NET Inti 2.0
• Mono 5.4
• Xamarin.iOS 10.14
• Xamarin.Mac 3.8
• Xamarin.Android 7.5
• UWP vNext (pengiriman akhir tahun ini)

Saat menjalankan RestSharp menggunakan kompatibilitas mundur shim , sebagian besar berfungsi, hanya ada masalah dengan kelas dasar yang digunakan untuk memanggil panggilan HTTP - jika klien HTTP dialihkan dengan HttpClient baru , itu akan berfungsi.

Sebagai catatan pribadi, kami menggunakan RestSharp cukup sedikit di sini di kantor kami, dan kami sudah bekerja pada solusi berbasis cloud baru yang berjalan menggunakan ASP.NET Core, jadi kami sangat ingin melihat RestSharp dibawa ke .NET terbaru versi sehingga kita tidak perlu beralih ke perpustakaan REST baru.

@qJake Karena .NET Standard 2.0 memiliki permukaan API yang sangat diperluas, tentunya HttpWebRequest dapat dipertahankan alih-alih beralih ke HttpClient. Mungkin masalah yang Anda alami dengan shim sudah tidak ada lagi?

Mengapa .NET Standar 2.0? Harap pertimbangkan untuk menargetkan versi terendah yang tersedia.

@mguinness Lihat komentar ini di proyek @dotnet/corefx - HttpWebRequest bukan bagian dari .NET Standard, tetapi System.Net.Http.HttpClient adalah.

Harap pertimbangkan untuk mendukung versi UWP saat ini juga. (sebelum Pembaruan Pembuat Konten Musim Gugur)

Versi UWP saat ini berarti netstandard1.4. Saya tidak yakin apa konsekuensinya, perlu mulai bereksperimen.

@qJake Yah HttpWebRequest ada di .NET Standard 2.0, pernyataan Anda hanya berlaku untuk .NET Standard 1.6 dan di bawahnya.

@mguinness Oh, saya mengerti - baik itu menghadirkan tantangan, lalu - karena RestSharp menggunakan HttpWebRequest/Response, apakah kami hanya mendukung .NET Standard 2.0 dan tetap menggunakan kelas-kelas itu, atau apakah kami memperbaiki klien yang mendasarinya dan beralih ke HttpClient , memungkinkan kami untuk mendukung versi .NET Standard yang lebih lama?

Orang menginginkan 1.4 karena masalah dengan versi UWP saat ini. NETStandard 2.0 hanya akan didukung di UWP vNext.

@qJake FWIW, ada juga paket nuget System.Net.Requests yang dapat digunakan di versi .NET Standard sebelumnya.

Hai teman-teman, ada pembaruan atau ETA tentang ini? Berencana menggunakan RestSharp pada aplikasi dotnet core 2 saya dan saya tidak ingin berpindah paket.

Ini sedang dalam proses. Hal-hal lama telah dihapus tetapi kami mungkin akan bersama-sama membawa JSON.NET ke rilis juga. Pantau terus.

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

Saya perlu menggunakannya untuk AWS Lambda, tetapi saat menggunakan RestSharp.NetCore 105.2.3 AWS mengembalikan kesalahan
--Penurunan versi paket yang terdeteksi: System.Reflection dari 4.3.0-preview1-24530-04 ke 4.1.0.

Berarti RestSharp menggunakan 4.1 tetapi AWS mendukung set versi 4.3, untuk .NetCoreApp 1.0.

Apakah kita versi dengan ketergantungan pada System.Runtime.Serialization.Primitives.4.3.0-preview1-24530-04?

Kami pindah ke .net core dan baru saja menemukan bahwa kami tidak dapat mereferensikan RestSharp dari .net standar 2.0 paket nuget gagal diinstal.

Paket 'RestSharpSigned 105.2.3' dipulihkan menggunakan '.NETFramework,Version=v4.6.1' alih-alih kerangka kerja target proyek '.NETStandard,Version=v2.0'. Paket ini mungkin tidak sepenuhnya kompatibel dengan proyek Anda.
Pemulihan paket gagal. Mengembalikan perubahan paket untuk

@trampster Saya pikir Anda salah paham tentang statusnya. Paket RestSharp resmi tidak mendukung .NET Standard dan terakhir diperbarui pada tahun 2015. Konversi yang sedang dikerjakan oleh alexeyzimarev belum dipublikasikan AFAIK.

Saya mengerti, saya memposting untuk membantu menunjukkan ada permintaan untuk itu. Juga untuk menunjukkan bahwa mode kompatibilitas .NET Framework untuk referensi .net lengkap dll dari .net standar 2.0 seperti yang diumumkan oleh Microsoft saat merilis .net standar 2.0 tidak berfungsi di sini. Jadi tidak ada jalan keluar, kami diblokir.

Kami lebih suka untuk tidak harus beralih ke perpustakaan Istirahat lain, tetapi kami akan melakukannya jika perlu. Ini akan tergantung pada berapa lama konversi ini akan berlangsung.

Menariknya ada paket RestSharp.NetCore di nuget https://www.nuget.org/packages/RestSharp.NetCore dengan 98.895 unduhan, namun sejauh yang saya tahu pengunggah tidak terkait dengan proyek jadi saya tidak tahu jika saya bisa mempercayainya.

@trampster Itu peringatan nuget (yang dapat ditekan), lihat Menggunakan kembali pustaka .NET Framework yang ada . Juga apa kerangka kerja target Anda di csproj Anda, apakah itu netcoreapp2.0 atau v4.6.1?

Lihatlah kedua baris terakhir. Itu menggulungnya kembali. Setelah itu saya tidak memiliki referensi ke RestSharp.

Juga jika Anda membaca posting saya akan melihat saya mencoba menggunakannya dari .net standar 2.0 bukan netcore2.0 atau v4.6.1.

Perlu juga dicatat bahwa peringatan mengatakan v4.6.1 telah digunakan tetapi paket nuget RestSharp tidak memiliki v4.6.1

@trampster Saya telah berhasil menginstalnya ke dalam aplikasi .NET Core 2.0 menggunakan jembatan kompatibilitas, tetapi ketika saya menjalankannya, saya mendapatkan pengecualian runtime yang bermuara pada penggunaan HttpWebRequest . Saya tidak mendapatkan kegagalan pemasangan paket NuGet, jadi itu aneh. 😃

Saya juga mengalami ini :\ @alexeyzimarev bagaimana komunitas dapat membantu. Kami membutuhkan ini dan semua diblokir dalam hal ini. Saya menjalankan paket OAuth2 yang menggunakan perpustakaan ini dan semua orang diblokir untuk menggunakannya juga.

Menggunakan paket nuget saat ini di aplikasi .NET Core hanya dimungkinkan jika Anda menargetkan kerangka kerja penuh.

Saya membuat aplikasi konsol .NET Core baru, menjalankan Install-Package RestSharp -Version 105.2.3 dari Package Manager dan menambahkan kode berikut ke Main:

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

var permintaan = restRequest baru();
request.Resource = "pengguna/restsharp/repos";

var respon = klien. Jalankan(permintaan);
```

Menargetkan netcoreapp2.0 akan memberikan System.PlatformNotSupportedException: Operation is not supported on this platform. tetapi akan berhasil jika Anda mengubah ke <TargetFramework>net46</TargetFramework> di csproj.

Kami tidak menargetkan kerangka kerja penuh

@niemyjski Mungkin coba RestSharp.NetCore sambil menunggu perpustakaan ini diperbarui. Ini sedang digunakan oleh perpustakaan berikut sehingga harus cukup stabil untuk digunakan.

ADH.PushCore
AplikasiVeyorTajam
CoreLib.Web
CouchDB.Client
DocuSign.NetCore
Flip.PomboCorreio.Connector
LancarEmail.Mailgun
GiphyApiClient.NetCore
Interkom.Inti
IronSphere.Henchmen
MasterCard-Core-Tidak Resmi
mbank-dotnet
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Situs Online.TokoFacilBradesco
pendorong-http-dotnet-core
RepositoriFramework.Api
RepositoryFramework.EntityFramework
RestSharp.Newtonsoft.Json
RestSharp.Newtonsoft.Json.NetCore
Slack.Webhooks.Core
StoneCo.PomboCorreio.Connector
SwitchAPI.Konektor
Syncromatics.Clients.Metro.Api
TransportApi.Sdk.NetCore
Twilio.NetCore
UtilityFramework.Application.Core
UtilityFramework.Services.Iugu.Core

Adakah yang tahu siapa pengunggah RestSharp.NetCore? Saya melihat di sana github dan mereka tidak memiliki garpu RestSharp. Tidak ada lisensi yang tercantum pada paket, yang saya tahu itu berbahaya.

Siapa pun yang memiliki proyek ini harus mencari kepemilikan namespace paket restsharp... dan mungkin menghapus paket itu. Saya mungkin akan melihat apakah paket itu berisi konten berbahaya dengan mendekompilasinya

Pada tanggal 5 Oktober 2017 pukul 22.57,

@niemyjski (https://github.com/niemyjski) Mungkin coba RestSharp.NetCore (https://www.nuget.org/packages/RestSharp.NetCore/) sambil menunggu perpustakaan ini diperbarui. Ini sedang digunakan oleh perpustakaan berikut sehingga harus cukup stabil untuk digunakan.

ADH.PushCore
AplikasiVeyorTajam
CoreLib.Web
CouchDB.Client
DocuSign.NetCore
Flip.PomboCorreio.Connector
LancarEmail.Mailgun
GiphyApiClient.NetCore
Interkom.Inti
IronSphere.Henchmen
MasterCard-Core-Tidak Resmi
mbank-dotnet
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Situs Online.TokoFacilBradesco
pendorong-http-dotnet-core
RepositoriFramework.Api
RepositoryFramework.EntityFramework
RestSharp.Newtonsoft.Json
RestSharp.Newtonsoft.Json.NetCore
Slack.Webhooks.Core
StoneCo.PomboCorreio.Connector
SwitchAPI.Konektor
Syncromatics.Clients.Metro.Api
TransportApi.Sdk.NetCore
Twilio.NetCore
UtilityFramework.Application.Core
UtilityFramework.Services.Iugu.Core

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub (https://github.com/restsharp/RestSharp/issues/992#issuecomment-334651808), atau nonaktifkan utas (https://github.com/notifications/unsubscribe-auth /AA-So9HrYQHV5nlV1m7W7eY-y_F5cBqqks5spaUXgaJpZM4PLH2m).

@alexeyzimarev apakah ada peluang untuk mendapatkan paket nuget pra-rilis di luar sana hari ini? Bahkan jika itu adalah beta dan semua tes berfungsi tetapi beberapa hal lain mungkin berubah.

Sedih RESTsharp tidak bekerja dengan Core 2.0. Kira itu kembali ke HttpClient

@niemyjski Tidak, maaf. Saya mengubah WebRequest ke HttpClient dan ini adalah perubahan besar. Alasannya adalah karena WebRequest hanya tersedia untuk netstandard 2.0 dan kami ingin mendukung 1.6.

@niemyjski Saya dapat mempublikasikan perubahan saya ke cabang terpisah jika Anda ingin membantu-

Saya sebenarnya beralih ke netstandard 2.0 sekarang. netstandard 1.6 tampaknya terlalu banyak bekerja. Tapi saya masih ingin menggunakan HttpClient.

Lihat ini: https://github.com/restsharp/RestSharp/tree/netstandard
PR selamat datang.

@amivit Anda dapat menyumbangkan sebagian waktu Anda untuk mewujudkannya, bukan?

Saya mengubah WebRequest ke HttpClient dan ini adalah perubahan besar. Alasannya adalah karena WebRequest hanya tersedia untuk netstandard 2.0 dan kami ingin mendukung 1.6.

Itu pernyataan yang salah karena ada paket nuget System.Net.Requests .

Apakah sulit untuk awalnya tetap menggunakan WebRequest dan kemudian beralih ke HttpClient dari waktu ke waktu?

@mguinness Sudahkah Anda mencoba menggunakan paket ini? Ya.

@mguinness Kami dapat mengatakan - lupakan 1.6, kami menggunakan 2.0 dan kami menyimpan WebRequest. Saya pribadi baik-baik saja dengan itu.

Maaf @alexeyzimarev saya tidak punya waktu untuk berkontribusi. Saya harap. Saya hanya terkejut RESTsharp tidak mengandalkan HttpClient untuk memulai. Bukankah ini merupakan peningkatan yang tersedia dari WebClient sejak 2012 atau .NET 4.5?

@amivit Mungkin kasus jika tidak rusak, jangan perbaiki.

Maaf baru mimimi disini :rofl:
tetapi setelah memutakhirkan aplikasi klien saya ke .net core 2.0 saya mendapatkan beberapa peringatan tentang RestSharp:

peringatan NU1603: RestSharp.NetCore 105.2.3 bergantung pada System.Runtime.Serialization.Formatters (>= 4.0.0-rc4-24217-03) tetapi System.Runtime.Serialization.Formatters 4.0.0-rc4-24217-03 tidak ditemukan. Perkiraan kecocokan terbaik System.Runtime.Serialization.Formatters 4.3.0-preview1-24530-04 telah diselesaikan.

Saya tidak mencoba menjalankan aplikasi untuk saat ini - saya kira itu tidak akan berhasil.
Jadi, RestSharp belum mendukung .net core 2.0. Tapi, akankah suatu hari nanti? Apakah sudah ada kencan? Bisakah saya membantu di sini untuk mewujudkannya (sebagai kontributor)?

@matthiasburger periksa cabang standar bersih. Saya menyebutkan ini hanya beberapa posting di atas komentar Anda.

Gunakan 2.0 untuk saat ini. Selalu dapat mengubahnya nanti menjadi klien http... Juga
pastikan Anda memiliki arahan kompiler untuk membuatnya memiliki metode sinkronisasi
(KERANGKA)

Terima kasih
-Blake Niemyjski

Pada Rabu, 11 Okt 2017 pukul 06:43, Alexey Zimarev [email protected]
menulis:

@matthiasburger https://github.com/matthiasburger periksa standar bersih
cabang.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/restsharp/RestSharp/issues/992#issuecomment-335782906 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AA-So8akA6MlKfoypWDSAqaElcYBPFoAks5srKnUgaJpZM4PLH2m
.

sry @alexeyzimarev terkadang saya harus membaca semuanya - bagus. saya perhatikan ya :)

@niemyjski Semua arahan pragma dihapus. Saya tidak ingin ada penyimpangan per platform, kerangka kerja, dll. Inilah yang dinyatakan oleh netstandard untuk dipecahkan dan saya akan menggunakannya.

Oke, jadi cabang netstandard sekarang dibuat untuk yang ditandatangani dan tidak ditandatangani. Masih saya memiliki empat tes yang gagal (encoding, decoding). Tes integrasi belum disertakan. Mudah-mudahan saya bisa menyelesaikan kode minggu ini tetapi membangun dan mengemas akan membutuhkan lebih banyak pekerjaan untuk beralih ke DotNetCli.

Oke, sepertinya semua berhasil. Saya harus mengabaikan dua tes secara kondisional karena pengecualian yang tidak didukung dari HttpListener (integrasi). Harapkan itu berfungsi ketika digunakan dengan server yang tepat.

Sekarang skrip build perlu diubah untuk menggunakan DotNetCli dan berhenti menggunakan nuget.exe

Teruslah berkarya @alexeyzimarev! Gak sabar nunggu rilisan pertama

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

Diuji 106.0.0-alpha0277 di VS2017 & penargetan IIS nyata .NET Core 2.0

ErrorException: System.PlatformNotSupportedException: Operasi tidak didukung pada platform ini.
di System.Net.SystemWebProxy.GetProxy(Uri tujuan)
di System.Net.ServicePointManager.ProxyAddressIfNecessary(Alamat Uri&, proxy IWebProxy)
di System.Net.ServicePointManager.FindServicePoint(alamat Uri, proxy IWebProxy)
di System.Net.HttpWebRequest.get_ServicePoint()
di RestSharp.Http.ConfigureWebRequest(Metode string, url Uri)
di RestSharp.Http.PostPutInternal(Metode string)
di RestSharp.Http.AsPost(String httpMethod)
di RestSharp.RestClient.DoExecuteAsPost(IHttp http, metode String)
di RestSharp.RestClient.Execute(permintaan IRestRequest, String httpMethod, Func`3 getResponse)

Saya tahu mereka menambahkan banyak metode IsXYZ dari waktu ke waktu, mungkin kita perlu memeriksanya sebelum memanggil metode ini atau membungkusnya?

Akan lebih baik untuk mulai menjalankan tes ini di Linux karena saya pikir itu akan menemukan lebih banyak masalah daripada di Windows.

@ maciek12305 tidak cukup untuk menyalin-menempel pengecualian di sini karena saya tidak tahu bagaimana Anda sampai di sana.

@niemyjski Saya setuju tentang menjalankan tes di Linux tetapi ini memerlukan pengaturan CI build baru. Saya akan melihat Travis nanti, mudah-mudahan minggu depan.

Sepertinya ada masalah dengan proxy https://github.com/Azure/Azure-iot-sdk-csharp/issues/140

Oke, masalahnya adalah .NET Core tidak mendukung proxy default karena pengaturan untuk proxy default dimuat dari registri.

Jadi, itu akan berfungsi jika Anda tidak menggunakan proxy dan itu akan macet di .NET Core jika proxy digunakan. Untuk saat ini saya menambahkan kelas "proxy default", yang mengatakan untuk melewati semuanya dan langsung pergi. Jika Anda harus menggunakan proxy - Anda harus menyediakannya menggunakan metode ConfigureProxy .

Silakan coba paket terbaru: https://www.nuget.org/packages/RestSharp/106.0.0-alpha0281

@niemyjski Sebenarnya tes integrasi lulus dengan baik di Mac. Jadi itu harus bekerja di Linux juga, saya kira.

@alexeyzimarev Paket terbaru tidak berfungsi untuk saya di Win 10. Satu-satunya cara bagi saya untuk membuatnya berfungsi adalah dengan memasukkan yang berikut ini dalam kode saya:

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

@mguinness jadi mengapa Anda menyimpan nilai lama (tidak yakin apa itu) dalam variabel proxy ? Saya kira satu-satunya baris, yang dapat membuat perbedaan adalah

WebRequest.DefaultWebProxy = null;

Saya dapat dengan mudah menambahkannya jika ini akan membantu.

@alexeyzimarev Ada bug dalam kerangka kerja yang melakukan "WebRequest.DefaultWebProxy: Set tidak berfungsi tanpa perbaikan Get sebelumnya".

Saya mengerti sekarang. Saya dapat mencoba membuat paket dengan menyetel properti Proxy permintaan ke nol alih-alih memanipulasi yang default.

@mguinness paket baru sudah keluar, terima kasih telah membantu!

@mavanmanen dapatkah Anda mencoba yang ini juga, dengan UWP? https://www.nuget.org/packages/RestSharp/106.0.0-alpha0282

Dengan versi 106.0.0-alpha0282 kesalahan yang sama "Operasi tidak didukung pada platform ini."

@remiskaune sudahkah Anda mencoba memasukkan baris-baris ini ke dalam kode Anda?

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

Terima kasih. Ini berfungsi sekarang dengan baris ini pada versi 106.0.0-alpha0282.

Jadi pertanyaannya adalah mengapa tidak bekerja tanpa, karena saya memasukkan baris-baris ini dalam kode RestSharp...

Mungkin WebRequest memiliki cakupan yang berbeda? Apakah ini kelas statis atau instance?

Anda bisa mengetahuinya dengan membuat aplikasi sampel, dan di aplikasi sampel Anda, periksa:

WebRequest.DefaultWebProxy

Dan juga mengekspos beberapa metode untuk RestSharp untuk mengirim nilai yang dilihatnya (untuk tujuan debugging) - misalnya:

public IWebProxy GetCurrentProxy() => WebRequest.DefaultWebProxy;

Lihat apakah keduanya berbeda?

@qJake Saya akan sangat menghargai jika seseorang dapat men-debug untuk saya :) Saya tidak akan dapat menghabiskan waktu untuk ini sampai minggu depan, akan berbicara di sebuah konferensi.

Paket baru tersedia di mana masalah proxy "diperbaiki" dengan menetapkan WebRequest.DefaultProxy ke null. Ini mungkin memiliki konsekuensi tetapi saya tidak mengharapkan masalah nyata. Solusinya hanya ditambahkan ke .NET Standard Assembly. Rakitan .NET Framework harus berfungsi seperti sebelumnya.
https://www.nuget.org/packages/RestSharp/106.0.0-alpha0284

Jika tidak ada masalah yang dilaporkan, saya akan mulai mempersiapkan rilis.

Respon yang cukup positif di sini. Saya bermain-main mencoba membuat paket dependen berfungsi (Atlassian.JIRA) dan dengan asumsi saya menargetkan .NET standar 2.0 maka semua integrasi/uji unit mereka "hanya berfungsi" jadi LGTM.

https://bitbucket.org/farmas/atlassian.net-sdk/issues/306/support-for-dotnet-core untuk utas di akhir itu.

Saya telah mengujinya terhadap solusi kami, dan itu berfungsi dengan baik.

Kami menggunakannya dari proyek .net standar 2.0 dan proyek .net 4.6.1

Saat digunakan dari .net 4.6.1. memproyeksikannya menarik referensi berikut, yang ditandai oleh studio visual dengan tanda seru berwarna kuning.
System.Net.Http
System.Runtime.Serialization.Primitives
Sistem.Keamanan.Kriptografi.Algoritme
System.Security.Cryptography.Encoding
Sistem.Keamanan.Kriptografi.Primitif
System.Security.Cryptography.X509Sertifikat

Saya tidak yakin mengapa ini terjadi, namun tampaknya tidak menimbulkan masalah.

Satu-satunya masalah kecil yang kami miliki adalah kami menggunakan clickonce untuk mendistribusikan salah satu alat kami sehingga kami terpaksa menyebutkan semuanya dengan kuat. Namun versi pra-rilis tidak bernama kuat. Kami telah menggunakan versi paket RestSharpSigned tetapi tidak ada versi pra-rilis dengan dukungan standar .net.

Memiliki versi bernama kuat dan tidak bernama kuat dapat menjadi masalah dalam situasi di mana Anda memiliki dua dependensi satu yang bergantung pada versi bernama kuat dan satu yang bergantung pada versi bernama tidak kuat.

Alih-alih ini saya sarankan memiliki satu paket yang ditandatangani dan dibekukan ke versi utama dari versi Majelis Anda (dalam SemVer versi utama hanya berubah ketika Anda merusak kompatibilitas) kemudian menggunakan SemVer penuh pada FileVersion Anda. Dengan cara ini Anda memiliki satu paket nuget yang dapat digunakan semua orang (bernama kuat atau tidak) dan pembekuan versi utama berarti bahwa pengalihan yang mengikat tidak diperlukan. Dan menggunakan SemVer berarti semua orang tahu persis di mana mereka berdiri dalam hal kompatibilitas.

Saya menyarankan ini di sini karena beralih ke standar .net mungkin saat yang tepat untuk melakukan perubahan ini.

Kami hanya harus menandatangani paket secara default dan memasukkan kuncinya ke GitHub , Tim .net merekomendasikan ini karena tidak ada salahnya.

Apakah ada PR yang bisa saya lihat perubahannya?

@niemyjski Saya menganggap cabang develop terlihat untuk semua. Saya menjadikannya cabang default juga.

@niemyjski "Hanya" tidak berfungsi dalam kasus ini. Jika Anda ingin membantu - silakan. Saya harus menghapus proyek Signed karena mereka gagal membangun seluruh solusi karena bug di nuget.
https://github.com/dotnet/standard/issues/538
https://github.com/NuGet/Home/issues/6038

Jadi saya harus menunggu sampai diperbaiki, atau saya harus menambahkan solusi dan proyek terpisah, dan kemudian memasukkan semua file secara manual, yang buruk.

@alexeyzimarev hanya memiliki satu csproj dan menandatanganinya, Bekukan nomor versi perakitan (ke versi utama) untuk menghindari masalah pengalihan yang mengikat. Gunakan SemVer standar untuk nuget dan versi file. Ini akan menyelesaikan semua masalah Anda.

Jika Anda bersikeras untuk menyimpan dua versi (yang akan menyebabkan masalah bagi pengguna Anda) maka Anda masih dapat melakukan ini dengan satu csproj melalui konfigurasi.

Saya melakukan ini pada awalnya di proyek saya sendiri (dan itu berhasil) sebelum saya menyadari betapa rusaknya memiliki dua versi. Pada dasarnya saya menambahkan grup properti StrongName. Kemudian bangun dengan 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>

Jika Anda menunggu perbaikan untuk masalah yang Anda angkat maka Anda bisa menunggu lama.

Ini akan menyelesaikan semua masalah Anda.

Saya hanya menyukainya.

Saran grup properti sangat berharga. Saya akan mencoba menyimpan dua paket, jika tidak maka akan membuat kebingungan. Saya mungkin salah tetapi secara pribadi saya hanya akan menghindari penandatanganan. Tetapi karena Anda membutuhkannya - saya akan mencoba membuat paket dengan Majelis yang ditandatangani.

@niemyjski apakah Anda memiliki tautan ke "Tim .net merekomendasikan ini"? Saya perlu tahu lebih banyak tentang konsekuensi dan bagaimana tepatnya mereka menyarankan melakukan ini.

Saya sudah berbicara dengan mereka dan saya tahu bahwa mereka juga mengatakannya secara terbuka di
forum dan kendur. Ini semacam lelucon dan harus dihapus (
https://twitter.com/terrajobst/status/774752534682402817).. Lebih baik untuk
cukup beri nama majelis yang kuat ... Kami kuatkan semua majelis kami dan
tinggalkan snk penandatanganan di repo karena itu lelucon. Siapa pun dengan editor hex
dapat melewati penandatanganan nama yang kuat dan itu hanya menyakiti mereka yang diharuskan
menandatangani paket mereka dari mengambil dependensi. Anda dapat mereferensikan yang kuat
paket yang ditandatangani dari paket yang tidak ditandatangani jadi mengapa tidak menandatanganinya saja?
waktu.

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

Terima kasih
-Blake Niemyjski

Pada hari Rabu, 1 Nov 2017 jam 13:30, Alexey Zimarev [email protected]
menulis:

@niemyjski https://github.com/niemyjski apakah Anda memiliki tautan ke ".net
tim merekomendasikan ini"? Saya perlu tahu lebih banyak tentang konsekuensi dan bagaimana
tepatnya mereka menyarankan melakukan ini.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/restsharp/RestSharp/issues/992#issuecomment-341197289 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AA-So94xh-jiEMniw0D2QaGQPgT9zfBfks5syLjDgaJpZM4PLH2m
.

Oke, saya hanya akan menandatanganinya.

Hal ini dirilis. https://www.nuget.org/packages/RestSharp/106.0.0

Anda harus membuat tag rilis di sini di github. :)

Ditandai

Catatan rilis untuk 106.1.0 menyebutkan:
"Memperbaiki masalah proxy di .NET Core"

Tidak yakin apa yang tercakup dalam perbaikan itu, tetapi kami masih menghadapi masalah dalam menggunakan proxy.
Sebelum port .NET Core 2.0 kami (berasal dari .NET Framework 4.6.1), kami membuat instance klien seperti ini dan itu bekerja dengan sangat baik.

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

Menggunakan kode yang sama dalam proyek .NET Core 2.0 memberi kami kesalahan respons berikut:

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

Kode yang memicu permintaan terlihat seperti ini:

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

Ada pikiran?

Terima kasih,
Fred

Apakah Anda memiliki kode kerja untuk .NET Core 2.0?

Bacause jika Anda memeriksa stacktrace, Anda akan melihat bahwa ini bukan pengecualian kami tetapi pengecualian .NET ketika mencoba mendapatkan proxy default.

Ya, Anda benar @alexeyzimarev , pengecualian sebenarnya dilemparkan ke System.Net.SystemWebProxy.GetProxy, saya harus cepat memicu. :)

Untuk orang lain yang mengalami masalah yang sama, Anda dapat secara eksplisit menentukan Proxy apa yang akan digunakan seperti ini:

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

Saya telah memutakhirkan dari 106.1.0 ke 106.2.0 di .NET Core 2.0 dan pesan ini mulai muncul:

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

Seperti yang disebutkan oleh orang lain, pesan ini tampaknya dihasilkan oleh System.Net.SystemWebproxy.GetProxy, tetapi dalam contoh saya, saya tidak secara eksplisit mengonfigurasi proxy sama sekali, secara internal ia melakukan operasinya sendiri dan memberikan pengecualian pada setiap permintaan yang saya buat.

Saya telah kembali ke 106.1.0 dan ini telah memperbaikinya, jadi apakah ada perubahan di 106.2.0 di mana pengaturan proxy harus eksplisit dalam beberapa cara?

@voicebooth ini dilaporkan di #1061