938

.NET मानक 2.0 का समर्थन करने का अर्थ होगा

• .NET फ्रेमवर्क 4.6.1
• .NET कोर 2.0
• मोनो 5.4
• Xamarin.iOS 10.14
• ज़ामरीन.मैक 3.8
• Xamarin.एंड्रॉयड 7.5
• UWP vNext (इस साल के अंत में शिपिंग)

बैकवर्ड संगतता शिम का उपयोग करते हुए RestSharp चलाते समय, यह अधिकांश भाग के लिए काम करता है, HTTP कॉल को लागू करने के लिए उपयोग किए जाने वाले अंतर्निहित वर्ग के साथ केवल समस्याएं हैं - यदि HTTP क्लाइंट को नए HttpClient के साथ स्विच किया

एक व्यक्तिगत नोट पर, हम यहां अपने कार्यालय में रेस्टशर्प का काफी उपयोग करते हैं, और हम पहले से ही नए क्लाउड-आधारित समाधानों पर काम कर रहे हैं जो एएसपी. संस्करण ताकि हमें एक नई आरईएसटी लाइब्रेरी में स्विच न करना पड़े।

@qJake चूंकि .NET मानक 2.0 में व्यापक रूप से विस्तारित API सतह है, निश्चित रूप से HttpClient पर स्विच करने के बजाय HttpWebRequest को बनाए रखा जा सकता है। हो सकता है कि शिम के साथ आपने जिन मुद्दों का अनुभव किया, वे अब मौजूद नहीं हैं?

क्यों .NET मानक 2.0? कृपया सबसे कम उपलब्ध संस्करण को लक्षित करने पर विचार करें।

@mguinness इस टिप्पणी को @dotnet/corefx प्रोजेक्ट में देखें - HttpWebRequest .NET मानक का हिस्सा नहीं है, लेकिन System.Net.Http.HttpClient है।

कृपया UWP के वर्तमान संस्करण का भी समर्थन करने पर विचार करें। (फॉल क्रिएटर्स अपडेट से पहले)

UWP के वर्तमान संस्करण का अर्थ होगा netstandard1.4. मुझे यकीन नहीं है कि इसके क्या परिणाम होंगे, प्रयोग शुरू करने की जरूरत है।

@qJake Well HttpWebRequest .NET मानक 2.0 में है, आपका दावा केवल .NET मानक 1.6 और उससे नीचे के लिए सही है।

@mguinness ओह, मैं देखता हूं - ठीक है जो एक चुनौती प्रस्तुत करता है, फिर - चूंकि RestSharp HttpWebRequest/प्रतिक्रिया का उपयोग करता है, क्या हम केवल .NET मानक 2.0 का समर्थन करते हैं और उन वर्गों के साथ चिपके रहते हैं, या क्या हम अंतर्निहित क्लाइंट को रिफैक्टर करते हैं और HttpClient स्विच करते हैं

यूडब्ल्यूपी के वर्तमान संस्करण के मुद्दों के कारण लोग 1.4 चाहते हैं। NETStandard 2.0 केवल UWP vNext में समर्थित होगा।

@qJake FWIW, System.Net.Requests nuget पैकेज भी है जिसका उपयोग .NET मानक के पुराने संस्करणों में किया जा सकता है।

हे दोस्तों, इस पर कोई अपडेट या ईटीए? अपने डॉटनेट कोर 2 ऐप पर रेस्टशर्प का उपयोग करने की योजना बना रहा हूं और मैं पैकेज स्विच नहीं करना चाहूंगा।

यह कार्य प्रगति पर है। पुराने सामान को हटा दिया गया है, लेकिन हम शायद JSON.NET को भी रिलीज में लाएंगे। बने रहें।

डब्ल्यूआईपी: https://github.com/alexeyzimarev/restsharp/tree/netstandard

मुझे इसे एडब्ल्यूएस लैम्ब्डा के लिए उपयोग करने की ज़रूरत है, लेकिन RestSharp.NetCore 105.2.3 एडब्ल्यूएस रिटर्न त्रुटियों का उपयोग करते समय
--पता लगाया गया पैकेज डाउनग्रेड: सिस्टम.प्रतिबिंब 4.3.0-पूर्वावलोकन1-24530-04 से 4.1.0 तक।

मीन्स रेस्टशर्प 4.1 का उपयोग कर रहा है, लेकिन .NetCoreApp 1.0 के लिए AWS 4.3 वर्जन सेट का समर्थन करता है।

क्या हम System.Runtime.Serialization.Primitives.4.3.0-preview1-24530-04 पर निर्भरता वाला संस्करण हैं?

हम .net कोर पर जा रहे हैं और अभी पाया है कि हम .net मानक 2.0 से RestSharp का संदर्भ नहीं दे सकते हैं, nuget पैकेज स्थापित करने में विफल रहता है।

पैकेज 'RestSharpSigned 105.2.3' को प्रोजेक्ट टारगेट फ्रेमवर्क '.NETStandard,Version=v2.0' के बजाय '.NETFramework,Version=v4.6.1' का उपयोग करके बहाल किया गया था। यह पैकेज आपके प्रोजेक्ट के साथ पूरी तरह से संगत नहीं हो सकता है।
पैकेज पुनर्स्थापना विफल। के लिए रोलिंग बैक पैकेज परिवर्तन

@trampster मुझे लगता है कि आप स्थिति को गलत समझते हैं। आधिकारिक RestSharp पैकेज .NET मानक का समर्थन नहीं करता है और आखिरी बार 2015 में अपडेट किया गया था। एलेक्सीज़िमारेव द्वारा काम किया जा रहा रूपांतरण अभी तक AFAIK प्रकाशित नहीं हुआ है।

मैं समझता हूं, मैं यह इंगित करने में मदद करने के लिए पोस्ट कर रहा था कि इसकी मांग है। साथ ही यह दिखाने के लिए कि .NET मानक 2.0 जारी करते समय Microsoft द्वारा घोषित .net मानक 2.0 से .net पूर्ण dll को संदर्भित करने के लिए .NET Framework संगतता मोड यहां काम नहीं कर रहा है। तो कोई काम नहीं है, हम अवरुद्ध हैं।

हम किसी अन्य रेस्ट लाइब्रेरी में शिफ्ट नहीं होना पसंद करेंगे, लेकिन जरूरत पड़ने पर हम करेंगे। यह इस पर निर्भर करेगा कि इस रूपांतरण में कितना समय लगेगा।

दिलचस्प बात यह है कि nuget पर एक RestSharp.NetCore पैकेज है https://www.nuget.org/packages/RestSharp.NetCore 98,895 डाउनलोड के साथ, हालांकि जहां तक ​​मैं बता सकता हूं कि अपलोडर परियोजना से जुड़ा नहीं है, इसलिए मुझे नहीं पता अगर मैं इस पर भरोसा कर सकता हूं।

@trampster यह एक नगेट चेतावनी है (जिसे दबाया जा सकता है), मौजूदा .NET Framework लाइब्रेरी का पुन: उपयोग करना देखें। इसके अलावा आपके csproj में आपका लक्ष्य ढांचा क्या है, क्या यह netcoreapp2.0 या v4.6.1 है?

अंतिम पंक्ति पर दूसरा नज़र डालें। इसने इसे वापस घुमाया। बाद में मेरे पास RestSharp का कोई संदर्भ नहीं है।

इसके अलावा अगर आप मेरी पोस्ट को पढ़ेंगे तो देखेंगे कि मैं इसे .net मानक 2.0 से उपयोग करने की कोशिश कर रहा हूं न कि netcore2.0 या v4.6.1 से।

यह भी ध्यान दिया जाना चाहिए कि चेतावनी कहती है कि v4.6.1 का उपयोग किया गया था लेकिन RestSharp nuget पैकेज में v4.6.1 नहीं है

@trampster मैंने इसे संगतता ब्रिज का उपयोग करके .NET Core 2.0 ऐप में सफलतापूर्वक स्थापित किया है, लेकिन जब मैं इसे चलाने के लिए जाता हूं तो मुझे एक रनटाइम अपवाद मिलता है जो HttpWebRequest उपयोग के लिए उबलता है। मुझे कोई NuGet पैकेज स्थापित विफलता नहीं मिली, इसलिए यह अजीब है। मैं

मैं इसमें भी भाग रहा हूं :\ @alexeyzimarev समुदाय कैसे मदद कर सकता है। हमें इसकी आवश्यकता है और इस पर सभी अवरुद्ध हैं। मैं OAuth2 पैकेज चलाता हूं जो इस लाइब्रेरी का उपयोग करता है और सभी को इसका उपयोग करने से भी रोक दिया गया है।

.NET कोर ऐप में वर्तमान नगेट पैकेज का उपयोग करना तभी संभव है जब आप पूर्ण ढांचे को लक्षित करते हैं।

मैंने एक नया .NET कोर कंसोल ऐप बनाया, पैकेज मैनेजर से Install-Package RestSharp -Version 105.2.3 चलाया और मेन में निम्नलिखित कोड जोड़ा:

```सी#
वर क्लाइंट = नया RestClient ();
client.BaseUrl = नया उरी ("https://api.github.com/");

वर अनुरोध = नया RestRequest ();
request.Resource = "उपयोगकर्ता/रेस्टशार्प/रेपो";

वर प्रतिक्रिया = ग्राहक। निष्पादित (अनुरोध);
```

netcoreapp2.0 को लक्षित करने से System.PlatformNotSupportedException: Operation is not supported on this platform. मिलेगा लेकिन यदि आप csproj में <TargetFramework>net46</TargetFramework> में बदलते हैं तो यह काम करेगा।

हम पूर्ण ढांचे को लक्षित नहीं कर रहे हैं

@niemyjski हो सकता है कि जब आप इस लाइब्रेरी के अपडेट होने की प्रतीक्षा करें तो RestSharp.NetCore आज़माएं। इसका उपयोग निम्नलिखित पुस्तकालयों द्वारा किया जा रहा है, इसलिए यह उपयोग के लिए पर्याप्त स्थिर होना चाहिए।

एडीएच.पुशकोर
AppVeyorतीव्र
कोरलिब.वेब
काउचडीबी.क्लाइंट
DocumentSign.NetCore
Flip.PomboCorreio.Connector
FluentEmail.Mailgun
GiphyApiClient.NetCore
इंटरकॉम.कोर
आयरनस्फीयर।गुर्गे
मास्टरकार्ड-कोर-अनौपचारिक
एमबैंक-डॉटनेट
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Onlinesites.ShopFacilBradesco
ढकेलनेवाला-http-डॉटनेट-कोर
रिपोजिटरीफ्रेमवर्क.एपीआई
RepositoryFramework.EntityFramework
रेस्टशार्प.न्यूटॉन्सॉफ्ट.जेसन
RestSharp.Newtonsoft.Json.NetCore
सुस्त।वेबहुक।कोर
स्टोनको.पोम्बोकोरेरियो.कनेक्टर
स्विचएपीआई। कनेक्टर
Syncromatics.Clients.Metro.Api
TransportApi.Sdk.NetCore
Twilio.NetCore
UtilityFramework.Application.Core
UtilityFramework.Services.Iugu.Core

क्या किसी को पता है कि RestSharp.NetCore का अपलोडर कौन है? मैंने वहां जीथब को देखा और उनके पास रेस्टशर्प का कांटा नहीं है। पैकेज पर कोई लाइसेंस सूचीबद्ध नहीं है, क्योंकि मुझे पता है कि यह दुर्भावनापूर्ण है।

जो भी इस परियोजना का मालिक है उसे रेस्टशार्प पैकेज नेमस्पेस का स्वामित्व लेना चाहिए ... और शायद उस पैकेज को हटा दिया जाए। मैं शायद देखूंगा कि क्या उस पैकेज में कोई दुर्भावनापूर्ण सामग्री है जो इसे डीकंपाइल करके रखती है

5 अक्टूबर, 2017 को रात 10:57 बजे,

@niemyjski (https://github.com/niemyjski) जब आप इस लाइब्रेरी के अपडेट होने की प्रतीक्षा कर रहे हों, तो शायद RestSharp.NetCore (https://www.nuget.org/packages/RestSharp.NetCore/) को आजमाएं। इसका उपयोग निम्नलिखित पुस्तकालयों द्वारा किया जा रहा है, इसलिए यह उपयोग के लिए पर्याप्त स्थिर होना चाहिए।

एडीएच.पुशकोर
AppVeyorतीव्र
कोरलिब.वेब
काउचडीबी.क्लाइंट
DocumentSign.NetCore
Flip.PomboCorreio.Connector
FluentEmail.Mailgun
GiphyApiClient.NetCore
इंटरकॉम.कोर
आयरनस्फीयर।गुर्गे
मास्टरकार्ड-कोर-अनौपचारिक
एमबैंक-डॉटनेट
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
Onlinesites.ShopFacilBradesco
ढकेलनेवाला-http-डॉटनेट-कोर
रिपोजिटरीफ्रेमवर्क.एपीआई
RepositoryFramework.EntityFramework
रेस्टशार्प.न्यूटॉन्सॉफ्ट.जेसन
RestSharp.Newtonsoft.Json.NetCore
सुस्त।वेबहुक।कोर
स्टोनको.पोम्बोकोरेरियो.कनेक्टर
स्विचएपीआई। कनेक्टर
Syncromatics.Clients.Metro.Api
TransportApi.Sdk.NetCore
Twilio.NetCore
UtilityFramework.Application.Core
UtilityFramework.Services.Iugu.Core

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub (https://github.com/restsharp/RestSharp/issues/992#issuecomment-334651808) पर देखें, या थ्रेड को म्यूट करें (https://github.com/notifications/unsubscribe-auth /AA-So9HrYQHV5nlV1m7W7eY-y_F5cBqqks5spaUXgaJpZM4PLH2m)।

@alexeyzimarev क्या आज वहाँ एक प्रीरिलीज़ नगेट पैकेज प्राप्त करने का कोई मौका है? भले ही यह बीटा है और सभी परीक्षण काम कर रहे हैं लेकिन कुछ अन्य चीजें बदल सकती हैं।

उदास RESTsharp कोर 2.0 के साथ काम नहीं करता है। मान लीजिए कि यह HttpClient पर वापस आ गया है

@niemyjski नहीं, क्षमा करें। मैं WebRequest को HttpClient में बदल रहा हूं और यह एक बड़ा बदलाव है। इसका कारण यह है कि WebRequest केवल netstandard 2.0 के लिए उपलब्ध है और हम 1.6 का समर्थन करना चाहते हैं।

@niemyjski यदि आप मदद करना चाहते हैं तो मैं अपने परिवर्तनों को एक अलग शाखा में प्रकाशित कर सकता हूँ-

मैं वास्तव में अब नेटस्टैंडर्ड 2.0 पर स्विच कर चुका हूं। नेटस्टैंडर्ड 1.6 बहुत अधिक काम प्रतीत होता है। लेकिन मैं अभी भी एचटीपी क्लाइंट का उपयोग करना चाहता हूं।

इसे देखें: https://github.com/restsharp/RestSharp/tree/netstandard
पीआर का स्वागत है।

@amivit आप इसे पूरा करने के लिए अपना कुछ समय दे सकते हैं, है ना?

मैं WebRequest को HttpClient में बदल रहा हूं और यह एक बड़ा बदलाव है। इसका कारण यह है कि WebRequest केवल netstandard 2.0 के लिए उपलब्ध है और हम 1.6 का समर्थन करना चाहते हैं।

यह एक गलत कथन है क्योंकि इसमें System.Net.Requests nuget पैकेज है।

क्या शुरुआत में WebRequest के साथ रहना और फिर समय के साथ HttpClient में संक्रमण करना मुश्किल होगा?

@mguinness क्या आपने इस पैकेज का उपयोग करने की कोशिश की है? मैंने किया।

@mguinness हम कह सकते हैं - 1.6 भूल जाओ, हम 2.0 के लिए जाते हैं और हम WebRequest रखते हैं। मैं इसके साथ व्यक्तिगत रूप से ठीक हूं।

क्षमा करें @alexeyzimarev मेरे पास योगदान करने का समय नहीं है। मैं चाहता हूं। मुझे आश्चर्य है कि RESTsharp शुरू करने के लिए HttpClient पर निर्भर नहीं है। क्या यह 2012 या .NET 4.5 के बाद से WebClient पर उपलब्ध सुधार नहीं है?

@amivit शायद अगर यह टूटा नहीं है, तो इसे ठीक न करें।

यहाँ सिर्फ मिमी के लिए क्षमा करें: rofl:
लेकिन मेरे क्लाइंट-एप्लिकेशन को .net कोर 2.0 में अपग्रेड करने के बाद मुझे RestSharp के बारे में कुछ चेतावनियां मिलती हैं:

चेतावनी NU1603: RestSharp.NetCore 105.2.3 System.Runtime.Serialization.Formatters (>= 4.0.0-rc4-24217-03) पर निर्भर करता है लेकिन System.Runtime.Serialization.Formatters 4.0.0-rc4-24217-03 नहीं था मिला। System.Runtime.Serialization.Formatters 4.3.0-preview1-24530-04 का लगभग सबसे अच्छा मिलान हल किया गया था।

मैंने अभी के लिए एप्लिकेशन को निष्पादित करने का प्रयास नहीं किया - मुझे लगता है कि यह काम नहीं करेगा।
तो, RestSharp अभी तक .net कोर 2.0 का समर्थन नहीं करता है। लेकिन, क्या यह किसी दिन होगा? क्या पहले से ही कोई तारीख है? क्या मैं ऐसा करने में (योगदानकर्ता के रूप में) यहाँ मदद कर सकता हूँ?

@matthiasburger नेटस्टैंडर्ड शाखा की जाँच करें। मैंने आपकी टिप्पणी के ऊपर सिर्फ कुछ पदों का उल्लेख किया है।

अभी के लिए 2.0 के साथ जाओ। http क्लाइंट बनने के लिए इसे बाद में कभी भी बदल सकते हैं... इसके अलावा
सुनिश्चित करें कि आपके पास सिंक विधियों को बनाने के लिए संकलक निर्देश हैं
(ढांचा)

धन्यवाद
-ब्लेक नीमीज्स्की

बुधवार, 11 अक्टूबर, 2017 को सुबह 6:43 बजे, एलेक्सी ज़िमारेव नोटिफिकेशन @github.com
लिखा था:

@matthiasburger https://github.com/matthiasburger नेटस्टैंडर्ड की जांच करें
डाली।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/restsharp/RestSharp/issues/992#issuecomment-335782906 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AA-So8akA6MlKfoypWDSAqaElcYBPoAks5srKnUgaJpZM4PLH2m
.

श्री @alexeyzimarev कभी-कभी मुझे सब कुछ पढ़ना चाहिए - बढ़िया। मैं इसे देख लेता हूँ :)

@niemyjski सभी

ठीक है, तो netstandard शाखा अब हस्ताक्षरित और अहस्ताक्षरित दोनों के लिए निर्मित होती है। फिर भी मेरे पास चार परीक्षण हैं जो विफल होते हैं (एन्कोडिंग, डिकोडिंग)। एकीकरण परीक्षण अभी तक शामिल नहीं हैं। उम्मीद है कि मैं इस सप्ताह कोड समाप्त कर सकता हूं लेकिन DotNetCli पर स्विच करने के लिए बिल्ड और पैक को कुछ और काम करने की आवश्यकता होगी।

ठीक है, सब काम करने लगता है। HttpListener (एकीकरण) से असमर्थित अपवादों के कारण मुझे सशर्त रूप से दो परीक्षणों को अनदेखा करना पड़ा। उचित सर्वर के साथ उपयोग किए जाने पर यह काम करने की अपेक्षा करें।

अब DotNetCli का उपयोग करने और nuget.exe का उपयोग बंद करने के लिए बिल्ड स्क्रिप्ट को बदलने की आवश्यकता है

बढ़िया काम करते रहो @alexeyzimarev! पहली रिलीज के लिए इंतजार नहीं कर सकता

कृपया https://www.nuget.org/packages/RestSharp/106.0.0-alpha0277 . का परीक्षण

VS2017 में 106.0.0-alpha0277 का परीक्षण किया गया और वास्तविक IIS लक्ष्यीकरण .NET Core 2.0

ErrorException: System.PlatformNotSupportedException: ऑपरेशन इस प्लेटफॉर्म पर समर्थित नहीं है।
System.Net.SystemWebProxy.GetProxy (उरी गंतव्य) पर
System.Net.ServicePointManager.ProxyAddressIfNecessary (उरी और पता, IWebProxy प्रॉक्सी) पर
System.Net.ServicePointManager.FindServicePoint (उरी पता, IWebProxy प्रॉक्सी) पर
System.Net.HttpWebRequest.get_ServicePoint () पर
RestSharp.Http.ConfigureWebRequest पर (स्ट्रिंग विधि, उरी यूआरएल)
RestSharp.Http.PostPutInternal (स्ट्रिंग विधि) पर
RestSharp.Http.AsPost पर (स्ट्रिंग httpMethod)
RestSharp.RestClient.DoExecuteAsPost (IHttp http, स्ट्रिंग विधि) पर
RestSharp.RestClient.Execute पर (IRestRequest अनुरोध, स्ट्रिंग httpMethod, Func`3 getResponse)

मुझे पता है कि उन्होंने समय के साथ बहुत सारे IsXYZ तरीके जोड़े हैं, शायद हमें इन तरीकों को कॉल करने या उन्हें लपेटने से पहले उनकी जाँच करने की आवश्यकता है?

इन परीक्षणों को लिनक्स के तहत चलाना शुरू करना अच्छा होगा क्योंकि मुझे लगता है कि इसमें विंडोज़ की तुलना में बहुत अधिक समस्याएं मिलेंगी।

@ maciek12305 यहां एक अपवाद को कॉपी-पेस्ट करना पर्याप्त नहीं है क्योंकि मुझे नहीं पता कि आप वहां कैसे पहुंचे।

@niemyjski मैं लिनक्स पर परीक्षण चलाने के बारे में सहमत हूं लेकिन इसके लिए एक नया सीआई बिल्ड स्थापित करने की आवश्यकता है। मैं ट्रैविस को बाद में देखूंगा, उम्मीद है कि अगले सप्ताह।

प्रॉक्सी के साथ एक समस्या की तरह लगता है https://github.com/Azure/azure-iot-sdk-csharp/issues/140

ठीक है, समस्या यह है कि .NET कोर डिफ़ॉल्ट प्रॉक्सी का समर्थन नहीं करता है क्योंकि डिफ़ॉल्ट प्रॉक्सी के लिए सेटिंग्स रजिस्ट्री से लोड की जाती हैं।

इसलिए, यदि आप प्रॉक्सी का उपयोग नहीं करते हैं तो यह काम करना चाहिए और यदि प्रॉक्सी का उपयोग किया जाता है तो यह .NET कोर पर क्रैश हो जाएगा। अभी के लिए मैंने "डिफ़ॉल्ट प्रॉक्सी" वर्ग जोड़ा है, जो सब कुछ बाईपास करने और सीधे जाने के लिए कहता है। यदि आपको प्रॉक्सी का उपयोग करना है - तो आपको इसे ConfigureProxy पद्धति का उपयोग करके प्रदान करना होगा।

कृपया नवीनतम पैकेज का प्रयास करें: https://www.nuget.org/packages/RestSharp/106.0.0-alpha0281

@niemyjski वास्तव में मैक पर एकीकरण परीक्षण ठीक है। तो यह लिनक्स पर भी काम करना चाहिए, मुझे लगता है।

@alexeyzimarev नवीनतम पैकेज ने मेरे लिए विन 10 पर काम नहीं किया। मेरे लिए इसे काम करने का एकमात्र तरीका मेरे कोड में निम्नलिखित शामिल करना था:

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

@mguinness तो आप पुराने मूल्य को क्यों रखते हैं (सुनिश्चित नहीं है कि यह क्या है) proxy चर में? मुझे लगता है कि एकमात्र पंक्ति, जो कोई फर्क कर सकती है, वह है

WebRequest.DefaultWebProxy = null;

मैं इसे आसानी से जोड़ सकता हूं अगर इससे मदद मिलेगी।

@alexeyzimarev ढांचे में एक बग था जो "WebRequest.DefaultWebProxy: सेट पिछले प्राप्त किए बिना काम नहीं करता" फिक्स करता है।

मैं अब समझता हूँ। मैं डिफ़ॉल्ट एक में हेरफेर करने के बजाय अनुरोध प्रॉक्सी संपत्ति को शून्य पर सेट करने के साथ एक पैकेज बनाने का प्रयास कर सकता हूं।

@mguinness नया पैकेज आ गया है, मदद करने के लिए धन्यवाद!

@mavanmanen क्या आप इसे यूडब्ल्यूपी के साथ भी https://www.nuget.org/packages/RestSharp/106.0.0-alpha0282

संस्करण 106.0.0-alpha0282 के साथ एक ही त्रुटि "इस प्लेटफॉर्म पर ऑपरेशन समर्थित नहीं है।"

@remiskaune क्या आपने इन पंक्तियों को अपने कोड में शामिल करने का प्रयास किया है?

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

धन्यवाद। यह अब इस लाइन के साथ संस्करण 106.0.0-alpha0282 पर काम करता है।

तो सवाल यह है कि यह बिना काम क्यों नहीं करता है, क्योंकि मैंने इन पंक्तियों को रेस्टशर्प कोड में शामिल किया है ...

शायद WebRequest का एक अलग दायरा है? क्या यह एक स्थिर वर्ग या उदाहरण है?

आप एक नमूना ऐप बनाकर पता लगा सकते हैं, और अपने नमूना ऐप में, जांचें:

WebRequest.DefaultWebProxy

और रेस्टशर्प के लिए वह मूल्य भेजने के लिए कुछ विधि को उजागर करना जो वह देख रहा है (डिबगिंग उद्देश्यों के लिए) - उदाहरण के लिए:

public IWebProxy GetCurrentProxy() => WebRequest.DefaultWebProxy;

देखें कि क्या दोनों अलग हैं?

@qJake अगर कोई मेरे लिए डिबग कर सकता है तो मैं सराहना करूंगा :) मैं अगले सप्ताह तक इस पर कोई समय नहीं बिता पाऊंगा, एक सम्मेलन में बोलूंगा।

नया पैकेज उपलब्ध है जहां WebRequest.DefaultProxy को शून्य पर असाइन करके प्रॉक्सी समस्या "फिक्स्ड" है। इसका परिणाम हो सकता है लेकिन मुझे वास्तविक मुद्दों की उम्मीद नहीं है। समाधान केवल .NET मानक असेंबली में जोड़ा जाता है। .NET Framework असेंबली को पहले की तरह काम करना चाहिए।
https://www.nuget.org/packages/RestSharp/106.0.0-alpha0284

यदि कोई समस्या रिपोर्ट नहीं की जाएगी, तो मैं रिलीज की तैयारी शुरू कर दूंगा।

यहां काफी सकारात्मक प्रतिक्रिया। मैं एक आश्रित पैकेज (एटलसियन.जेआईआरए) को काम करने की कोशिश कर रहा था और मान रहा था कि मैंने .NET मानक 2.0 को लक्षित किया है, फिर उनके सभी एकीकरण/इकाई परीक्षण "बस काम किया" तो एलजीटीएम।

उस छोर पर धागे के लिए https://bitbucket.org/farmas/atlassian.net-sdk/issues/306/support-for-dotnet-core ।

मैंने इसे हमारे समाधान के खिलाफ परीक्षण किया है, और यह अच्छी तरह से काम करता है।

हम इसे .net मानक 2.0 प्रोजेक्ट्स और .net 4.6.1 प्रोजेक्ट्स से उपयोग कर रहे हैं

जब .net 4.6.1 से उपयोग किया जाता है। परियोजनाओं में यह निम्नलिखित संदर्भों में खींचता है, जो दृश्य स्टूडियो पीले विस्मयादिबोधक चिह्नों के साथ चिह्नित करता है।
System.Net.Http
System.Runtime.Serialization.Primitives
System.Security.Cryptography.Algorithms
सिस्टम.सुरक्षा.क्रिप्टोग्राफी.एन्कोडिंग
System.Security.Cryptography.Primitives
System.Security.Cryptography.X509Certificates

मुझे यकीन नहीं है कि ऐसा क्यों है, हालांकि ऐसा लगता है कि कोई समस्या नहीं है।

हमारे पास एक छोटी सी समस्या यह है कि हम अपने उपकरणों में से एक को वितरित करने के लिए एक बार क्लिक का उपयोग करते हैं, इसलिए हमें हर चीज को मजबूत नाम देने के लिए मजबूर होना पड़ता है। हालांकि प्रीरिलीज संस्करण का नाम मजबूत नहीं है। हम पैकेज के RestSharpSigned संस्करण का उपयोग कर रहे हैं लेकिन .net मानक समर्थन के साथ इसका कोई पूर्व-रिलीज़ संस्करण नहीं है।

एक मजबूत नामित और गैर-मजबूत नामित संस्करण होने से उस स्थिति में समस्याग्रस्त हो सकता है जहां आपके पास दो निर्भरताएं हैं जो मजबूत नामित संस्करण पर निर्भर करती हैं और एक जो गैर-मजबूत नामित संस्करण पर निर्भर करती है।

इसके बजाय मेरा सुझाव है कि एक पैकेज जो हस्ताक्षरित है और आपके असेंबली संस्करण के प्रमुख संस्करण के लिए फ्रीजिंग है (SemVer में प्रमुख संस्करण केवल तभी बदलता है जब आप संगतता तोड़ते हैं) फिर अपने FileVersion पर पूर्ण SemVer का उपयोग करें। इस तरह आपके पास एक नगेट पैकेज है जिसे हर कोई उपयोग कर सकता है (मजबूत नाम या नहीं) और प्रमुख संस्करण फ्रीज का मतलब है कि बाध्यकारी रीडायरेक्ट की आवश्यकता नहीं है। और SemVer का उपयोग करने का मतलब है कि हर कोई जानता है कि अनुकूलता के मामले में वे कहां खड़े हैं।

मैं इसे यहां सुझाता हूं क्योंकि यह परिवर्तन करने के लिए .net मानक पर स्विच करना एक अच्छा समय हो सकता है।

हमें बस डिफ़ॉल्ट रूप से पैकेज पर हस्ताक्षर करना चाहिए और कुंजी को GitHub में रखना चाहिए, .net टीम इसकी अनुशंसा करती है क्योंकि इससे कुछ भी नुकसान नहीं होता है।

क्या कोई जनसंपर्क है जिससे मैं परिवर्तन देख सकता हूँ?

@niemyjski मुझे लगता है कि develop शाखा सभी के लिए दृश्यमान है। मैंने इसे एक डिफ़ॉल्ट शाखा भी बना दिया।

@niemyjski "जस्ट" इस मामले में काम नहीं करता है। अगर आप मदद करना चाहते हैं - कृपया करें। मुझे Signed प्रोजेक्ट्स को हटाना पड़ा क्योंकि वे नगेट में बग के कारण पूरे सॉल्यूशन बिल्ड को विफल कर देते हैं।
https://github.com/dotnet/standard/issues/538
https://github.com/NuGet/Home/issues/6038

तो या तो मुझे इसके ठीक होने तक इंतजार करना होगा, या मुझे एक अलग समाधान और प्रोजेक्ट जोड़ना होगा, और फिर सभी फाइलों को मैन्युअल रूप से शामिल करना होगा, जो कि बुरा है।

@alexeyzimarev के पास केवल एक csproj है और उस पर हस्ताक्षर करें, बाध्यकारी रीडायरेक्ट मुद्दों से बचने के लिए असेंबली संस्करण संख्या (प्रमुख संस्करण में) को फ्रीज करें। nuget और फ़ाइल संस्करण के लिए मानक SemVer का उपयोग करें। इससे आपकी सभी समस्याओं का समाधान हो जाएगा।

यदि आप दो संस्करणों को रखने पर जोर देते हैं (जो आपके उपयोगकर्ताओं के लिए समस्याएँ पैदा करेंगे) तो आप अभी भी कॉन्फ़िगरेशन के माध्यम से एकल csproj के साथ ऐसा कर सकते हैं।

मैंने इसे मूल रूप से अपने स्वयं के प्रोजेक्ट में किया (और यह काम किया) इससे पहले कि मुझे एहसास हुआ कि दो संस्करणों के लिए यह कितना टूटा हुआ था। मूल रूप से मैंने एक स्ट्रांगनाम संपत्ति समूह जोड़ा। फिर डॉटनेट बिल्ड-सी स्ट्रांगनाम के साथ निर्माण करें

<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>

यदि आप अपने द्वारा उठाए गए मुद्दों के समाधान की प्रतीक्षा करते हैं तो आप लंबे समय तक प्रतीक्षा कर सकते हैं।

इससे आपकी सभी समस्याओं का समाधान हो जाएगा।

मुझे यह पसंद है।

संपत्ति समूह सुझाव मूल्यवान है। मैं दो पैकेज रखने की कोशिश करूंगा, नहीं तो यह भ्रम पैदा करेगा। मैं गलत हो सकता हूं लेकिन व्यक्तिगत रूप से मैं सिर्फ हस्ताक्षर करने से बचूंगा। लेकिन चूंकि आपको इसकी आवश्यकता है - मैं एक हस्ताक्षरित असेंबली के साथ एक पैकेज बनाने की कोशिश करूंगा।

@niemyjski क्या आपके पास ".net टीम इसकी अनुशंसा करती है" का लिंक है? मुझे परिणामों के बारे में और जानने की जरूरत है और वे वास्तव में ऐसा करने का सुझाव कैसे देते हैं।

मैंने उनके साथ बात की है और मुझे पता है कि उन्होंने इसे सार्वजनिक रूप से भी कहा है
मंचों और सुस्त। यह एक तरह का मजाक है और इसे हटा दिया जाना चाहिए (
https://twitter.com/terrajobst/status/774752534682402817).. बेहतर है
बस मजबूत नाम विधानसभा... हम अपनी सभी विधानसभाओं को मजबूत नाम देते हैं और
रेपो में हस्ताक्षर करने वाले स्नैक को छोड़ दें क्योंकि यह एक मजाक है। हेक्स संपादक वाला कोई भी
मजबूत नाम हस्ताक्षर को बायपास कर सकते हैं और यह केवल उन लोगों को आहत करता है जिनकी आवश्यकता होती है
निर्भरताओं को लेने से उनके पैकेज पर हस्ताक्षर करें। आप एक मजबूत का संदर्भ दे सकते हैं
एक अहस्ताक्षरित पैकेज से हस्ताक्षरित पैकेज तो क्यों न सिर्फ इस पर हस्ताक्षर करें
समय।

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

धन्यवाद
-ब्लेक नीमीज्स्की

बुधवार, 1 नवंबर, 2017 को दोपहर 1:30 बजे, एलेक्सी ज़िमारेव नोटिफिकेशन @github.com
लिखा था:

@niemyjski https://github.com/niemyjski क्या आपके पास "The .net ." का लिंक है
टीम इसकी अनुशंसा करती है"? मुझे परिणामों के बारे में और जानने की आवश्यकता है और कैसे
वास्तव में वे ऐसा करने का सुझाव देते हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/restsharp/RestSharp/issues/992#issuecomment-341197289 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AA-So94xh-jiEMniw0D2QaGQPgT9zfBfks5syLjDgaJpZM4PLH2m
.

ठीक है, मैं अभी इस पर हस्ताक्षर करूंगा।

इसे जारी किया जाता है। https://www.nuget.org/packages/RestSharp/106.0.0

आप यहां जीथब पर एक रिलीज टैग बना सकते हैं। :)

टैग

106.1.0 के लिए जारी नोट में उल्लेख है:
".NET कोर पर प्रॉक्सी समस्या को ठीक किया गया"

निश्चित नहीं है कि फिक्स में क्या शामिल है, लेकिन हम अभी भी प्रॉक्सी का उपयोग करने में समस्याओं का सामना कर रहे हैं।
हमारे .NET Core 2.0 पोर्ट (.NET Framework 4.6.1 से आने वाले) से पहले, हमने क्लाइंट को इस तरह से इंस्टेंट किया और यह एक आकर्षण की तरह काम किया।

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

.NET Core 2.0 प्रोजेक्ट में समान कोड का उपयोग करने से हमें निम्नलिखित प्रतिक्रिया त्रुटि मिलती है:

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

अनुरोध फायरिंग कोड इस तरह दिखता है:

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

कोई विचार?

धन्यवाद,
फ्रेड

क्या आपके पास .NET Core 2.0 के लिए वर्किंग कोड है?

क्योंकि यदि आप स्टैकट्रेस को चेक करते हैं, तो आप देखेंगे कि यह हमारा अपवाद नहीं है बल्कि .NET अपवाद है जब उसने डिफ़ॉल्ट प्रॉक्सी प्राप्त करने का प्रयास किया।

हां, आप सही कह रहे हैं

उसी समस्या का सामना करने वाले अन्य लोगों के लिए, आप स्पष्ट रूप से निर्दिष्ट कर सकते हैं कि इस तरह किस प्रॉक्सी का उपयोग करना है:

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

मैंने .NET Core 2.0 पर 106.1.0 से 106.2.0 में अपग्रेड किया है और यह संदेश पॉप अप होना शुरू हो गया है:

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

जैसा कि दूसरों ने उल्लेख किया है, यह संदेश System.Net.SystemWebproxy.GetProxy द्वारा उत्पन्न किया गया प्रतीत होता है, लेकिन मेरे उदाहरण में मैं स्पष्ट रूप से प्रॉक्सी को बिल्कुल भी कॉन्फ़िगर नहीं कर रहा हूं, आंतरिक रूप से यह अपने स्वयं के संचालन कर रहा है और मेरे द्वारा किए गए प्रत्येक अनुरोध पर अपवाद फेंक रहा है।

मैं 106.1.0 पर वापस आ गया हूं और इसने इसे ठीक कर दिया है, तो क्या 106.2.0 में कुछ बदलाव आया है जहां प्रॉक्सी सेटिंग्स को किसी तरह से स्पष्ट करने की आवश्यकता है?

@voicebooth इसकी सूचना #1061 . में दी गई है