938

قد يعني دعم .NET Standard 2.0 دعم جميع الأنظمة الأساسية التالية :

• NET Framework 4.6.1
• NET Core 2.0
• مونو 5.4
• Xamarin.iOS 10.14.0 تحديث
• Xamarin.Mac 3.8.0 تحديث
• Xamarin.Android 7.5
• UWP vNext (يتم الشحن لاحقًا هذا العام)

عند تشغيل RestSharp باستخدام رقاقة التوافق مع الإصدارات السابقة ، فإنه يعمل في الغالب ، وهناك فقط مشكلات في الفئة الأساسية المستخدمة لاستدعاء مكالمات HTTP - إذا تم تبديل عميل HTTP باستخدام HttpClient الجديد ، فيجب أن يعمل.

من الناحية الشخصية ، نستخدم RestSharp كثيرًا هنا في مكتبنا ، ونحن نعمل بالفعل على حلول جديدة قائمة على السحابة تعمل باستخدام ASP.NET Core ، لذلك نود حقًا أن نرى RestSharp قد تم إحضاره إلى أحدث إصدار من .NET. الإصدار حتى لا نضطر إلى التبديل إلى مكتبة REST جديدة.

qJake نظرًا لأن .NET Standard 2.0 لديه سطح API موسع بشكل كبير ، فمن المؤكد أنه يمكن الاحتفاظ بـ HttpWebRequest بدلاً من التبديل إلى HttpClient. ربما لم تعد المشكلات التي واجهتها مع الرقاقة موجودة؟

لماذا NET Standard 2.0؟ يرجى النظر في استهداف أقل إصدار متاح.

mguinness راجع هذا التعليق في مشروع @ dotnet / corefx - HttpWebRequest ليس جزءًا من .NET Standard ، ولكن System.Net.Http.HttpClient هو جزء من.

يرجى النظر في دعم الإصدار الحالي UWP أيضًا. (قبل تحديث Fall Creators)

الإصدار الحالي UWP يعني netstandard1.4. لست متأكدًا من العواقب التي سيحدثها هذا ، فأنا بحاجة إلى البدء في التجربة.

qJake Well HttpWebRequest موجود في .NET Standard 2.0 ، تأكيدك صحيح فقط لـ .NET Standard 1.6 وما

mguinness أوه ، أرى - حسنًا ، هذا يمثل تحديًا ، إذن - نظرًا لأن RestSharp يستخدم HttpWebRequest / Response ، فهل ندعم فقط .NET Standard 2.0 ونلتزم بهذه الفئات ، أو هل نقوم بإعادة بناء العميل الأساسي والتبديل إلى HttpClient ، هل تسمح لنا بدعم الإصدارات القديمة من .NET Standard؟

يريد الناس 1.4 بسبب مشاكل في الإصدار الحالي من UWP. لن يتم دعم NETStandard 2.0 إلا في UWP vNext.

qJake FWIW ، هناك أيضًا حزمة System.Net.Requests nuget التي يمكن استخدامها في الإصدارات السابقة من .NET Standard.

مرحبًا يا رفاق ، أي تحديث أو ETA على هذا؟ التخطيط لاستخدام RestSharp على تطبيق dotnet core 2 ولا أرغب في تبديل الحزم.

إنه العمل في التقدم. تمت إزالة العناصر القديمة ولكن من المحتمل أن نكون قد شاركنا في إحضار JSON.NET إلى الإصدار أيضًا. ابقوا متابعين.

ويب: https://github.com/alexeyzimarev/restsharp/tree/netstandard

أحتاج إلى استخدامه مع AWS Lambda ، ولكن عند استخدام RestSharp.NetCore 105.2.3 ، ترجع أخطاء AWS
- تم اكتشاف الرجوع إلى إصدار أقدم من الحزمة: System.Reflection من 4.3.0-preview1-24530-04 إلى 4.1.0.

يعني أن RestSharp يستخدم 4.1 ولكن AWS يدعم الإصدار 4.3 المعين ، لـ .NetCoreApp 1.0.

هل لدينا نسخة تعتمد على System.Runtime.Serialization.Primitives.4.3.0-preview1-24530-04؟

نحن ننتقل إلى .net core ووجدنا للتو أنه لا يمكننا الرجوع إلى RestSharp من .net القياسي 2.0 ، حيث فشل تثبيت حزمة nuget.

تمت استعادة الحزمة "RestSharpSigned 105.2.3" باستخدام ".NETFramework، Version = v4.6.1" بدلاً من إطار عمل المشروع المستهدف ".NETStandard، Version = v2.0". قد لا تكون هذه الحزمة متوافقة تمامًا مع مشروعك.
فشلت استعادة الحزمة. التراجع عن تغييرات الحزمة لـ

trampster أعتقد أنك تسيء فهم الحالة. حزمة RestSharp الرسمية لا تدعم .NET Standard وتم تحديثها آخر مرة في عام 2015. التحويل الذي يعمل عليه alexeyzimarev لم يتم نشره بعد AFAIK.

أفهم ، كنت أنشر للمساعدة في الإشارة إلى أن هناك طلبًا عليه. أيضًا لإظهار أن وضع التوافق مع .NET Framework للإشارة إلى ملفات dll كاملة .net من .net القياسي 2.0 كما أعلنته Microsoft عند إصدار معيار net 2.0 لا يعمل هنا. لذلك لا يوجد حل ، نحن محجوبون.

نفضل ألا نضطر إلى الانتقال إلى مكتبة أخرى للراحة ، لكننا سنفعل إذا احتجنا لذلك. سوف يعتمد على المدة التي سيستغرقها هذا التحويل.

من المثير للاهتمام أن هناك حزمة RestSharp.NetCore على nuget https://www.nuget.org/packages/RestSharp.NetCore مع 98،895 تنزيلًا ، ولكن بقدر ما أستطيع أن أقول أن القائم بالتحميل غير مرتبط بالمشروع لذلك لا أعرف إذا كان بإمكاني الوثوق به.

trampster هذا تحذير nuget (يمكن منعه) ، راجع إعادة استخدام مكتبة .NET Framework موجودة . أيضًا ما هو إطار العمل المستهدف في csproj ، هل هو netcoreapp2.0 أم v4.6.1؟

ألق نظرة ثانية على السطر الأخير. دحرجته إلى الوراء. بعد ذلك ليس لدي أي إشارة إلى RestSharp.

أيضًا إذا قرأت منشوري ، فسترى أنني أحاول استخدامه من .net القياسي 2.0 وليس netcore2.0 أو v4.6.1.

وتجدر الإشارة أيضًا إلى أن التحذير يشير إلى أنه تم استخدام v4.6.1 ولكن حزمة RestSharp nuget لا تحتوي على الإصدار 4.6.1

trampster لقد قمت بتثبيته بنجاح في تطبيق .NET Core 2.0 باستخدام جسر التوافق ، ولكن عندما أذهب لتشغيله ، أحصل على استثناء وقت تشغيل يتلخص في استخدام HttpWebRequest . لم أحصل على أي إخفاقات في تثبيت حزمة NuGet ، لذلك هذا غريب. 😃

أنا أواجه هذا أيضًا: \ alexeyzimarev كيف يمكن للمجتمع أن يساعد. نحن بحاجة إلى هذا وكلنا محجوبون على هذا. أقوم بتشغيل حزمة OAuth2 التي تستخدم هذه المكتبة ويمنع الجميع من استخدامها أيضًا.

لا يمكن استخدام حزمة nuget الحالية في تطبيق .NET Core إلا إذا كنت تستهدف إطار العمل الكامل.

لقد قمت بإنشاء تطبيق .NET Core console جديد ، وقمت بتشغيل Install-Package RestSharp -Version 105.2.3 من Package Manager وأضفت الكود التالي إلى Main:

ج #
var client = new RestClient () ؛
client.BaseUrl = new Uri ("https://api.github.com/") ؛

طلب var = RestRequest جديد () ،
request.Resource = "users / restsharp / repos" ؛

var response = client.Execute (طلب) ؛
""

سيؤدي استهداف netcoreapp2.0 إلى منح System.PlatformNotSupportedException: Operation is not supported on this platform. ولكنه سيعمل إذا قمت بالتغيير إلى <TargetFramework>net46</TargetFramework> في csproj.

نحن لا نستهدف الإطار الكامل

niemyjski ربما جرب RestSharp.NetCore أثناء انتظار تحديث هذه المكتبة. يتم استخدامه من قبل المكتبات التالية ، لذا يجب أن يكون مستقرًا بدرجة كافية للاستخدام.

ADH
AppVeyorSharp
CoreLib.Web
CouchDB. العميل
DocuSign.NetCore
Flip.PomboCorreio. الموصل
بطلاقة
GiphyApiClient.NetCore
انتركم
آيرون سفير
ماستر كارد كور غير رسمي
mbank دوت نت
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
أونلاين سايت
دافع- http-dotnet-core
مستودع الإطار
RepositoryFramework.EntityFramework
RestSharp.Newtonsoft.Json
RestSharp.Newtonsoft.Json.NetCore
Slack.Webhooks الأساسية
StoneCo.PomboCorreio. موصل
SwitchAPI
Syncromatics.Clients.Metro.Api
TransportApi.Sdk.NetCore
Twilio.NetCore
UtilityFramework.Application.Core
UtilityFramework.Services.Iugu.Core

لا أحد يعرف من هو رافع RestSharp.NetCore؟ نظرت إلى جيثب هناك ولم يكن لديهم شوكة من RestSharp. لا يوجد ترخيص مدرج على الحزمة ، لكل ما أعرفه أنها ضارة.

يجب على من يملك هذا المشروع أن يسعى للحصول على ملكية مساحة اسم حزمة restsharp ... وربما يتم حذف هذه الحزمة. من المحتمل أن أرى ما إذا كانت هذه الحزمة تحتوي على أي محتوى ضار عن طريق فك تجميعه

في 5 تشرين الأول (أكتوبر) 2017 الساعة 10:57 مساءً ،

niemyjski (https://github.com/niemyjski) ربما جرب RestSharp.NetCore (https://www.nuget.org/packages/RestSharp.NetCore/) بينما تنتظر تحديث هذه المكتبة. يتم استخدامه من قبل المكتبات التالية ، لذا يجب أن يكون مستقرًا بدرجة كافية للاستخدام.

ADH
AppVeyorSharp
CoreLib.Web
CouchDB. العميل
DocuSign.NetCore
Flip.PomboCorreio. الموصل
بطلاقة
GiphyApiClient.NetCore
انتركم
آيرون سفير
ماستر كارد كور غير رسمي
mbank دوت نت
MessageMedia.REST.API.NetCore
Minio.NetCore
MiX.Integrate.Api.Client
OdinSdk.BaseLib.Core
OneSignal.AspNet.Core.SDK
OneSignal.CSharp.SDK.Core
أونلاين سايت
دافع- http-dotnet-core
مستودع الإطار
RepositoryFramework.EntityFramework
RestSharp.Newtonsoft.Json
RestSharp.Newtonsoft.Json.NetCore
Slack.Webhooks الأساسية
StoneCo.PomboCorreio. موصل
SwitchAPI
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 هل هناك أي فرصة للحصول على حزمة nuget التجريبية الموجودة هناك اليوم؟ حتى لو كانت نسخة تجريبية وجميع الاختبارات تعمل ولكن قد تتغير بعض الأشياء الأخرى.

لا يعمل Sad RESTsharp مع Core 2.0. أعتقد أنه عاد إلى HttpClient

niemyjski لا ، آسف. أقوم بتغيير WebRequest إلى HttpClient وهذا تغيير كبير. والسبب في ذلك هو أن WebRequest متاح فقط لـ netstandard 2.0 ونريد دعم 1.6.

niemyjski يمكنني نشر

لقد تحولت بالفعل إلى netstandard 2.0 الآن. يبدو أن netstandard 1.6 يتطلب الكثير من العمل. لكن ما زلت أريد استخدام HttpClient.

تحقق من ذلك: https://github.com/restsharp/RestSharp/tree/netstandard
ترحيب PRs.

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 كبداية. ألم يكن تحسينًا متاحًا على WebClient منذ 2012 أو .NET 4.5؟

amivit على الأرجح حالة إذا لم يتم كسرها ، فلا تقم بإصلاحها.

آسف لمجرد mimimi هنا: rofl:
ولكن بعد ترقية تطبيق العميل الخاص بي إلى .net core 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 core 2.0 حتى الآن. لكن ، هل سيحدث يومًا ما؟ هل يوجد بالفعل موعد؟ هل يمكنني المساعدة هنا لتحقيق ذلك (كمساهم)؟

@ matthiasburger تحقق من فرع netstandard. لقد ذكرت هذا بضع مشاركات فقط فوق تعليقك.

اذهب مع 2.0 الآن. يمكن دائمًا تغييره لاحقًا ليكون عميل http ... أيضًا
تأكد من حصولك على توجيهات المترجم لجعله يحتوي على طرق المزامنة
(إطار العمل)

شكرا
-بليك نيميجسكي

يوم الأربعاء 11 تشرين الأول (أكتوبر) 2017 الساعة 6:43 صباحًا ، أرسل Alexey Zimarev [email protected]
كتب:

matthiasburger https://github.com/matthiasburger تحقق من شبكة الإنترنت
فرع.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/restsharp/RestSharp/issues/992#issuecomment-335782906 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AA-So8akA6MlKfoypWDSAqaElcYBPFoAks5srKnUgaJpZM4PLH2m
.

sryalexeyzimarev أحيانًا يجب أن أقرأ كل شيء - رائع. ألقي نظرة عليه :)

niemyjski تتم إزالة كافة توجيهات pragma. لا أريد أن يكون لدي أي انحرافات لكل منصة ، أو إطار عمل ، وما إلى ذلك. هذا ما يعلن netstandard عن حله وسأستخدمه.

حسنًا ، لذلك تم إنشاء فرع netstandard لكلٍّ من الموقع وغير الموقعة. لا يزال لدي أربعة اختبارات تفشل (تشفير ، فك تشفير). لم يتم تضمين اختبارات التكامل حتى الآن. آمل أن أتمكن من إنهاء الكود هذا الأسبوع ، لكن البناء والحزمة سيتطلبان المزيد من العمل للتبديل إلى DotNetCli.

حسنًا ، يبدو أن كل شيء يعمل. اضطررت إلى تجاهل اختبارين مشروطًا بسبب الاستثناءات غير المدعومة من HttpListener (التكامل). توقع أن يعمل على الرغم من استخدامه مع خادم مناسب.

الآن يجب تغيير إنشاء البرنامج النصي لاستخدام DotNetCli والتوقف عن استخدام nuget.exe

استمروا في العمل الرائعalexeyzimarev! لا يمكن أن تنتظر الإصدار الأول

يرجى اختبار https://www.nuget.org/packages/RestSharp/106.0.0-alpha0277

تم اختباره 106.0.0-alpha0277 في VS2017 و IIS الحقيقي الذي يستهدف .NET Core 2.0

ErrorException: System.PlatformNotSupportedException: العملية غير مدعومة على هذا النظام الأساسي.
في System.Net.SystemWebProxy.GetProxy (وجهة Uri)
في System.Net.ServicePointManager.ProxyAddressIfNecessary (Uri & address ، IWebProxy proxy)
في System.Net.ServicePointManager.FindServicePoint (عنوان Uri ، وكيل IWebProxy)
في System.Net.HttpWebRequest.get_ServicePoint ()
في RestSharp.Http.ConfigureWebRequest (String method، Uri url)
في RestSharp.Http.PostPutInternal (أسلوب السلسلة)
في RestSharp.Http.AsPost (String httpMethod)
في RestSharp.RestClient.DoExecuteAsPost (IHttp http ، String method)
في RestSharp.RestClient.Execute (طلب IRestRequest ، String httpMethod ، Func`3 getResponse)

أعلم أنهم أضافوا الكثير من أساليب IsXYZ مع مرور الوقت ، فربما نحتاج إلى التحقق منها قبل استدعاء هذه الطرق أو تغليفها؟

سيكون من الجيد بدء تشغيل هذه الاختبارات في نظام Linux حيث أعتقد أنه سيجد الكثير من المشكلات أكثر من Windows.

@ maciek12305 لا يكفي نسخ ولصق استثناء هنا لأنني لا أعرف كيف وصلت إلى هناك.

nemyjski @ أوافق على إجراء الاختبارات على Linux ولكن هذا يتطلب إعداد بناء CI جديد. سألقي نظرة على ترافيس لاحقًا ، وأتمنى الأسبوع المقبل.

تبدو مشكلة في الوكيل https://github.com/Azure/azure-iot-sdk-csharp/issues/140

حسنًا ، المشكلة هي أن .NET Core لا يدعم الوكيل الافتراضي لأنه يتم تحميل إعدادات الوكيل الافتراضي من التسجيل.

لذلك ، يجب أن يعمل إذا كنت لا تستخدم الوكيل وسوف يتعطل على .NET Core إذا تم استخدام الوكيل. في الوقت الحالي أضفت فئة "الوكيل الافتراضي" ، والتي تنص على تجاوز كل شيء والانتقال مباشرة. إذا كان عليك استخدام الوكيل - فسيتعين عليك توفيره باستخدام طريقة ConfigureProxy .

يرجى تجربة أحدث حزمة: https://www.nuget.org/packages/RestSharp/106.0.0-alpha0281

niemyjski في الواقع ، تجتاز اختبارات التكامل جيدًا على نظام التشغيل Mac. لذلك يجب أن يعمل على Linux أيضًا ، على ما أعتقد.

alexeyzimarev لم تنجح الحزمة الأخيرة بالنسبة لي في Win 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 هل يمكنك تجربة هذا أيضًا ، مع UWP؟ 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.

لذا فإن السؤال هو لماذا لا يعمل بدونه ، حيث قمت بتضمين هذه الأسطر في كود RestSharp ...

ربما WebRequest له نطاق مختلف؟ هل هي فئة ثابتة أم مؤسسة؟

يمكنك معرفة ذلك من خلال إنشاء نموذج للتطبيق ، وفي نموذج التطبيق الخاص بك ، تحقق من:

WebRequest.DefaultWebProxy

وأيضًا كشف بعض الطرق لـ RestSharp لإرسال القيمة التي تراها (لأغراض التصحيح) - على سبيل المثال:

public IWebProxy GetCurrentProxy() => WebRequest.DefaultWebProxy;

انظر ما إذا كان الاثنان مختلفان؟

qJake سأكون ممتنًا لو تمكن شخص ما من تصحيح الأخطاء بالنسبة لي :) لن أتمكن من قضاء أي وقت في هذا الأمر حتى الأسبوع المقبل ، وسأتحدث في أحد المؤتمرات.

الحزمة الجديدة متاحة حيث يتم "إصلاح" مشكلة الوكيل عن طريق تعيين WebRequest.DefaultProxy إلى قيمة خالية. قد يكون هذا نتيجة ولكن لا أتوقع مشاكل حقيقية. يتم إضافة الحل البديل فقط إلى تجميع .NET Standard. يجب أن يعمل تجميع .NET Framework كما كان من قبل.
https://www.nuget.org/packages/RestSharp/106.0.0-alpha0284

إذا لم يتم الإبلاغ عن أية مشكلات ، فسوف أبدأ في إعداد الإصدار.

رد إيجابي إلى حد ما هنا. كنت أتلاعب بمحاولة الحصول على حزمة تابعة تعمل (Atlassian.JIRA) وافترض أنني استهدفت .NET standard 2.0 ثم "عملت للتو" جميع اختبارات التكامل / الوحدة الخاصة بهم لذا LGTM.

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.Security.Cryptography.X509 الشهادات

لست متأكدًا من سبب ذلك ، ولكن لا يبدو أنه يسبب أي مشاكل.

المشكلة الثانوية الوحيدة التي نواجهها هي أننا نستخدم clickonce لتوزيع إحدى أدواتنا ، لذا فنحن مضطرون إلى تسمية كل شيء بشكل قوي. ومع ذلك ، النسخة التجريبية ليست قوية التسمية. لقد استخدمنا إصدار RestSharpSigned من الحزمة ولكن لا توجد نسخة تجريبية من ذلك مع دعم. net القياسي.

يمكن أن يكون وجود نسخة مسماة قوية وغير قوية مشكلة في الموقف حيث يكون لديك تبعيتين أحدهما يعتمد على الإصدار المسمى القوي والآخر يعتمد على النسخة المسماة غير القوية.

بدلاً من ذلك ، أقترح أن يكون لديك حزمة واحدة موقعة ومجمدة إلى الإصدار الرئيسي من إصدار التجميع الخاص بك (في SemVer ، يتغير الإصدار الرئيسي فقط عند كسر التوافق) ثم استخدام SemVer الكامل على FileVersion الخاص بك. بهذه الطريقة يكون لديك حزمة nuget واحدة يمكن لأي شخص استخدامها (باسم قوي أم لا) ويعني تجميد الإصدار الرئيسي أن عمليات إعادة توجيه الربط غير مطلوبة. واستخدام SemVer يعني أن كل شخص يعرف بالضبط أين يقف من حيث التوافق.

أقترح هذا هنا لأن التبديل إلى معيار net قد يكون الوقت المناسب لإجراء هذا التغيير.

يجب علينا فقط التوقيع على الحزمة افتراضيًا ووضع المفتاح في GitHub ، يوصي فريق .net بهذا لأنه لا يضر بأي شيء.

هل هناك علاقات عامة يمكنني من خلالها مشاهدة التغييرات؟

niemyjski أفترض أن الفرع develop مرئي للجميع. لقد جعلته فرعًا افتراضيًا أيضًا.

niemyjski "Just" لا يعمل في هذه الحالة. إذا كنت تريد المساعدة - الرجاء القيام بذلك. اضطررت إلى إزالة مشاريع Signed لأنها فشلت في بناء الحل بالكامل بسبب خطأ في nuget.
https://github.com/dotnet/standard/issues/538
https://github.com/NuGet/Home/issues/6038

لذلك إما سأحتاج إلى الانتظار حتى يتم إصلاحه ، أو يجب علي إضافة حل ومشاريع منفصلة ، ثم تضمين جميع الملفات يدويًا ، وهو أمر سيئ.

alexeyzimarev ليس لديك سوى

إذا كنت تصر على الاحتفاظ بنسختين (مما سيؤدي إلى حدوث مشكلات للمستخدمين) ، فلا يزال بإمكانك القيام بذلك باستخدام csproj واحد عبر التكوين.

لقد فعلت هذا في الأصل في مشروعي الخاص (وقد نجح) قبل أن أدرك مدى تعطل إصدار نسختين. لقد أضفت مجموعة خصائص StrongName بشكل أساسي. ثم قم بالبناء باستخدام 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>

إذا انتظرت إصلاح المشكلات التي أثارتها ، فقد تنتظر وقتًا طويلاً.

هذا سوف يحل كل مشاكلك

أنا فقط أحب ذلك.

اقتراح مجموعة الممتلكات قيمة. سأحاول الاحتفاظ بحزمتين ، وإلا فسيحدث ذلك ارتباكًا. قد أكون مخطئًا ولكنني شخصياً سأتجنب التوقيع. ولكن نظرًا لأنك في حاجة إليها - سأحاول إنشاء حزمة بتجميع موقع.

niemyjski هل لديك رابط إلى "يوصي فريق .net بهذا"؟ أحتاج إلى معرفة المزيد عن العواقب وكيف يقترحون بالضبط القيام بذلك.

لقد تحدثت معهم وأنا أعلم أنهم قالوا ذلك أيضًا علنًا
المنتديات والركود. إنها نوع من المزحة ويجب إزالتها (
https://twitter.com/terrajobst/status/774752534682402817) .. من الأفضل أن
مجرد تسمية قوية للتجميع ... نحن نشجع جميع مجموعاتنا و
اترك التوقيع snk في الريبو لأنها مزحة. أي شخص لديه محرر ست عشري
يمكن أن يتجاوز توقيع الاسم القوي ويؤذي فقط أولئك المطلوب منهم
التوقيع على حزمهم من أخذ التبعيات. يمكنك الرجوع إلى ملف
حزمة موقعة من حزمة غير موقعة ، فلماذا لا تقوم فقط بتوقيعها بالكامل
زمن.

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

شكرا
-بليك نيميجسكي

يوم الأربعاء 1 نوفمبر 2017 الساعة 1:30 ظهرًا ، Alexey Zimarev [email protected]
كتب:

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

لست متأكدًا مما يغطيه هذا الإصلاح ، لكننا ما زلنا نواجه مشكلات في استخدام الوكيل.
قبل منفذ .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؟

لأنك إذا قمت بفصل stacktrace ، فسترى أن هذا ليس استثناءً لدينا ولكنه استثناء .NET عندما حاول الحصول على وكيل افتراضي.

نعم ، أنت محق alexeyzimarev ، تم طرح الاستثناء في System.Net.SystemWebProxy.GetProxy ، لقد كنت سريعًا في بدء التشغيل. :)

بالنسبة للآخرين الذين يواجهون نفس المشكلة ، يمكنك تحديد البروكسي صراحةً لاستخدامه مثل هذا:

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

لقد قمت بالترقية من 106.1.0 إلى 106.2.0 على .NET Core 2.0 وبدأت هذه الرسالة في الظهور:

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

كما ذكر آخرون ، يبدو أن هذه الرسالة تم إنشاؤها بواسطة System.Net.SystemWebproxy.GetProxy ، لكن في حالتي لا أقوم بتكوين وكيل على الإطلاق ، داخليًا يقوم بعملياته الخاصة ويطرح استثناء على كل طلب أقوم به.

لقد كررت مرة أخرى إلى 106.1.0 وهذا أصلحها ، فهل تغير شيء ما في 106.2.0 حيث يجب أن تكون إعدادات الوكيل صريحة بطريقة ما؟

voicebooth ورد هذا في # 1061