Runtime: تم انتهاك قواعد أمان الوراثة حسب النوع: "System.Net.Http.WebRequestHandler". يجب أن تتطابق الأنواع المشتقة مع إمكانية الوصول الأمني ​​للنوع الأساسي أو أن تكون أقل وصولاً.

صادف أن ألقي نظرة على هذا اليوم من تقرير آخر. تضمين التغريدة

يبدو أن هذا قد يكون بسبب فقدان سمات الأمان على System.Net.Http.dll خارج النطاق مقارنة بعلبة الوارد System.Net.Http.dll. يحتوي إصدار البريد الوارد على AllowPartiallyTrustedCallers. وكذلك الحال في علبة الوارد System.Net.Http.WebRequest.dll. هذا يعني أن كل شيء يتم التعامل معه باعتباره SecurityTransparent ما لم يتم توضيح خلاف ذلك.

يفتقد OOB System.Net.Http.dll AllowPartiallyTrustedCallers ، مما يجعل كل شيء مهمًا للأمان. الآن عندما يقوم WebRequest.dll بعلبة الوارد بتحميل OOB System.Net.Http.dll ، فإنه ينتهك قاعدة الأمان ، نظرًا لأن WebReqeuestHandler شفاف ، ولكن HttpClientHandler الذي اشتق منه أمر بالغ الأهمية.

بلدي ريبرو:

1. ملف> تطبيق سطح المكتب الجديد
2. خصائص المشروع> التوقيع> تمكين توقيع strongname
3. أضف مرجعًا إلى System.Net.Http.WebRequest
4. قم بتثبيت System.Net.Http 4.1.0.
5. بشكل رئيسي ، ما عليك سوى استدعاء WebRequestHandler () الجديد ؛

ericstj على حق ، لدي نفس المشكلة هنا. هذه مشكلة حرجة في System.Net.Http 4.1.0 يجب إصلاحها. لا يمكنني استخدام هذه المكتبة مع .net4.6.1 لأنها تفتقر إلى التناسق.

هذه المشكلة هي مشكلة كبيرة يجب التعامل معها ، وبشكل خاص تجعل استخدام عميل Azure KeyVault مؤلمًا لفريقي. البديل الوحيد غير المؤلم هو الرجوع إلى .NET 4.5.2 ، وهو أمر غير مقبول.

أيضاً ، الحل البديل المذكور سابقاً غير كافٍ. إذا كنت ترغب في استخدام NET 4.6.x ، فإن ما وجدناه هو أنه يتعين عليك القيام بما يلي حتى تعمل بشكل موثوق: تعطيل فحص التبعية ، الرجوع إلى إصدار أقدم System.Net.Http ، تحرير CSPROJ وتعطيل إعادة توجيه الربط التلقائي ، وتعديل app.config ، وعادةً ما ينظف / يخرج من VS / ويعيد البناء كما رأيت غالبًا System.Net.Http قيد الاستخدام ، حتى بالنسبة للمشاريع البسيطة. إليك الإجراء الذي يعمل على إصلاح هذا بشكل موثوق.

1. انقر بزر الماوس الأيمن فوق المشروع في Visual Studio وحدد إدارة حزم NuGet.
2. انتقل إلى علامة التبويب المثبتة.
3. قم بالتمرير لأسفل إلى SYSTEM.Net.Http - وليس Microsoft.Net.Http.
4. في الجزء الأيمن ، إذا لم يكن التثبيت 4.0.0.0 ، فقم بتعيين الإصدار على 4.0.0.0.
5. في الجزء الأيمن ، اضبط سلوك التبعية على تجاهل التبعيات. إذا لم تقم بذلك ، فسيتم إرجاع حزمة Microsoft.IdentityModel.Clients.ActiveDirectory إلى إصدار سابق ، وهذا ليس صحيحًا.
6. انقر فوق تحديث - يجب أن يسمى هذا الزر بالفعل "التغيير إلى الإصدار".
7. في نافذة المعاينة ، تحقق من أن التغيير الوحيد المدرج هو "تثبيت System.Net.Http". إذا نسيت ضبط سلوك التبعية بشكل صحيح ، فسيتم إدراج التغيير الإضافي هنا.
8. انقر فوق موافق / نعم / أوافق في مربعات حوار التأكيد وانتظر حتى تكتمل المعالجة. عند اكتمالها ، ستعرض قائمة الحزمة رقمين للإصدار - تكون علامة الاختيار بجوار الرقم قيد الاستخدام.
9. في علامة التبويب تثبيت NuGet ، حدد قائمة Microsoft.IdentityModel.Clients.ActiveDirectory.
10. في جزء التفاصيل الأيمن ، عيّن سلوك التبعية على "تجاهل". إذا لم تقم بذلك ، فستفشل أي إضافات NuGet لاحقة عند تشغيل التحقق من صحة NuGet لهذه الحزمة.
11. في Visual Studio ، حدد ملف | حفظ الكل.
12. افتح ملف CSPROJ لهذا المشروع في محرر نصي.
13. في / Project / PropertyGroup * 1 (أول عنصر PropertyGroup في المشروع) ، أضف السطر التالي ، أو قم بتغيير قيمة هذا العنصر إذا كان موجودًا بالفعل:
    <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
14. احفظ الملف ، ثم أعد تحميل المشروع في Visual Studio.
15. افتح ملف app.config لهذا المشروع.
16. ابحث عن سطر System.Net.Http وقم بتحريره لإعادة توجيهه إلى 4.0.0.0 بدلاً من 4.1.0.0. لذا ابحث عن هذا:

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" /> 
</dependentAssembly> 

وقم بتغييرها إلى هذا:

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.0.0.0" /> 
</dependentAssembly> 

1. إعادة بناء المشروع. إذا حصلت على استثناء عند تشغيل رمز Azure Key Vault ، فلن يتم تحديث ملف أو أكثر من ملفات * .config في الحاوية / التصحيح أو الدلائل المماثلة. قد تضطر إلى الخروج من Visual Studio لمسحها وإعادة البناء.

dluxfordhpf ، شكرًا على وقتك في شرح كيفية عمل ذلك. عملت إعادة التوجيه إلى System.Net.Http 4.0 بالنسبة لي في .net4.6.1 ، ولكن لا يزال من الصعب جدًا الحفاظ عليها (تبعية nuget). نتطلع إلى الإصدار الذي سيصلح هذا.

قد تتسبب إعادة التوجيه في حدوث مشكلات إذا كان الأشخاص يستخدمون أيًا من واجهة برمجة التطبيقات الجديدة المضافة في System.Net.Http 4.1.0.

بشكل خاص يجعل استخدام عميل Azure KeyVault مؤلمًا لفريقي

واجهChadNedzlek نفس المشكلة وكان قادرًا على حلها عن طريق تمرير HttpClient الذي أنشأه بنفسه إلى مُنشئ KeyVaultClient. إذا كنت لا تستخدم WebRequestHandler ، فستتجنب المشكلة.

على سبيل المثال:

c# var handler = new HttpClientHandler(); // configure handler // eg: handler.ServerCertificateCustomValidationCallback = (message, cert, chain, errors) => errors == SslPolicyErrors.None; var client = new HttpClient(handler); var kvclient = new KeyVaultClient(async (authority, resource, scope) => "foo", client);

davidsh أعتقد أنك بحاجة إلى إعادة AllowPartiallyTrustedCallers مرة أخرى إلى System.Net.Http.dll. / cc morganbr

dluxfordhpf شكراً جزيلاً على الخطوات.
إنه مؤقت ونأمل أن يتم إصلاحه قريبًا ولكن لا يزال بإمكاني مواصلة العمل في المشروع!

terrajobst هذه مشكلة تتعلق بحظر الإنتاج. أي فكرة متى يمكننا الحصول على إصلاح في NuGet؟ شكر!

فقط واجهت هذا بنفسي. سيكون رائعًا إذا لم ننزل إلى جحيم التبعية في .Net. إنه يتجه بهذه الطريقة.

تحرير: تم الإصلاح مع اقتراح تعليقات مسبقة لاستخدام نظام httpclient ؟؟
new KeyVaultClient(GetAccessToken, new HttpClient(new HttpClientHandler()))
يبدو أن هذا حصل عليه ...

تزداد المشكلة سوءًا نظرًا لأن المزيد والمزيد من حزم nuget من Microsoft تعتمد على أحدث إصدار من System.Net.Http. ربما لست الوحيد الذي يقوم باستمرار بترقية حزم Microsoft nuget إلى أحدث إصدار قبل الإصدار. على سبيل المثال الحزم التي لم تعد تعمل معي في أحدث إصدار لها:

Microsoft.IdentityModel.Clients.ActiveDirectory
Microsoft.TeamFoundationServer.Client
Microsoft.VisualStudio.Services.Client.
....

ما زلت لا أفهم لماذا لا تزال هذه الحزمة متاحة. terrajobstcoolcsh هل يمكننا إزالة / إصلاح هذه الحزمة؟ إنها تسبب بالفعل مشكلات في بيئات التطبيقات المعقدة. أهدرت عدة ساعات في محاولة لمنع الحزمة المخالفة من التسلل إلى البناء. شكر!

نحن نبحث في الارتباط بـ System.Net.Http في NET Framework بدلاً من هذا الشيء المعطل من NuGet. أوافق على أن هذه المشكلة سخيفة ومكلفة للغاية للتعامل معها حيث يجب عليك مزامنة إصدارات NuGet بين المشاريع ومنع تحديثات الربط التلقائي وإصلاح / التحقق من app.config. ما يفاجئني هو أنه في مثل هذا التجميع المستخدم على نطاق واسع. ربما لا يهتم MS حقًا KeyVault كثيرًا؟

يتم استخدامه أيضًا بواسطة ActiveDirectory Nugget

لقد عدت بعض المكتبات من استهداف .NET Standard بسبب هذا والمشكلات ذات الصلة حيث تؤدي حزم NuGet المعطلة إلى تعطل التطبيقات التي تستهدف .NET Standard. هذه حالة مؤسفة من الأشياء.

شكرا للتقديم. نحن نبحث بنشاط في هذا. ترقب.

لقد أصبحت هذه قضية مهمة بالنسبة لي. نحن نستخدم الكثير من حزم nuget الخاصة بنا داخليًا. ويبدو أن nuget فقط _لن ندع هؤلاء bindingRedirect s بمفردهم. في كل مرة نقوم فيها بتحديث إحدى newVersion="4.1.0.0" . هل هناك طريقة لمنعها من القيام بذلك ، أم أن هناك إصلاح في الأفق؟

تمت مصادفته عند تشغيل التطبيق عبر HTTPS ، والذي كان يعمل بشكل جيد عبر HTTP. لست متأكدا إذا كان هناك أي اختلافات كبيرة أخرى.
الحل البديل لإعداد newversion="4.0.0.0" نجح معي.

لا تزال مشكلة في NETStandard 1.6.1. لماذا ا؟!

System.Net.Http 4.3.0 خارج. حاول شخص ما؟

LoulG نعم ، ما زلت أخشى مشكلة.

لقد تحدثت مع terrajobst على Twitter ، وقال إنها في الواقع مشكلة أكبر ، ولديهم مثل 10 أشخاص يعملون عليها الآن. لست متأكدًا شخصيًا من سبب عدم قيامهم بسحب إصدارات هذه الحزمة التي تعرض المشكلة ، حيث اعتقدت أن هذا هو الغرض من إدارة الحزم. لكن الخطوة التالية التي يمكننا القيام بها في هذه المرحلة هي الانتظار.

LoulG نفس الشيء هنا ، لقد قمت بتحديث جميع حزم Nuget الخاصة بي ، مع إصدار .net core 1.1 وحصلت على هذه المشكلة

System.TypeLoadException: تم انتهاك قواعد أمان الوراثة حسب النوع: "System.Net.Http.WebRequestHandler". يجب أن تتطابق الأنواع المشتقة مع إمكانية الوصول الأمني ​​للنوع الأساسي أو أن تكون أقل وصولاً.

أولاً ، أعتقد أنه كان بسبب IdentityServer / IdentityServer3AccessTokenValidation ، لكن مع قراءة هذه المشكلة ، فهمت وضعي t_t ، قضيت عدة ساعات لمحاولة حلها

تعديل :
يا الهي،
الحل البديل لإعداد الإصدار الجديد = "4.0.0.0" نجح معي أيضًا

أحاول التحديث إلى 4.3 ولكن ، نفس المشكلة: (((

نفس المشكلة هنا بعد الترقية

لا تزال المشكلة موجودة مع 4.3.0.

terrajobst ، هل يمكنك تقديم أي تحديثات حول هذه المشكلة أو أي نظرة ثاقبة أخرى حول المشكلة الأعمق التي أشار إليها

هل هناك أي سبب يجعل هذا الإصلاح يعمل محليًا ، ولكن عند نشره في Azure Cloud Service ، يستمر الخطأ؟

في بعض الأحيان ، يمكن أن تؤدي حزم Azure إلى إفساد عمليات إعادة التوجيه الملزمة ، حاول فك ضغط cspkg ومعرفة ما يتم نشره بالفعل.

هذا هو إصدار System.Net.Http.dll

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

ماذا عن ملف .config الذي يحتوي على عمليات إعادة توجيه ملزمة للمشروع؟ أتوقع في الواقع أنه لا يزال ينشر الإصدار المعطل من التجميع نظرًا لكون CopyLocal صحيحًا من حزمة nuget ، لكن إعادة توجيه الربط يجب أن تضمن تحميل إصدار إطار العمل للتجميع بدلاً من ذلك داخل VM للخدمة السحابية.

أنه!!! WTH؟

<dependentAssembly> <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> </dependentAssembly>

إذا نظرنا إلى الوراء في مشروعي ، فقد عاد web.config أيضًا. سآخذ هذا مرة أخرى في الصباح. شكرا لبعض الخيوط!

أجد أنه إذا كنت تستخدم AutoGenerateBindingRedirects ثم قمت بتعديل أي حزمة nuget للمشروع ، فسوف "تصلح" عمليات إعادة التوجيه التي تم تعديلها يدويًا مسبقًا إلى الإصدار المعطل. محبط جدا.

ولكن جزءًا من المشكلة هو أنك إذا لم تستخدم توجيهات AutoGenerateBindingRedirects عند إضافة حزم جديدة ، فقد تواجه مشكلات أخرى أيضًا.

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

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

لسوء الحظ ، لا يزال اتباع ما سبق يعمل فقط على إصلاح بيئة التطوير الخاصة بي وليس المنتج الأزرق السماوي. لقد تحققت من أحدث ملف pub وتم تعيين web.config بشكل صحيح مع ملف dll الذي تم نشره باعتباره الإصدار الموضح أعلاه. لسوء الحظ ، تتعلق مشاكلي بمكتبة Azure Search ، لذلك كان هذا الإصلاح واعدًا. أي أفكار أخرى هناك؟ قليلا من الخسارة. شكرا للمساعدة.

لماذا يزيد عمر هذا عن شهرين؟ هذا هو مشكلة كبيرة. ارجو الاصلاح.

هذه مشكلة توقف شحن تمامًا ، يجب معالجتها تمامًا.

من أجل رجال f # $ @ ، أصلح هذا بالفعل. هذا حماقة.

suprduprmn لقد قمت بتحديث جميع الحزم ودمجها ثم غيرت ذلك في جميع ملفات app.config و web.config:

<bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.0.0.0" />

عندها فقط سيتم تشغيل تطبيق الويب الخاص بي على Azure ويكون قادرًا على إجراء مكالمات https إلى خدمات Azure التي تعتمد على System.Net.Http. YMMV لكن حظا سعيدا.

و terrajobst ... هل هناك مكان مناسب يمكنني فيه الشكوى رسميًا من إهمال قضايا رئيسية مثل هذه؟ لا تنطبق هنا قواعد Happy-go-lucky للمصدر المفتوح. هذا هو برنامج Microsoft Showstopper 101 مادة حوالي عام 1995. لا توجد طريقة يمكن أن يساعد بها "المجتمع". يجب عليك إصلاحه ويجب عليك أدوات وعملية معمارية للتأكد من توقفها عن الحدوث. أرى أشياء مثل هذه في العديد من مشاريع Microsoft وهو أمر غير مقبول تمامًا. من الواضح أن هناك فجوات كبيرة في الاختبار. السيناريوهات الأساسية ببساطة لا يتم تثبيتها أو إنشاءها بشكل نظيف ، ناهيك عن العمل بشكل صحيح في وقت التشغيل.

أريد أن أعتذر عن XXXL الوقت الذي استغرقه الرد على هذه المشكلة. لقد مر شهر واحد منذ آخر رد وتم فتح المشكلة لمدة 3 أشهر أو أكثر. أوافق على أن هذا غير مقبول بالنسبة لقضية شديدة التأثير مثل هذه.

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

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

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

لقد فهمت

شكرا لك على الرد. أعتقد أن أفضل حل في الوقت الحالي هو إلغاء تنشيط أي حزمة لا تشير إلى System.Net.Http 4.0.0. يوجد إصداران على الأقل من الحزمة سيئان. أليس هذا هو الهدف من توزيع هذه الأشياء من خلال NuGet في المقام الأول؟

عناق @ ms-team

أيضًا ، فقط لكي تعرف ، بين هذه المشكلة ، المشكلات المتعلقة بـ HttpClient نظرًا لكونها سيئة التصميم للغاية ، والمشكلات المتعلقة بـ Microsoft.Security.Owin.Jwt التي تم كسرها مقابل التبعيات الحالية ، وحالة .NET Core ...

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

كل ما يجب القيام به. حتى لو كان ذلك يعني شحن 4.3.1 يشير إلى الحزمة القديمة 4.0. ارجوك افعلها قريبا

شكرا يا شباب. FWIW ، إذا كنت بحاجة إلى إجراء تغيير جذري ، يرجى القيام بذلك. نحن لا نحب هذا ، لكننا نتعايش مع الألم لعدة أشهر ، والآن بعد أن علمنا أنك مرتبط ، يمكننا الانتظار أكثر من ذلك ، حتى لو كان علينا إجراء بعض التغييرات في واجهة برمجة التطبيقات.

شيء ما خارج القضبان هنا. لقد كنت أقوم بشحن تطبيقات C # لمدة 15 عامًا. ومن المفارقات أنه نظرًا لأن Microsoft يتم شحن التجريدات ذات المستوى الأعلى ، فأنا أقضي المزيد والمزيد من الوقت في البحث بعمق في الأجزاء الداخلية التي لم يكن لدي القلق بشأنها من قبل. أنت تعمل ذلك بالطريقة الخاطئة.

لست ذكيًا بما يكفي لفهم سبب كون إعادة إشارات الثقة في هذه المكتبة أمرًا ضخمًا ولا أفهم لماذا لا أملك المزيد من التحكم في ذلك من تطبيقي على أي حال.

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

تحديث سريع:
لقد التقينا عدة مرات هذا الأسبوع. قمنا بعصف ذهني للخيارات واكتشفنا التمويل.
يعمل CIPop على هذه المشكلة كأولوية قصوى (تم نقل العمل من davidsh الذي سيكون OOF بدءًا من الأسبوع المقبل لبقية العام).

الحالة:

• تمكنا من إعادة إنتاج النسخة الأصلية لـ
• نحن نتابع الحل [3] أدناه - مع التركيز على السؤال المفتوح المتبقي ، أي التحقق من الجدوى الفنية للخيار.
• نحن نستكشف الحل الموازي [2] أدناه - نستكشف سؤاله المفتوح ، أي تقييم تأثير الحل على النظام البيئي.

وصف المشكلة

• لقد قمنا بشحن System.Net.Http 4.3.0.0 "OOB" في يونيو
  
  
  
  • المحتوى البارز (لهذا السياق): HttpCient ، HttpClientHandler
  
  
  • قيمة العميل: دعم الشهادات ودعم http2 ومكدس WinHttp على سطح المكتب
  
  
  • تعمل جميع الأنظمة الأساسية باستثناء سطح المكتب بشكل جيد - بالنسبة لسطح المكتب ، لا يحتوي سطح واجهة برمجة التطبيقات على سمات SecurityAttributes لكود PartialTrust (APTCA = AllowPartialTrustCodeAttribute)
  
  
  • على سطح المكتب ، تتجاوز مكتبة OOB استخدام System.Net.Http 4.0.0.0 الذي يعد جزءًا من النظام الأساسي (ولديه APTCA)
  
  
• System.Net.WebRequestHandler 4.0.0.0 هو جزء من Desktop
  
  
  
  • يعتمد ذلك على System.Net.Http ولديه APTCA ، وبالتالي يتطلب System.Net.Http أن يكون لديه APTCA
  
  
  • يستخدم أنواعًا داخلية من System.Net.Http (الذي يحتوي على InternalsVisibleTo)
  
  
  • إنه نوع قديم "ممل" لا نريده في .NET Core
  
  
• هناك مكتبات (3+ حزم NuGet وتطبيق ASP.NET Core على سطح المكتب) والتي ستجلب (بشكل غير مباشر) كلاً من OOB System.Net.Http 4.3.0.0 والمرجع إلى System.Net.WebRequestHandler 4.0.0.0. التحرير والسرد يمنع تشغيل التطبيق.

حلول

1. [غير مقبول] إعادة توجيه الربط اليدوي - يدويًا لكل تطبيق الرجوع إلى إصدار أقدم (عبر إعادة توجيه الربط) System.Net.Http 4.3.0.0 إلى 4.0.0.0 - من الصعب فهم ماذا / أين وهي خطوة يدوية لكل تطبيق
   
   
   
   • ملاحظة: يُستخدم اليوم كـ "الحل البديل"
   
   
2. [المرشح] تراجع عن قرار خارج النطاق - إعادة الشحن 4.3.1.0 كإعادة توجيه إلى صندوق الوارد 4.0.0.0.
   
   
   
   • الجانب السلبي: سوف نكسر العملاء الذين يعتمدون على الوظائف الجديدة
   
   
   • سؤال مفتوح: هل ستتأثر WCF أو مكتبات NuGet الأخرى على سطح المكتب؟
   
   
3. [المرشح] سمات أمان الرش في System.Net.Http
   
   
   
   • افعل ذلك لسطح المكتب فقط (استخدم #if) ، ولا تنشره في حزم أخرى (قم بالتجميع مقابل مرجع سطح المكتب) ، أضف اختبارات لفرضه في المستقبل.
   
   
   • الجانب السلبي: بعض خصائص WebRequestHandler الخاصة بتنفيذ سطح المكتب لـ System.Net.Http لن تعمل (حسب التصميم عندما قمنا بتبديل التنفيذ)
   
   
   • ملاحظة فنية: يجب أن تكون طرق Async عبارة عن SecurityTransparent (قيود مترجم Roslyn) ، وبالتالي لا يمكنها استدعاء (SecurityCritical) PInvokes - لكل مكالمة PInvoke يجب أن تكون هناك طريقة غلاف SecuritySafeCritical (نوع قبيح ، لكن مباشر)
   
   
   • سؤال مفتوح: هل يمكننا جعل التبعيات الداخلية لـ WebRequestHandler تعمل مع System.Net.Http المستند إلى WinHttp الجديد؟
   
   
4. [مرفوض] OOB WebRequestHandler فقط على سطح المكتب
   
   
   
   • الجانب السلبي: يدفع بالمشكلة إلى الأعلى (تعتمد بعض مجموعات APTCA عليها)
   
   
   • الجانب السلبي: بعض خصائص WebRequestHandler الخاصة بتنفيذ سطح المكتب لـ System.Net.Http لن تعمل (حسب التصميم) - انظر [3] أعلاه
   
   
   • الجانب السلبي: يجب على الجميع إضافة التبعية ، أو إخبار NuGet بتثبيت أحدث
   
   
5. [المرشح] حِزمة System.Net.WebRequestHandler.dll في حزمة System.Net.Http NuGet
   
   
   
   • 2 جوانب سلبية كما في [4] أعلاه:
     
     
     
     
     
     1. الجانب السلبي: يدفع بالمشكلة إلى الأعلى (تعتمد بعض مجموعات APTCA عليها)
     
     
     
     2. الجانب السلبي: بعض خصائص WebRequestHandler الخاصة بتنفيذ سطح المكتب لـ System.Net.Http لن تعمل (حسب التصميم) - انظر [3] أعلاه
     
     
     
   
   

شكرا لك على المعلومات التفصيلية ، نحن نقدر ذلك.

ماذا عن مزيج من الخيار 2 وإعادة الشحن 4.3 كـ 5.0؟ نظرًا لأنه كان تغييرًا تقنيًا ، يمكنك بعد ذلك شحن OOB WebRequestHandler.dll لسطح المكتب كـ v5.0 أيضًا. سيتيح لك ذلك إعادة تنفيذ الوظائف في WinHttp ، وإيقاف الخصائص التي لا يتم تعيينها ، ويمنح الجميع طريقة للمضي قدمًا بالطريقة التي من المفترض أن تتيحها لك SemVer. سيظل Upstream بحاجة إلى إصلاح الكود الخاص بهم أيضًا ، ولكن هذا ليس غير متوقع في إصدار رئيسي ، ويمكنهم أيضًا تقييد حزمهم بحيث لا تتضمن 5.0.

أعني ، لقد حصلت على فكرة الرغبة في شحن مجموعات حزم الإطار بالكامل بنفس أرقام الإصدار ، ولكن أ) كان هذا الكلب مشدودًا بالفعل عندما قمت بشحن كل شيء على أنه 4.0 بدلاً من اتباع إصدار سطح المكتب الحالي ، و ب) الفعلي إصدار التجميع موجود بالفعل في كل مكان (حزمة System.Security.Claims 4.3 تشحن 4.0.2 dll ، وهو أمر مزعج للغاية عند الحاجة إلى إنشاء عمليات إعادة توجيه ملزمة). لذا فقد تم بالفعل الضرر.

يبدو أن dotnet / corefx # 3 هو الحل الوحيد الحقيقي للأسباب الجذرية بالنسبة لي.

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

لا أعتقد أن أي شخص يهتم كثيرًا بإصدارات مجموعات إطار العمل بأكملها أيضًا. بصراحة ، إذا اعتقدت أنه سيساعد غالبية العملاء ، فسأصوت لمجرد تغيير الأرقام - لا أعتقد أنه سيساعد على الإطلاق تقريبًا. سيؤدي ذلك فقط إلى تغيير رسالتنا إلى "نعم ، لقد تعطلت - هذا ما تقوله النسخة ، أنت فقط لم تدرك نوع الأشياء التي توافق عليها عند أخذ الإصدار" ، وهو عذر IMO ضعيف.

نظرًا للاختلاف في الآراء ، فأنا مهتم بما يعتقده الآخرون: يرجى استخدام التأييد / التصويت المعارض على هذه المشاركة:

• 👍 إذا كنت تتفق معي ، أي أنك تعتقد أن شحن التغيير العاجل لأن 5.0 لن يحدث فرقًا وسيظل معظم الأشخاص منكسرين ومشوشين ومتأثرين.
• 👎 إذا كنت توافق على اقتراح robertmclaws ، على العاجل مثل 5.0 سيساعد الأشخاص على فهم مقدمًا ، يجب عليهم الابتعاد عن الحزمة ، لأنه سيؤدي إلى كسر التحرير والسرد مع مكتبة أخرى ويمنع الألم غير الضروري للمطورين.

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

ما زلت في حيرة من أمري حول سبب هذه المشكلة في البداية
مكان. أنتم يا رفاق تتحدثون حقًا فوق رأسي.

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

ألم أقرأ مقالًا قبل بضعة أشهر حول كيفية استخدام معظم ملفات
كانت مكتبة System.Net.Http قيد الغروب لصالح مكتبة أعيد بناؤها؟

في 15 كانون الأول (ديسمبر) 2016 ، الساعة 3:18 مساءً ، كتب "Karel Zikmund" [email protected] :

robertmclaws https://github.com/robertmclaws لا نعتقد أن ملف
تغيير الإصدار سيحدث فرقا. معظم الناس (التطبيق والمكتبة
مالكي) عادةً "اضغط على الترقية إلى الأحدث" في حزمهم ، فهم
لا تهتم بمدى تغيير الإصدار (ثانوي مقابل كبير). لذا فإن الكسر
سيكون التأثير هو نفسه بالضبط.
بل والأسوأ من ذلك أن تأثير "الانهيار" لن يظهر إلا عندما
تجمع أشياء متعددة. لهذا السبب تراجعت هذه المشكلة في ملف
المركز الأول - ليس لدينا اختبار لهذا السرد (وأنا أزعم
هذا جيد - لا يمكن للمرء اختبار جميع المجموعات ، لكن يمكننا مناقشتها في
بعد الوفاة).

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

نظرًا لاختلاف الآراء ، فأنا مهتم بما يعتقده الآخرون:
الرجاء استخدام التصويت المؤيّد / التصويت المعارض على هذا المنشور:

• 👍 إذا كنت تتفق معي ، أي أنك تعتقد شحن التغيير العاجل
  نظرًا لأن الإصدار 5.0 لن يحدث فرقًا وسيظل معظم الأشخاص محطمين ،
  مشوشة ومتأثرة.
• 👎 إذا كنت توافق على robertmclaws https://github.com/robertmclaws 's
  الاقتراح ، أي تعتقد أن شحن التغيير العاجل مثل 5.0 سيساعد
  يفهم الأشخاص مقدمًا أنه يجب عليهم الابتعاد عن الحزمة ،
  لأنه سوف يكسر التحرير والسرد مع مكتبة أخرى ويمنع
  معاناة لا داعي لها للمطورين.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267446604 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAavtBRE24SlHsZHCYm5OhPbOGs6MfRzks5rIa68gaJpZM4JsdDX
.

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

karelz أقدر ما تحاول القيام به هنا ، لكن إجراء استطلاع حول معنى "الإصدار 5.0" يعد إهدارًا تامًا لوقت الجميع. إنه برنامج GitHub للتواصل الاجتماعي وليس الهندسة. سأقوم بشحن الإصدار 5.0 اليوم الذي يعمل على إصلاح هذا وشحن 6.0 عندما تكتشف كيفية ضبط جميع التعليقات التوضيحية الصغيرة بشكل صحيح و / أو إعادة تشكيل الكود.

عبارات مثل "عادةً ما يقوم معظم الأشخاص (مالكو التطبيقات والمكتبة) بالضغط على الترقية إلى الأحدث" ليست مفيدة. هذه هي الطريقة التي تمكنت بها Perl 6 و Python 3 و Rails 3 & 4 و Node.js 1،2،3،4،5 & 6 من تقسيم الأشياء. دعونا لا نتبع ذلك.

dluxfordhpfciel لسوء الحظ، وهذا هو منطقة يصعب تفسيره. كل هذا يأتي من Code Access Security "القديم" الذي لم يعد موصى به بشكل نشط للاستخدام.

فيما يلي ملخص لما هو / كان الغرض منه:
https://msdn.microsoft.com/en-us/library/ee191569 (v = مقابل 110) .aspx
https://msdn.microsoft.com/en-us/library/dd233102 (v = مقابل 110) .aspx

يجب أن تفعل المشكلة الفعلية كما قال karelz بنوع من مستوى واحد من شفافية الأمان (عن طريق التواجد في إطار عمل سطح المكتب) تحاول الاشتقاق من نوع له موقف أمان أقل تقييدًا (لأن السمات مفقودة في إصدار OOB). هذا لأن CAS كمفهوم غير موجود في أي شيء آخر غير .net لسطح المكتب.

في سياق المستندات أعلاه ، انظر إلى هذا القسم الخاص بقواعد الميراث

يصف القواعد المطلوبة لميراث الأنواع عبر مستويات الأمان المختلفة.

شكر! أنا على دراية بـ CAS ؛ التقنيات رائعة.

بالنظر إلى جميع التغييرات في رقم الإصدار بين .NET Core و .NET Standard ، وآخرون. آل. في العام الماضي (وشحن كود جديد بإصدار 4.3 على NuGet يعمل على 4.6.2 ، أفهم أن Microsoft قد لا تعتقد أن أرقام الإصدارات مهمة. ولكن كشخص يدير بمفرده بنية تطبيق معقدة للغاية ، ويشحن أكثر من 20 OSS NuGet الطرود ، أنا أختلف بصدق.

يعد الضغط على "تحديث الكل" دون التحقق من التوافق أسهل طريقة في .NET لإفساد تطبيقك وعدم معرفته حتى وقت التشغيل. يعد الالتزام بـ SemVer هو الطريقة الوحيدة للحفاظ على أي شعور بالعقلانية. زيادة النسخة الرئيسية تشير إلى أن شيئًا ما سوف ينكسر. عندما تشير إلى هذا التغيير ، تحصل عندئذٍ على حرية القيام بكل ما تريد لإصلاحه.

يبدو الإصلاح المقترح جيدًا بالنسبة لي ، لكني أود فقط التعليق على مصفوفة الاختبار - سيكون استخدام HttpClient على سطح المكتب .NET أمرًا رئيسيًا في المستقبل المنظور. يجب بالفعل اختبار هذا التحرير والسرد ، على الرغم من أنه لا يمكن / يجب اختبار كل الاحتمالات.

نعم ، يبدو الشيء الاختباري لي أيضًا وكأنه عمل. أضف أفضل 100 حزمة إلى مشروع اختبار الوحدة الخاص بك وتأكد من استمرار تشغيل حماقة. يبدو أنه نوع الهندسة الأساسية التي اعتادت Microsoft القيام بها قبل أن تدرك أنه بإمكانها طرد المختبرين وترك "المجتمع" يفرز هذه الأشياء بدلاً من ذلك. إنها مجرد مضيعة رهيبة ومحبطة للوقت.

لأن ضمان الجودة "القديم" الذي قدم لنا Windows ME و Vista كانا متفوقين.

أيضًا ، أنا متأكد من أن إهانتهم سيؤدي إلى إنجاز المهمة بشكل أسرع.

في 16 كانون الأول (ديسمبر) 2016 ، الساعة 7:46 صباحًا ، كتب "chadwackerman" [email protected] :

نعم ، يبدو الشيء الاختباري لي أيضًا وكأنه عمل. أضف أعلى 100
حزم لمشروع اختبار الوحدة الخاصة بك وتأكد من استمرار تشغيل حماقة.
يبدو أنه نوع الهندسة الأساسية التي اعتادت Microsoft القيام بها من قبل
مدركين أن بإمكانهم طرد المختبرين والسماح لـ "المجتمع" بفرز ذلك
بدلا من ذلك. إنها مجرد مضيعة رهيبة ومحبطة للوقت.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267597137 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAavtAUL3pmMiSRnFBe7DEa0y5AaZoVXks5rIpZIgaJpZM4JsdDX
.

وجد قائد الفريق لا أحد يدعو إلى حفلات العيد لأنه
يعامل الناس مثل القرف.

في 16 كانون الأول (ديسمبر) 2016 ، الساعة 8:26 صباحًا ، كتب "chadwackerman" [email protected] :

نداء الهراء صدق أو لا تصدق لا ينجز المهمة بشكل أسرع.
وإلا لديك مديري تطوير مليونيرين لم يكتبوا سطرًا من
رمز في 10 سنوات يقول "هذا شيء رائع على Github بالتأكيد أنيق. دعنا نخترق
التصويت بالإيجاب / التصويت السلبي على الرموز التعبيرية وإجراء استطلاع حتى لا أضطر إلى اتخاذ قرار ".
كما لو أن هذا سيحل أي شيء بعد أشهر عمل رجل وستة
ساعات من اجتماعات الفرز داخليا. إنها إشارات اجتماعية كاذبة و
بصراحة ، هذا النوع من المهندسين الذين اعتادوا أن ينادونا بجودة عالية
مثل صاروخ Saturn V. و .NET الذي كان أفضل تغليف لغوي
والمكتبة القياسية لأي شيء في هذا الفضاء قبل وقت طويل من كل هذا عبر الإنترنت
بدأت البلاهة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267604666 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAavtEigDK5EqlA4LQVlxB_lfamMgHanks5rIp9-gaJpZM4JsdDX
.

أو ربما وجدت الشخص الذي تعلم كيفية إلغاء حظر فريقه بالكامل عن طريق جعل Microsoft تتصرف أخيرًا بشأن مشكلة تم تجاهلها لعدة أشهر.

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

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

في 16 كانون الأول (ديسمبر) 2016 ، الساعة 8:34 صباحًا ، كتب "chadwackerman" [email protected] :

أو ربما وجدت الشخص الذي تعلم كيفية إلغاء حظر فريقه بالكامل
جعل Microsoft تعمل أخيرًا على حل مشكلة تم تجاهلها لعدة أشهر.

لدى Microsoft قوائم أخطاء وأولويات مكررة بالكامل داخليًا.
جيثب عبارة عن مجموعة من الهراء الاجتماعي. لن يأخذوا طلب سحب
هذه المشكلة على أي حال حتى يتحول هذا إلى موضوع دعم العملاء. المطورين
قام بعمل سيئ هنا ولا بأس في سماعه.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267606461 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAavtHTdxym7pvR9KRomyIT14FVaILLFks5rIqF8gaJpZM4JsdDX
.

سأرد فقط لأن Microsoft تستخدم "الفرز حسب GitHub number_of_comments" للمساعدة في ما karelz مثل "اكتشاف التمويل". نرحب باستخدام مقياس الرموز التعبيرية GitHub للتحقق من صحة قيمك الاجتماعية أيضًا.

جاء المتأنق وقال إن SemVer لا يهم. من واجبنا كمهندسين أن نشير إلى مدى سخافة ذلك. إنها حالة كلاسيكية حيث نحتاج إلى مدير أكبر لديه خبرة فعلية ، أو إلى شاب أكثر صغرًا يعرف بالفعل كيف تؤثر الأشياء على العالم الحقيقي. يمثل المدراء المتوسطون الذين يلعبون دور رئيس البلدية على جيثب المشكلة الحقيقية هنا. الآن لا تتردد في النقر فوق "رفض" حتى نتمكن جميعًا من متابعة يومنا هذا ، شكرًا لك.

نعم ، لقد امتص هذا الخطأ ، وأنا مندهش لرؤية المسار الرئيسي Sev1 تم إصداره. لكن الألم الحقيقي من IMHO يرجع إلى تصميم NuGet: أي حزمة NuGet يستخدمها المشروع يجب أن تتم الإشارة إليها يدويًا من قبل جميع مستهلكي هذا المشروع. هذا هو تكرار لا داعي له وتصميم سيء ، إنه يهيئك للفشل. يكون معالج المزامنة عديم الفائدة عندما يكون التصميم الأساسي سيئًا. NUGET هو السبب في أن هذا الخطأ مؤلم للغاية. وإلا فإننا سوف ندخن ، ونضع الحل السيئ في Util ، وسنكون قادرين على نسيانه. لكن علينا الآن أن نكون حذرين في جميع المشاريع الـ 18 المستهلكة تقريبًا ، والتي تنمو كل شهر. هذا هو السبب في أن هذا الخطأ مؤلم للغاية - بسبب NuGet ، لا يمكن عزل الإصلاح في مشروع واحد ، عليك أن تلمس كل شيء ، وتستمر في القيام بذلك.

أيضًا ، أردد الشعور بأن Desktop / Windows .NET هو المهم. يسعدني أن أسمع عن وصول Microsoft .NET إلى Linux ، ولكن المال موجود على Windows ، وهذا هو المكان الذي يجب أن نحظى فيه بأفضل تجربة ، وأريد أن يعمل ذلك بشكل أفضل.

مشكلة مستمرة لدى فريقي هي "لماذا يتعين علينا تنزيل كل هذه الحزم؟" نقوم بإنشاء وحدة تحكم أو مشروع ASP.NET وكل ما تحتاجه موجود في الصندوق. أنت تنشئ شيئًا أكثر حداثة وتنزيل 5 مليارات.

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

السبب في أن هذه المشكلة (و dotnet / runtime # 17786) تسببت في الكثير من الألم لنا لأننا نقلنا خدماتنا السحابية من أدوار Azure على الويب إلى خدمات نسيج الخدمة واضطررنا إلى الانتقال إلى netcore / netstandard ، ولكن لا يزال يعمل في إطار كامل تطبيقات.

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

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

لذا مهما كان الحل ، إذا كانت الحزمة الجديدة لا تدعم HttpClient / HttpClientHandler الأحدث فلن نأخذها. هذه ليست مشكلة كبيرة لأن الأمور تعمل الآن. ومع ذلك ، يجب أن يأتي "الإصلاح الحقيقي" بعد فترة وجيزة ، لأنني لا أريد أن أكون ممنوعًا من تحديث المزيد من حزم الجهات الخارجية التي قد تنقل أكوادها إلى معيار الشبكة وإدخال هذه المشكلة.

dluxfordhpf ... سيكون من الجيد رؤية وصف جيد للمشكلة الداخلية حتى نفهم الحلول المقترحة ...

حاولت وصف المشكلة هنا: https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198.
باختصار:

• حزمة Http NuGet 4.1 / 4.3 "تتجاوز" Http 4.0 في .NET Framework ، ولكنها لا تحتوي على سمات أمان. علاوة على ذلك ، فإنه يستخدم مكونًا مختلفًا لنظام التشغيل أسفل الغطاء (أي "تغيير كبير" + حالات كسر الزاوية المحتملة (على الرغم من عدم ارتباطه بشكل مباشر بهذه المشكلة ، إلا أنه يشير إلى وجود مشاكل)).
• يعد WebRequestHandler جزءًا فقط من .NET Framework ، ولكنه يعتمد على Http 4.0 ويتطلب سمات أمان في Http.
• بمجرد أن تأخذ الاعتماد على Http 4.1 / 4.3 من NuGet وتعيد توجيه إصدار 4.0 .NET Framework الوارد إليه ، لا يمكنك استخدام WebRequestHandler.
• لجعل الأمور أسوأ ، يحتوي Http على بعض واجهات برمجة التطبيقات الجديدة التي تعد جزءًا من .NET Standard 1.6 وتعتمد بعض المكونات عليها. لذلك لا يمكننا ببساطة التراجع إلى الإصدار القديم.
• وبالطبع التفاصيل تجعل الأمر أكثر تعقيدًا.
• التصريح بما هو بديهي: لا يوجد "حل صحيح". إنها مسألة اختيار الشخص الذي له تأثير أقل بشكل عام.

chadwackerman ... إجراء استطلاع حول معنى "الإصدار 5.0" هو إهدار كامل لوقت الجميع. إنه برنامج GitHub للتواصل الاجتماعي وليس الهندسة.

إنه ليس التنشئة الاجتماعية. إذا نظرت إلى الأصوات ، فإنها تظهر عدم وجود رأي إجماعي في هذا الشأن. لذا ، حتى إذا كنت لا تثق في رأي فريق CoreFX (الذي يتمتع بخبرة تزيد عن 10 سنوات مع عملاء .NET) الذي يقول " لا يهتم الأشخاص بالإصدار الرئيسي كما نرغب " ، آمل أن يكون من المفيد أن نرى أنه حتى بعض MVPs ( onovotny) شاركنا هذا الرأي. بينما لا يوافق اللاعبون الأساسيون الآخرون (robertmclaws).

chadwackerman ... سأقوم بشحن إصدار 5.0 اليوم

إنه الخيار [2] الذي عرضته أعلاه (بأرقام إصدارات مختلفة). إنه شيء نستكشفه بالتوازي. نظرًا لتأثير الحل ، ليس من الواضح " نعم - من الواضح أن هذا هو الشيء الصحيح الذي يجب عمله ، دعنا نذهب إليه ".

robertmclaws ... قد لا تعتقد Microsoft أن أرقام الإصدارات مهمة ... عندما تشير إلى هذا التغيير ، تحصل حينئذٍ على الحرية للقيام بكل ما تريد لإصلاحه ...

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

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

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

chadwackerman ... أضف أفضل 100 حزمة لمشروع اختبار الوحدة الخاص بك ...

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

chadwackerman ... ودع "المجتمع" يفرز هذه الأشياء بدلاً من ذلك ...

نحن (يمكنني التحدث عن فرق CoreFX و CLR) لا نستعين بمصادر خارجية لاختبار المنتجات للمجتمع عبر GitHub. نحن نحمل معايير عالية على جودة ما نشحنه.

(أرسل مفتاح الاختصار العرضي الرد قبل أن أنتهي منه ... للمتابعة ...)

chadwackerman ... لدى Microsoft قوائم أخطاء وأولويات مكررة بالكامل داخليًا ...

ليس صحيحًا على الأقل في فرق CoreFX و CoreCLR - GitHub هو قاعدة بيانات الأخطاء الأساسية لجميع NET Core. المنتجات الأخرى غير مفتوحة المصدر (".NET Framework" و .NET Native "الكامل") تستخدم قواعد بيانات الأخطاء الداخلية بشكل أساسي.

chadwackerman ... لن يأخذوا طلب سحب لهذه المشكلة على أي حال ...

لن نتلقى طلب سحب غير قادر على معالجة / شرح جميع المخاوف المذكورة أعلاه (بما في ذلك تلك التي لا يتفق معها الشخص الذي أرسلها شخصيًا). هل هناك مشاريع مفتوحة المصدر تتطلب اختراقًا سريعًا دون التفكير في كل تأثيراتها؟ ربما إذا كان 20٪ + من عملائها على الأرض ... لم يكن هذا هو الحال هنا (حتى الآن).

chadwackerman ... تستخدم Microsoft " تم تسريبه بأدب

أولاً ، لا يعد number_of_comments مقياسًا نولي اهتمامًا له (ما لم يلاحظ شخص ما "يدويًا" أنه يخرج من السقف). وبالتأكيد لا علاقة له "بالتمويل".
نحن نولي اهتمامًا لأي شيء له تأثير على العملاء - سواء عدد الأصوات أو عدم رضا العملاء (على GitHub أو Twitter أو تعليقات منشورات المدونة أو في أي مكان آخر).
حصل هذا الخطأ على راداري باعتباره "استياءًا كبيرًا من العملاء" (قام موظف MS آخر في هذا الموضوع برفع الأمر على هذا النحو داخليًا) ، ولهذا السبب تدخلت.
نحن نمولها بقدر ما نستطيع في هذه اللحظة. ستكون الأولوية الأعلى الوحيدة هي مشكلة الأمان أو 20٪ + من عملائنا على الأرض دون حل بديل.
راجع للشغل: إلقاء الشتائم لن يساعد في تسريعها أو التأثير على عملية صنع القرار.

dluxfordhpf ... يرجى إعلامي إذا كان بإمكاننا مساعدتك في اختبار / تقييم / التحقق من المستندات بحثًا عن الأخطاء المطبعية / كل ما تحتاجه نحن على استعداد للمساعدة ...

شكرا ، نحن نقدر عرضك. سنرحب بالتأكيد بالمساعدة عندما يكون لدينا وحدات بت جاهزة (ويتم التحقق من صحتها في النسخ التي لدينا) ، للتحقق من صحة المزيد من السيناريوهات الشاملة. سنريد تجنب الموقف عندما نصلح فقط بعض السيناريوهات الشاملة ، بينما نترك البعض الآخر معطلاً بنفس الطريقة أو بطريقة أخرى.

jahmai ... لكن

شكر! هذا مثال جيد لتوضيح تأثير القضية على عمل التطوير اليومي الذي نحتاج إلى سماعه وفهمه. يساعدنا ذلك على فهم أن السرد مع أدوات VS يجعل هذا كابوسًا حقيقيًا للعمل معه. سنأخذ ذلك في الاعتبار عند الانتهاء من خطة الإصدار والتواريخ (التي سأبدأ بمجرد أن نتوصل إلى حل).

jahmai ... إذا كانت الحزمة الجديدة لا تدعم HttpClient / HttpClientHandler الأحدث فلن نأخذها ...

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

من فضلك دعنا نجعل المناقشة فنية من الآن فصاعدًا.

تحديث سريع:
الحل [3] يبدو أن " سمات أمان الرش في System.Net.Http " كما هو موضح أعلاه مكلفة (6w +) ، لذلك قمنا بإعادة تنظيم تفاصيل التنفيذ الداخلي: نحن نفكر في استخدام تطبيق Http الأصلي من الإصدار 4.0 من الحزمة + قم بتنفيذ 8 واجهات برمجة تطبيقات جديدة فوقها بأفضل ما يمكن (قد يكون بعضها قد قطع تقنيًا عن الحلول البديلة). لن يتوفر دعم http2 وعناصر "WinHttp stack الجديدة" الأخرى بشكل افتراضي ، أي شخص يريده يحتاج إلى استدعاء مُنشئ خاص (تغيير التغيير تقنيًا ، ولكن نأمل ألا يعتمد الكثير من الأشخاص على الأشياء الجيدة الجديدة 4.1 / 4.3 الموجودة تحت الغطاء) .
يبدو أن التكلفة أقل بشكل ملحوظ حتى الآن ، لكننا ما زلنا نطارد ونحسب 2 خسارة (APIs) ، قبل أن نستقر على الخطة النهائية. سيتعين علينا اتخاذ بعض قرارات التوافق "المثيرة" على الأقل لواجهتي API ، لكن لا ينبغي أن يبطئوا من وقت إصدار الإصلاح.

راجع للشغل: الحل [2] تبين أن " التراجع عن قرار OOB " له تأثير أكبر مما توقعنا في الأصل (على سبيل المثال ، قد يؤدي إلى كسر .NET Standard 1.6 ، مما يؤدي إلى المزيد من الفوضى والتفسيرات على المدى الطويل). نحن نحتفظ بها كخيار الملاذ الأخير في هذه اللحظة ، إذا تبين أن ما سبق باهظ التكلفة أو غير معقول بأي شكل آخر.

إذا كنت تبحث حاليًا عن حالات الحافة حول هذه المشكلة ، فقد يكون من المفيد التحقق منها:
https://github.com/gulbanana/repro-netstandard-httpclient

يوضح هذا الحل أنه حاليًا في vs2017rc ، ينتج عن استخدام netfx و netstandard إصدارات متضاربة من system.net.http. لست متأكدًا من علاقة ذلك بشيء OOB.

أنا أقدر (وأعجب بصراحة) @ Karelz الصراحة هنا ولكني سأقوم

إذا كنت لا تثق في رأي فريق CoreFX (الذي يتمتع بخبرة تزيد عن 10 سنوات مع عملاء .NET) الذي يقول "لا يهتم الأشخاص بالإصدار الرئيسي" ... استنادًا إلى سنوات خبرة فريقنا في خدمة .NET والشحن NuGet الحزم ...

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

نأمل أن نتفق على الأقل على أن عدم الاصطدام برقم الإصدار الرئيسي ووجود تغيير فاصل هو الأسوأ في جميع العوالم. لكن ها نحن ذا. مع الحديث عن "الميزانية" و "أكثر من 6 أسابيع من وقت التطوير" ... للتركيز على بعض السمات. لنظام ثقة عفا عليه الزمن لم ينجح أبدًا ولا أستخدمه. بسبب القضايا المهملة في المترجم.

قامت Amazon Web Services بشحن دعم .NET Core الكامل لجميع خدماتها الصيف الماضي. تحديثهم الأخير يقلل من المستوى القياسي 1.5 إلى 1.3. في هذه الأثناء ، لا يستطيع فريق Azure حتى تشغيل النقاط الصغيرة.

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

شكرا جزيلا على صراحتك وتفسيراتك.

chadwackerman ... لا يمكنك الادعاء بفهم عميق من فريق من ذوي الخبرة

أنت تضع افتراضين كبيرين:

1. الافتراض: تغيير التكسير معروف (يُعرف أيضًا بأنه كسر) قبل الشحن.
   
   
   
   • هذا ليس هو الحال بالنسبة لهذه المشكلة - كما هو شائع بالنسبة لفئة "تغييرات التكسير غير المقصودة". نعم ، تتأرجح الأمور أحيانًا: (. المقاييس المهمة هي IMO: رد فعل سريع (أوافق على أننا لم نفعل ذلك بشكل صحيح بشأن هذه المشكلة حتى الآن) وتقليل / تكرار مثل هذه الأخطاء
   
   
2. الافتراض: خبراء الإصدار قادرون على مراجعة كل تغيير (وهو ليس كذلك) وأن الناس بشكل عام لا يرتكبون أخطاء (خيال علمي).
   
   
   
   • في هذه الحالة بالذات ، تمت مراجعة خطة System.Net.Http API (8 واجهات برمجة تطبيقات جديدة لسطح المكتب) على مستوى عالٍ قبل الشحن أيضًا من قبل خبراء الإصدار. قدموا اقتراحات وتوجيهات بشأن الخيارات. لسوء الحظ ، لم يتم التعرف على مستوى الانهيار مقدمًا من قبل أي شخص (لا خبراء المنطقة ولا خبراء الإصدار) ، وبالتالي فإن الحل المختار يؤدي إلى هذه المشاكل.
   
   

أريد أيضًا أن أشير إلى أنه من خلال رفض تجربتنا في الإصدار ، فأنت تقول أساسًا " إذا ارتكبت (فريق .NET) في أي وقت خطأً كبيرًا (هذا الخطأ) ، فلا يُسمح لك باستدعاء نفسك خبيرًا حتى في التاريخ السابق والعميل أنماط (منطقة ذات صلة) ".
هذه مطرقة IMO كبيرة وليست واقعية. يرتكب الأشخاص / الفرق أخطاء عرضية (مثل هذه). هذا لا يجعلهم غير لائقين ليكونوا خبراء في المناطق المجاورة (أو حتى في منطقة معينة). الشيء الرئيسي هو ما إذا كان بإمكانهم التعلم من أخطائهم والقيام بعمل أفضل في المستقبل.

chadwackerman ... مع الحديث عن "الميزانية" و "أكثر من 6 أسابيع من وقت للتعبير عن بعض الصفات. ...

التكلفة ليست من "صفات الصفعات" ، هذا هو الجزء السهل. الجزء المكلف من السؤال المفتوح في الخيار [3]:

https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198: سؤال مفتوح: هل يمكننا جعل التبعيات الداخلية لـ WebRequestHandler تعمل مع System.Net.Http المستندة إلى WinHttp؟

اتضح أن هذا يتطلب الكثير من العمل ، والاعتمادات الداخلية سيئة للغاية :(

أنا حقا أقدر كل النقاش حول هذا. بجدية. إنه رائع. شكرا لانفتاحك على هذا

في نهاية اليوم ، إليك مشكلة dotnet / corefx # 1: لقد أعدتم يا رفاق كتابة جزء كبير من المكدس. الجزء الأساسي لكل شيء تقريبًا. وليس لديك تغطية اختبار كافية حتى عن بعد. لا ينبغي أن يكون هناك خبراء مطلوبين. كان يجب أن تحتوي على حالة اختبار موثقة بوضوح تمت كتابتها في الوقت الذي تمت فيه كتابة WebRequestHandler (أو تم اتخاذ القرار بعدم النقل إلى Core) ، وكان يجب أن تنكسر عندما بدأت يا رفاق في التعامل معها.

بعد أكثر من 5 سنوات من شحن الأشياء المتعلقة بـ .NET 4.0 ، ليس هناك حقًا أي عذر لعدم وجود تغطية اختبار التكامل في مكان ما من شأنه أن يكتشف ذلك. إذا وجدت نفسك تتذرع بذلك ، فأنت لا تطالب بالتميز من فريقك.

إذا كان هناك:

• تغطية الاختبار المناسبة
• عملية ضمان الجودة المناسبة
• إصدار بيتا مناسب
• وطريقة مناسبة لإرسال المشكلات إلى فرق محددة مسؤولة عن حزم محددة

... هذا ما كان ليحدث.

إذا كان الفريق:

• لم يكن عازمًا جدًا على غليان المحيط بإعادة كتابة كل جانب واحد من .NET في نفس الوقت
• استجابت لتحذيرات أولئك الذين تحدثوا عن هذا الأمر منذ بدء مشروع ".NET 5 / MVC 6"

... هذا ما كان ليحدث.

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

هناك تكلفة _ حقيقية _ و _ مهمة _ لهذا. اضطررنا إلى إغلاق خادم CI منذ أسابيع ونشره يدويًا للتحقق من web.config يدويًا في كل مرة. ننشر على الأقل مرة واحدة في اليوم. مئات الدولارات في الأسبوع لساعات عمل إضافية ، ناهيك عن التأخير الناتج عن الاضطرار إلى قضاء ذلك الوقت في فعل شيء آخر.

مرة أخرى ، هذا لا يأخذ في الاعتبار الساعات التي لا حصر لها في التعامل مع العيوب الموجودة في بنية HttpClient: هذا لا يتخلص من المثيلات بشكل صحيح ، ويبقي اتصالات TCP مفتوحة ، ويخزن إدخالات DNS مؤقتًا لفترة طويلة جدًا.

لذا ، ستلتقط بعض الفلاش لهذا الغرض. ويستحق ذلك.

واستنادًا إلى مدى "تكلفة" الإصلاح ، أتمنى أن تضع فريقًا من فريق النمر مكونًا من العديد من أفضل الأشخاص لديك لإصلاحه بشكل صحيح ، وليس وضعه على أكتاف شخص واحد.

.. الضرب سيستمر حتى تتحسن الروح المعنوية.

دعهم يصلحون الخطأ الذي اعترفوا به ولا يتم تقييدهم بلباقة.

فقط لكي نكون واضحين ، أنا لا أحاول التغلب على حصان ميت من خلال مشاركتي الأخيرة. لكنني رأيت الكثير من الأعذار من Microsoft مؤخرًا. "التسمية صعبة". "الإصدار صعب." "الناس يخطئون." هذه عقلية الضعف وليست عقلية الفريق الذي يسعى للتميز. أنا معجب حقًا @ Karelz لخروجه إلى هنا ومناقشته. ولكن يتعين على أي موظف في MSFT التوقف عن تبرير ما حدث ، والسماح للأشخاص بالتنفيس دون الشعور بالحاجة إلى قضاء الوقت في تصحيح السجل. هذه ليست استثناءات فائقة التطور عند استخدام DateTime أو شيء من هذا القبيل. إنه تأثير هائل بسبب عدم مطالبة أكثر من شخص بالتميز في عملهم ، ويجب التعامل معه على هذا النحو. الرد الصحيح الوحيد هو: "لقد نجحنا. لقد كسرنا .NET. لن نرتاح حتى يتم إصلاحه." لأن هذا كان سيكون الرد قبل 5 سنوات عندما كان جو يدير العرض.

أنا متعاطف مع karelz الذي تولى منصبه مؤخرًا بعد وقت طويل من العمل على .NET. وبالتأكيد لا يجب عليه الدفاع عن فريقه. أنا لا ألوم العمال هنا. من الواضح أنها مشكلة إدارية.

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

في .NET Core ، فقد Microsoft SQL Server القدرة على كتابة القيم غير الموقعة. مرة أخرى ، هناك مشكلة مهملة في الجزء العلوي من مواقع UserVoice التي تعود إلى عام 2014. ولا تتمتع الشركات برفاهية تغيير مخطط قاعدة البيانات الخاصة بهم (خاصةً شيء مضبوط مثل غير الموقعة) لأن مديري برامج لا يمكنهم الوصول إلى نفس الصفحة بعد ثلاثة سنوات. وفي الوقت نفسه ، يعمل كل من Redis و SQLite (مهما كان ذلك) بشكل جيد ، ويقوم Scott Hanselman بإخراج العروض التجريبية كما لو أن هذه الأشياء تعمل بالفعل. من المؤكد أن هناك فجوة آخذة في الاتساع بين الحقائق الداخلية والخارجية هنا وتحتاج القضايا إلى التنفيس (بأدب).

التسمية صعبة. الإصدار صعب. تمتلك Microsoft منظورًا فريدًا ، حيث تتعامل مع العملاء من جميع أنواع الصناعات ، بدءًا من حافة النزيف إلى الكرمة المتعفنة. مفاهيم نهج التطوير التي تبدو "واضحة" في الألعاب أجنبية في أنظمة إدارة علاقات العملاء. كيف تتعامل مع المشاكل ، ما هو مهم وما هو غير مهم ، تختلف. ثم تضيف تقنية متقدمة ، وأساليب مختلفة للمشكلات: DAO vs ADO.NET vs LINQ vs EF لاستخدام مقارنة سهلة مشتركة. أخيرًا ، المنافسة في مجال خادم الإنترنت ، ونماذج الأجهزة الجديدة بالكامل مع الأجهزة اللوحية الجاهزة ، وفيروس Balmer. طرق جديدة تمامًا في التفكير ونمذجة المشكلات ذات القيود والمزايا المختلفة.

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

لقد فاتني خطأ مرة واحدة حيث إذا قمنا بالتثبيت على محرك الأقراص D ، عند إلغاء التثبيت في ظل ظروف معينة ، يمكن للمنتج ... حذف جميع الملفات الموجودة على القرص الصلب. كان علينا حرق 40 ألف دولار من الأقراص المدمجة المضغوطة.

الناس ليسوا مثاليين ونرتكب أخطاء. اللوم ، مع ذلك ، مفهوم عديم الفائدة. يجعلنا نشعر بالقوة من خلال مفاهيم هدامة مثل الخزي والذل. التواضع والمغفرة أقوى. هذه هي الطريقة التي نؤدي بها بشكل أفضل ، ونتعلم طرقًا أفضل ، وأحيانًا ببساطة سبب أهمية شيء ما في المقام الأول.

نعم ، تغضبني المشكلة أيضًا ، لكن يتم إصلاحها. وأنت تعرف ماذا - مشاكل المصدر المفتوح مثل هذه تضعف لعقود قبل أن تزعج حتى المحاولة. ما عليك سوى محاولة Kerberos لنظام Linux أو البحث في GSSAPI. InitializeSecurityContext / AcceptSecurityContext أسهل بكثير. الأمور المالية.

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

كان هذان منتجان مختلفان. NET هو منتج واحد. وأنا لا أحاول إلقاء اللوم على أي شخص. أنا ألوم العملية. يبدو الأمر كما لو أن Microsoft اختارت OSS ، فقد ألقوا بالعمليات التي ساعدتهم على شحن إطار التطوير الأكثر استقرارًا في التاريخ خارج النافذة. أشعر أن هذا كان من الممكن أن يتم اكتشافه إذا تم شحنه في .NET 4.6.3 بدلاً من NuGet.

من المؤكد أن الانتقال الخرقاء إلى برمجيات المصدر المفتوح لا يساعد الأمور. أنا لا ألوم OSS ولكن يبدو أن Microsoft بالتأكيد فخورة بارتكابها كل الأخطاء الواضحة.

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

ضع في اعتبارك فريق BashOnWindows الذي قرر أن يكون لديه مجموعة من الأشخاص ليس لديهم خبرة في نظام Linux يكتبون حزمة مستخدم Linux مباشرة على GitHub. يعد العمل بمثابة علامة اختيار أساسية ولكنها مملة خارج تمرين هندسة الصناديق وليس هناك أي سبب على الإطلاق لإشراك تعليقات المجتمع لتحديد أولويات الميزات. لكنهم ذهبوا بعيدا.

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

عدل للإضافة: صفقة مماثلة مع كارثة باش. شحن البتات المكسورة مباشرة ، روابط غريبة مع مكونات أخرى (يمكن تثبيتها فقط كجزء من Windows Update) ، وبالطبع يقوم سكوت هانسلمان بعمل عروض توضيحية مباشرة على الرغم من حقيقة أنه لا يمكن تشغيل tar ناهيك عن مترجم.

بعض العبارات هنا تنم عن "الأيام الخوالي" لمايكروسوفت ، وهو أمر مثير للسخرية لأن كل التغييرات التي نشهدها الآن هي استجابة مباشرة لطلب العملاء من مايكروسوفت للتطور.

لقد سئمنا من قواعد المصدر المغلق وقواعد الهندسة العكسية الصارمة (إزالة التجميع) ، لذلك حصلنا على مصادر مراجع والآن مفتوحة المصدر.

لقد سئمنا من أخطاء .net Framework التي أثرت على كل تطبيق مثبت على جهاز واستغرق الأمر وقتًا طويلاً لإصلاحه وطلب توزيع المؤسسات وأقسام تكنولوجيا المعلومات لتأهيل كل تحديث لإصدار .net Framework قبل حدوثه ، لذلك نحن الآن نتجه نحو شحن حزم nuget مع تطبيقاتنا حتى نتمكن من دفع الإصلاح بمجرد توفره.

لقد سئمنا من إغلاق Microsoft Connect لكل خطأ آخر باعتباره "يعمل وفقًا لما هو مصمم" أو يستغرق 6 أشهر حتى لجدولة إصدار ، لذلك لدينا الآن مشاريع Github التي تتم إدارتها عن كثب من قبل الفريق الذي يكتب بالفعل الرمز ، وكل يمكن للمجتمع أن يعطي 2c بسهولة على كل عنصر عمل يثيره المجتمع.

لقد سئمنا من قيام Microsoft بأخذ كل فكرة جيدة في المجتمع وعمل نسخة خاصة بها لا تعمل بشكل جيد مع أدوات غير تابعة لـ Microsoft ، لذلك أصبحنا الآن نستخدم NPM و Gulp و NodeJS ، إلخ.

لقد سئمنا من C # فقط كونها قابلة للتطبيق لنظام التشغيل Windows ، ومشاريع مثل Mono تكافح حتى للحفاظ على المساواة ، مع الاضطرار إلى التغلب على الأخطاء أو نقص الوظائف مع #ifdef في كل مكان ، لذلك لدينا الآن Xamarin يدفع تطوير Mono مع مصادر مرجعية ويسمح لنا لترميز أحدث لغة C # ومشاركة نفس قاعدة الشفرة على .net و UWP و iOS و Android و netcore.

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

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

ثلاثة أسابيع ولا تحديث. سنة جديدة سعيدة للجميع.

قم بالتحرير لإضافة هذا الاقتباس من التقليل من

سأقوم بنشر التحديثات (نأمل بمزيد من التفاصيل الفنية) عندما تكون لدينا ، على الأقل على أساس أسبوعي.

chadwackerman بجدية ، هل تفهم أن

ما لهجة؟ لقد أدلى بتصريح له ميزة الدقة ، ثم تمنى للجميع سنة جديدة سعيدة. إذا تعاملت مع الأمر بشكل سلبي ، فهذه هي مشكلتك.

وفيما يتعلق بهذا البيان الأول: هذه مشكلة رئيسية لا تظهر حتى وقت التشغيل. قبل خمس سنوات ، كان لدى ScottGu أو Rob Howard فريق يعمل على مدار الساعة طوال أيام الأسبوع حتى يتم شحن الإصلاح. الآن الأمر مجرد "كما تعلمون ، سنتعامل معه".

أنت تعرف ما الذي يجعل الناس سعداء؟ حل المشكلة. بخلاف ذلك ، هناك بعض العملاء الغاضبين ، وبعضهم موجود في هذا الموضوع. لديهم كل الحق في أن يكونوا غاضبين. لذا ابحث عن شيء آخر لتفعله بسخطك ،pollax. لم تساهم بأي شيء ذي معنى في هذا الموضوع ، ولم يمسحك أحد بشرطة الفكر في GitHub. أنت أيضًا لم تهدر> 5 آلاف دولار من أموال شركتك على هذه المشكلة.

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

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

أتلقى أيضًا تقريرًا عن حدوث ذلك في إطار عمل كامل مع حزمة Exceptionless nuget. أي إصلاحات قوية أو حل بديل؟

أحصل أيضًا على ASP.NET Core للاستضافة الذاتية من خدمة Windows تعمل بإطار كامل 4.6.2. التبعية يجبرني NETStandard.Library 1.6.1 على استخدام System.Net.Http 4.3.0.

التبعية يجبرني NETStandard.Library 1.6.1 على استخدام System.Net.Http 4.3.0.

وهذه أكبر مشكلتي مع هذا الوضع برمته

المزيد والمزيد من الحزم تعتمد على الحزمة الوصفية ، مما يجبرني على ترقية كل تبعية لدي (أو خوض معركة شاقة من تخفيض / تجاهل معينة)

هذا يتعارض مع الوعد السابق بـ "الخلط والمطابقة" بين تبعيات النظام

اضطررت إلى الرجوع إلى إصدار أقدم من نظامي إلى 4.5.2 من 4.6.1 (وفقدان وقت كبير) ، لأن كل حزمة ثانية جلبت .net 1.6 ونظام عربات التي تجرها الدواب System.Net.Http

إذا كانت هذه مجرد حزم تابعة لجهات خارجية ، حسنًا ، فليكن ذلك ، يمكنني الالتفاف عليها ، وإلحاح المشرفين على استخدام المزيد من التبعيات الدقيقة ، ولكن معظم أقسامي كانت من MS ، وأتوقع أن يستخدم MS التبعيات الحبيبية ، وليس فقط صفعة. net 1.6 في ملف nuget

لقد خططت لإرسال تحديث للأيام القليلة الماضية ، لذلك ها هو:

تم منع عمل davidsh لإرسال العلاقات العامة مبكرًا هذا الأسبوع (أي في أي يوم الآن).

فيما يلي تفاصيل حول خطة التنفيذ لدينا والحالة:

خطة رفيعة المستوى:
أ استبدل WinHttpHandler بـ HttpClientHandler في net46 بناء CoreFX
ب. تنفيذ 8 واجهات برمجة تطبيقات جديدة على HttpClientHandler قدمناها في حزمة 4.1.0.0 OOB

خطة التنفيذ:

تحرير 2017/1/12 - تم نقل خطة التنفيذ إلى أعلى مشاركة https://github.com/dotnet/corefx/issues/11100#issue -173058293

niemyjski أي إصلاحات قوية أو

هناك حل بديل لتقليل الحزمة المخالفة إلى 4.0.0.0 (راجع https://github.com/dotnet/corefx/issues/11100#issuecomment-246469893) ، لسوء الحظ وفقًا للتعليقات أعلاه ، فإن أي تعديل على تبعيات NuGet سيعيدها احتياطيًا - وهذا هو السبب الرئيسي وراء كون هذه المشكلة مؤلمة للغاية.

آمل أن يكون هناك بعض التحسين الداخلي لحل هذه المشكلة ؛ سيكون الأمر مزعجًا لنا جميعًا إذا كانت الطريقة الوحيدة التي يمكننا من خلالها الحصول على إصلاحات هي عبر الكلمات النابية.

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

ووت !!!

أحسنت يا شباب Karelz

شكرا للتحديث. سيكون PlatformNotSupported أفضل من لا شيء نظرًا لأنها واجهات برمجة تطبيقات جديدة لا تعتمد عليها البرامج القديمة.

يبدو أنه بعد الإصلاح ، سيظل التوحيد من خلال عمليات إعادة التوجيه الملزمة مطلوبًا ، ولكن إعادة التوجيه إلى التجميع الأحدث بدلاً من التجميع الأقدم ، أي nuget يمكن أن يولد بشكل صحيح؟

الآن بعد أن تم تسجيل الوصول إلى PR dotnet / corefx # 15036 ، يجب أن تختفي هذه المشكلة عبر net46. يستخدم System.Net.Http.dll الآن مكدس HTTP مضمنًا من .NET Framework. هذا يعني أن لديه توافق بنسبة 100٪ مع WebRequestHandler.

يرجى تجربة أحدث الحزم في موجز MyGet dev. ستحتاج إلى استخدام أحدث حزم System.Net.Http.dll التي تم إنشاؤها والتي اعتبارًا من اليوم:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

الإصدار 4.4.0-beta-24913-02.

يمكنك استخدام حزم موجز dev عن طريق تغيير موجز مصدر حزمة NuGet إما باستخدام أدوات سطر الأوامر أو Visual Studio.

تعليمات:

سطر الأوامر:
أضف ما يلي في nuget.config ، أسفلجزء:

<add key="myget.org dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />

استوديو مرئي:
في VS ، Tools-> Options-> Nuget Package Manager-> Package Sources -> Add ، ضمن المصدر ، استخدم عنوان url هذا ، https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

في كلتا الحالتين ، تأكد من إدراج موجز MyGet dev كأول موجز في القائمة.

ولتلخيص الإصلاح في dotnet / corefx # 15036 ، انتهى بنا الأمر مع تطبيق متوافق بنسبة 100٪ مع سطح واجهة برمجة تطبيقات .NET Framework System.Net.Http 4.0 الأصلي وتوافق التطبيق بنسبة 100٪ عند استخدام WebRequestHandler

فيما يتعلق بمستوى الدعم للخصائص الأحدث المضافة إلى HttpClientHandler (التي تعد جزءًا من .NET Core 1.1 وما بعده) ، يلخص ما يلي السلوك المتوقع لهذه الخصائص الجديدة عند التشغيل على هدف 'net46' :

1) قائمة التحقق من شهادة الإلغاء العامة المنطقية
رمى PlatformNotSupportedException

2) شهادات X509CertificateCollection العامة
نفذت

3) وثائق التفويض ICredentials العامة DefaultProxyCredentials
نفذت

4) MaxConnectionsPerServer كثافة العمليات العامة
تم التنفيذ مقابل المنطق الحالي ServicePoint

5) كثافة العمليات العامة MaxResponseHeadersLength
نفذت

6) الهوية العامةالخصائص
نفذت

7) الوظيفة العامةServerCertificateCustomValidationCallback
تم التنفيذ باستثناء أن المعلمة الأولى تكون دائمًا فارغة نظرًا لعدم القدرة الحالية على تعيين HttpWebRequest داخليًا إلى HttpRequestMessage

8) SslProtocols العامة SslProtocols
رمى PlatformNotSupportedException

وو هوو! شكرا يا شباب!

هل حصل أي شخص على فرصة للتحقق من صحة بتاتdavidsh ؟ نرحب حقًا ببعض التحقق الشامل من السيناريوهات السبعة التي تم التلميح إليها في هذا الموضوع.

تمكنا من التحقق من صحة repro المبسط onovotny حتى الآن. سيكون من الرائع الحصول على مزيد من التأكيدات على repros ليس لدينا محليًا. شكر!

بمجرد أن نحصل على ذلك ، سوف نتحرك نحو نقل التغيير إلى فرع 1.1 وإصدار تصحيح - نأمل الأسبوع المقبل.

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

تضمين التغريدة نقدر مساعدتكم.

لقد قمت للتو بتثبيت 4.4.0-beta-24913-02 في مشروعي. يبدو أنه يساعد حالتي.

الحالة: استضافة ASP.NET Core ذاتيًا من خدمة Windows تعمل بإطار كامل 4.6.2. التبعية يجبرني NETStandard.Library 1.6.1 على استخدام System.Net.Http 4.3.0.

موجز myget بطيء جدًا في تجربتي. استغرق تثبيت System.Net.Http 4.4.0-beta-24913-02 بضع دقائق
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 82079ms
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 93813ms

شكرا لك @ annemartijn0 للتأكيد

تستغرق هذه الصفحة حاليًا خمس إلى سبع دقائق لإرجاع نتيجة:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

لماذا تقوم Microsoft بالاستعانة بمصادر خارجية للبنية التحتية الحيوية لهذه الشركات الصغيرة المشبوهة والمواقع الصغيرة الغبية؟ أنت تختار حقًا تثبيت عملك وعملي على شركة في بلجيكا تسمى Tech Tomato؟

على أي حال ... كان لدي بالفعل موجز myget ولكنه لم يسحب هذه المكتبة حتى بعد إعادة تشغيل Visual Studio ، قمت بالنقر فوق الزر "تحديث" المدفون في مربع حوار في مكان ما ، ثم أعد تشغيل Visual Studio مرة أخرى. أنا أكتب هذا حاليًا بينما يحاول Visual Studio 2015 استعادة الحزم الخاصة بي.

تحديث: لا يزال Visual Studio متماوجًا ولكن ظهر تحديث صفحة myget أخيرًا. يعرض ربما عشرات التنزيلات في اليوم لهذا الإصدار من المكتبة. وفي الوقت نفسه ، يلخصه Visual Studio بأنه "System.Net.Http - 75.8K تنزيل." لقد افترضت دائمًا أن هذه الإحصائيات كانت تخبرني بالشيء الخطأ ، لكن إليك مثال رائع على سبب عدم هذا ما أريده. على الأقل ، يرجى إخباري بحالة الإصدار الحالي مقابل الملخص حتى لا أصبح أحد مختبري ألفا عن غير قصد دون أن أختار صراحة الجنون خلال هذه اللحظة السخيفة في تاريخ .NET.

بعد 5 ساعات وما زلت غير قادر على تجربة هذا التصحيح:

Attempting to gather dependency information for package 'System.Net.Http.4.4.0-beta-24913-02'
with respect to project '...', targeting '.NETFramework,Version=v4.6.1'

بعد خمس دقائق...

Package 'System.Net.Http 4.4.0-beta-24913-02' is not found in the following primary source(s):
'https://dotnet.myget.org/F/dotnet-core/api/v3/index.json'. Please verify all your online package
sources are available (OR) package id, version are specified correctly.

NET هو حريق الإطارات.

سهل هناك chadwackerman . لقد _ اخترت في_ خلاصة بيتا / ألفا / غير الإنتاج الخاصة بهم ، وهذا يعني أنك على استعداد لاستثناء المشاكل ، وما إلى ذلك. ومع ذلك ، كنت أستخدم myget للأعمار الآن (اشتراك مدفوع) ولدي مشكلات قليلة جدًا مع عليه. ربما .. فقط ربما .. قد يكون جهاز الكمبيوتر / اتصال الشبكة / أيا كان؟ (لقد حققت بعض المكاسب الكبيرة الحقيقية باستخدام MyGet خلال آخر 12 شهرًا أو أكثر).

NET ليس حريق إطارات ، الآن. بالتأكيد ، هناك الكثير من الجبن يتحرك وهناك الكثير من الأجزاء المتحركة والأشياء التي يمكن (وتحدث) أن تسوء. ولكن هناك عددًا هائلاً من الأشخاص يقومون بأشياء رائعة مع إطلاق وحدات بت RC و RTM. أنا شخصياً قررت استخدام إصدارات عامة فقط - ولا حتى BETA أو RC بعد الآن. لذا فإن توقعاتي هي: مشاكل أقل ولكن يجب أن تنتظر لفترة أطول. لذا ، إذا وجدت بعض هذه الأشياء محبطة حقًا بالنسبة لك - فربما تنتظر لفترة أطول قليلاً حتى تصل بعض أعمال التطوير هذه إلى حالة RTM.

لقد كان العمل الذي قام به فريق corefx (والآخرون في عالم .NET-core) رائعًا وترحيبًا ممتازًا فيما يتعلق بالاستمرار في github / open-and-transparent ، مقارنةً بـ bad-ole-Balmer-day ، لذا دعنا الكل يحاول أن يظل إيجابيًا ومفيدًا للقائمين على صيانة الريبو. الجميع هنا بشر وكلهم يحاولون فقط جعل العالم مكانًا أفضل: بايت واحد في كل مرة.

chadwackerman يبدو أن معاناة myget feed الآن. لست متأكدًا بنسبة 100٪ من كيفية عمل myget ، ولكن أعتقد أنه إذا كان لديك مضيف مخصص ("dotnet.myget.org") ، فإن الخلاصات مستأجرة بالفعل ولها حدود QOS.

يُظهر الانتقال إلى هنا وجود الحزمة ، ولكن الأمر يستغرق بعض الوقت للظهور: https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

PureKrome ، أنا مدير تطوير سابق في Microsoft طُلب منه التحقق من هذا

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

chadwackerman أستطيع أن أفهم
تم تأسيس / تشغيل Tech Tomato بواسطة أفراد مؤهلين: maartenba ، xavierdecoster ، موظف MS الحالي ؛ في بلد (وأنا متحيز له) يشجع الابتكار. لا يكاد اسم الشركة وثيق الصلة بالموضوع وأن تأسيس الشركة في بلجيكا يظهر أن فريق .NET Core يتطلع إلى ما وراء Redmond، WA للبحث عن حلول.
إنني أتطلع إلى مساهماتكم البناءة للمساعدة في حل هذه المشكلة.

تم تحرير المحتوى من قبل المشرف

تم تقديم تقرير مدونة قواعد السلوك مقابل بعض التعليقات الواردة في سلسلة الرسائل هذه ، ونتيجة لذلك قمنا بإزالة بعض المواد التي يُعتقد أنها تنتهك هذه المدونة. إذا كان لديك أي أسئلة أو مخاوف بشأن ذلك ، فيرجى إرسال بريد إلكتروني [email protected].

chadwackerman إن وظيفتك السابقة في الشركة لا

مرحبًا يا رفاق - أراد مارتن من .NET Foundation هنا شرح ذلك .

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

في غضون ذلك ، يرجى الحفاظ على النبرة الاحترافية والامتناع عن الإدلاء بأي تعليقات يمكن اعتبارها هجومًا شخصيًا على الآخرين. لقد كنت خفيفًا بشكل متعمد على التعديلات التي تم إجراؤها لأنني أردت الحفاظ على بعض من قوة الشعور وعدم الإفراط في تعقيم الأشياء ، ولكن يرجى الحفاظ على الأمور متحضرة.

هل حاول أي شخص آخر الاتصال بـ Tech Tomato؟ لا يوجد رد على استفساراتي.

إليك ما سيبدو عليه الأمر إذا حاولت القيام بعمل فعلي لفرز تحذيرات إنشاء غريبة بعد إضافة الخلاصة:

Attempting to gather dependency information for package
'System.Net.Http.4.4.0-beta-24913-02' targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 1.55 min

Attempting to gather dependency information for package 
'Microsoft.Extensions.Configuration.Json.1.1.0' targeting '.NETFramework,Version=v4.6.1' 
Gathering dependency information took 2.2 min

... وهلم جرا.

ولا يزال هذا الرابط يستغرق أكثر من 5 دقائق لإظهار الصفحة:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

أن هذا أ) لم يتم إصلاحه بعد ب) تم تجاهله من قبل المجتمع وج) تم التغاضي عنه من قبل فريق .NET كجزء من التطوير اليومي يعمل على تعزيز العيوب الواضحة في العملية والأدوات والثقافة والإدارة التي أدت إلى هذا الخطأ تبدأ بـ - بالإضافة إلى الخطأ نفسه الذي تم تجاهله لعدة أشهر حتى قمت شخصيًا بتصعيده داخليًا.

أنا أتطلع إلى ما بعد الوفاة وعد @ Karelz .

مرحبا تشاد ،

وقت تحميل هذه الصفحة هو شيء ننظر إليه. وقت استعادة NuGet ليس طبيعيا. إذا أمكن ، هل يمكنك التواصل معنا (MyGet) عبر الدعم في MyGet.org مع ذكر إصدار NuGet.exe قيد الاستخدام بالإضافة إلى التتبع مع تمكين مفتاح -Verbosity المفصل؟ سيساعدنا هذا بالتأكيد في تحديد أي مشكلات تتعلق بالأداء.

شكر!

إصدار مضيف وحدة تحكم مدير الحزم 3.5.0.1996

سأبحث في الحصول على السجلات من سطر الأوامر حيث ينتقل Visual Studio من الصخور الصلبة إلى غير المستقرة بمجرد إضافة موجز myget.org. وبمجرد حدوث خطأ في سحب حزمة ، ينقلب الأمر برمته.

ملاحظة @ karelz : حريق الإطارات.

هل يمكنك تجربة سطر الأوامر هذا باستخدام أحدث إصدار من NuGet.exe (ليلاً) من

الأمر الدقيق: تثبيت NuGet.exe System.Net.Http -Version 4.4.0-beta-24913-02 -الخطورة مفصلة

يجب أن ينتج عن هذا جميع إجراءات التنزيل الوسيطة أيضًا. شكر!

maartenba :

على الرابط الذي أرسلته ، تشير كلمة "الأحدث" إلى https://dist.nuget.org/win-x86-commandline/latest/nuget.exe. هذا هو الإصدار الذي أملكه بالفعل ، لذلك لا أعتقد أن هذا هو الإصدار الليلي.

لقد قمت بتنزيل الحزمة الليلية NuGet.CommandLine.4.0.0-rtm-2254.nupkg ، وقمت بتثبيت nuget.exe عليها ، وفشلت في محاولة سحب الملفات من myget.org. لمعلوماتك: 1.5 ثانية لإرجاع 404 من dotnet.myget.org.

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

ما زلت سعيدًا بالمساعدة ولكن ... واو. يجب أن تتحرك الأشياء حقًا في اتجاه البساطة ، وليس لي استكشاف أخطاء مضيف الحزمة الثانوية لمضيف الحزمة الأساسي باستخدام قطرة ليلية من مدير الحزم ، على الرغم من وجوده في الإصدار 4.0.0-rtm ، إلا أنه يحتوي بطريقة ما على خمس طرق يدوية متميزة لـ تحديث نفسها على صفحة التوزيع الخاصة به ، وكل منها يتطلب تدخل المستخدم اليدوي.

ملاحظة @ karelz ... أوه ، لا تهتم. :)

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

لقد لاحظت بنفسي أن myget.org بطيء جدًا ، لكنني تمكنت من تثبيت الحزمة المعنية بنجاح في وقت "معقول" (على شبكة Wi-Fi العامة).

OK https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms
Installing System.Net.Http 4.4.0-beta-24913-02.

يجب أن ننظر بالتأكيد إلى بطء myget.org العام ، ولكن ربما يكون خارج نطاق هذه المشكلة - فهو ليس سيناريو عميل نموذجي بعد كل شيء. maartenba أين هو أفضل مكان لمناقشة ذلك؟
هنا (حول هذه المشكلة تحديدًا) ، دعنا نركز على كيفية إلغاء حظر التحقق الشامل ، على سبيل المثال باستخدام بعض الحلول الإبداعية.
أتساءل أيضًا عما إذا تم حظر الأشخاص الآخرين بشكل سيء مثل chadwackerman ، أو ما إذا كانت تجربة chadwackerman سيئة للغاية ، مقارنة بالآخرين.

chadwackerman بالنظر إلى أن الهدف الرئيسي هنا هو التحقق من صحة السيناريو من طرف إلى طرف ، أتساءل عما إذا كان بإمكانك تقديم خطوات السيناريو الخاصة بك؟ يمكن لأي شخص آخر هنا (لم يتم حظره بشدة من خلال استخدام myget.org كما أنت) إنهاء التحقق في مثل هذه الحالة. يجب أن يقلل ذلك من الألم ويضيع الوقت على جانبك. بالطبع ، بافتراض أن ذلك ممكن وقابل للتنفيذ بثمن بخس من جانبك.

البديل الأخير الذي أرغب في تجنبه هو تخطي التحقق من صحة السيناريو بالكامل - إذا حصلنا على عدد قليل من السيناريوهات الأخرى التي تم التحقق من صحتها ، فقد نكون على ما يرام (بافتراض أسوأ سيناريو حيث maartenba لن يكون قادرًا على تحرّي الخلل وإصلاحه في تجربة myget.org فائقة السوء :().

karelz مع عدم الاتصال بالإنترنت مع تشاد ، سنقدم تقريرًا هنا بمجرد اكتشاف ما يحدث.

حقائق أساسية:

• يتم استخدام موجز myget.org بواسطة الإصدارات اليومية ، و CI ، و dev-workflow ، وما إلى ذلك ، لذلك يتم التعامل معها كثيرًا على أساس يومي. لا تظهر أي من مشكلات الأداء هذه في تلك السيناريوهات (عندما فعلوا ذلك في الماضي ، تصرفنا وفقًا لها ، لأنها أثرت على سير عمل مطورينا - لقد جلبنا 30-60 دقيقة من أوقات المزامنة إلى أقل من 5 دقائق في الأشهر القليلة الماضية). ما أفهمه هو أنه من النادر لأي شخص في فريق .NET أو في المجتمع أن يستخدم موجز myget في VS - وهو ما يشرح IMO سبب عدم ملاحظة الأداء السيئ في هذا السيناريو.
• تم تصعيد هذه المشكلة إلي من قبل زميل في العمل في هذا الموضوع في 2016/12/9 - ولهذا انضممت إلى المناقشة هنا. لست على علم بأي تصعيد داخلي آخر. نظرًا لأنني أدفع هذه المشكلة باستمرار داخليًا عبر فرق متعددة (تقريبًا على أساس يومي) ، أعتقد أنني على دراية بجميع الأحداث المتعلقة بهذه المشكلة.

karelz نعم ، لقد تم تصعيد هذا من خلال الاتصالات الداخلية في نفس التاريخ 2016/12/9. سأقدم التفاصيل ورسائل البريد الإلكتروني والمشاريع التي أعمل عليها بشكل خاص بعد تشريح الجثة ويمكننا إنهاء هذا في وضع عدم الاتصال. ربما شخصيًا ، ربما باستخدام الكحول.

لقد تحققت منذ ذلك الحين من أن MyGet.org يسيء التصرف من أجهزة العديد من الأصدقاء على السواحل الشرقية والغربية. المنجم هو تثبيت نظيف حديث لبرنامج Visual Studio 2015 ، بدون وظائف إضافية ، بالتأكيد لا يوجد ReSharper. ملاحظات المستخدم ومعالجة الأخطاء في Visual Studio ضعيفة. حتى هنا ، أبلغ المستخدمون الآخرون عن فترات تأخير مماثلة. سأقوم بإسقاط هذا الآن لتحرير الخيط ولكن دعونا لا نتظاهر بأن MyGet غير مفصول وأن نظام تغليف NuGet بالكامل (وقدرة NuGet على تحديث نفسه) لا يشم رائحة المطاط المحترق وهو ليس كذلك عامل مساهم في هذا الخطأ. كلاهما في الأصل كجزء من السبب الجذري وحتى اليوم كجزء من محاولة اختبار وشحن الإصلاح.

لست متأكدًا مما إذا كان يجب علينا مواصلة مناقشة هذا في هذا الموضوع أو فتح موضوع آخر له. على أي حال: تقرير الحالة!

نحن على اتصال بـ chadwackerman عبر البريد الإلكتروني - شكرًا تشاد على السجل الذي أرسلته!

حول "البطء" - يخبرنا التنميط الأولي أن هذا ناتج عن عدد إصدارات الحزمة وتأثير هذه الحقيقة على حجم تنزيل بيانات البروتوكول. على سبيل المثال ، تتطلب بعض الحزم تنزيل 4 ميغابايت من بيانات JSON وتحليلها لجمع البيانات الوصفية. يؤدي هذا إلى ارتفاع كبير في استخدام الذاكرة في عميل NuGet والحاجة إلى تحليل حمولة القارب لبيانات JSON - بالتأكيد هناك مجال للتحسين على الرغم من أن 4.0.0 nightlies للعميل يبدو أنها تتصرف بشكل أفضل.

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

نحن نتطلع أيضًا إلى تسريع وقت تحميل هذه الصفحة (ولكن هذا ثانوي ، فالتثبيت / الاستعادة السريع هو الأولوية).

بعد ساعات من التجربة ، تمكنت من الترقية إلى System.Net.Http 4.4.0-beta-24913-01 دون تعطل Visual Studio. ثم حاولت الترقية من 24913-01 إلى 24913-02 وحصلت على خطأ مناسب بدلاً من حدوث عطل.

إنه عام 2017 ، ويستغرق تحديث البنية الليلية لمكون HTTP الأساسي للنظام بأكمله من "إصدار الاثنين" إلى "إصدار الثلاثاء" أكثر من خمس دقائق من وقت ساعة الحائط على معالج 8-Core i7 ويتطلب أكثر من 4 جيجابايت من ذاكرة الوصول العشوائي.

المشروع المعني هو webjob (تطبيق سطر أوامر معاد تسميته) يتكون من 27 سطرًا من التعليمات البرمجية.

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

تمكنت من تثبيت الحزمة المعنية بنجاح في وقت "معقول" (على شبكة Wi-Fi العامة).
https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms

إليك بعض الحقائق البديلة:

محاولة جمع معلومات التبعية للحزمة 'System.Net.Http.4.4.0-beta-24913-02' فيما يتعلق بمشروع 'webjob' ، باستهداف '.NETFramework، Version = v4.6.1'
استغرق جمع معلومات التبعية 4.22 دقيقة
محاولة حل التبعيات للحزمة 'System.Net.Http.4.4.0-beta-24913-02' مع DependencyBehavior 'Lowest'
حل إجراءات تثبيت الحزمة "System.Net.Http.4.4.0-beta-24913-02"
تم حل الإجراءات لتثبيت الحزمة "System.Net.Http.4.4.0-beta-24913-02"
System.OutOfMemoryException: تم طرح استثناء من النوع "System.OutOfMemoryException".
في Newtonsoft.Json.Linq.JContainer.ReadContentFrom (JsonReader r)
في Newtonsoft.Json.Linq.JContainer.ReadTokenFrom (قارئ JsonReader)
في Newtonsoft.Json.Linq.JObject.Load (قارئ JsonReader)
في NuGet.Protocol.HttpSource. <> ج.b__15_0 (تيار تيار)

نعم ، هل يمكنكم يا رفاق نقل مشكلة MyGet / NuGet هذه إلى إصدار جديد؟ ليس له علاقة بالقضية الأصلية.

onovotny - قد تفكر في إعادة فتح مشكلتك إلى. أصبحت هذه المشكلة الآن طويلة جدًا ، لذا تم تقليل قابلية استخدام المشكلة.

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

اختبر جميع السيناريوهات السبع من طرف إلى طرف التي أبلغ عنها المجتمع (اطلب المساعدة من المجتمع ، وقدم خطوات لاستهلاك الحزم الرئيسية على myget)

ما هي السيناريوهات السبعة؟ هل يمكن للجميع المساعدة؟

richlander ، يسعدني إعادة فتح مشكلة ، هل تبحث عني فقط لاستنساخ هذه المشكلة باستخدام تحديثات

كانت قاعدة الاستخدام الخاصة بي تعمل مع Azure Storage API ، والتي كانت تعمل آخر مرة في 4.0.1-rc2-24027. يبدو أن هذا يعمل الآن. لقد أجريت اختبارًا سريعًا فقط ، حيث استغرق الأمر حوالي 20 دقيقة لتحديث جميع الحزم في مشاريعي من MyGet.

onovotny لا تعيد فتحه. لدينا زخم هنا ونحن على بعد بوصات من دقة جزئية على الأقل. الموضوع مربك لأي شخص ينضم الآن ، ولكن مثل أي مشكلة أخرى لم يتم حلها منذ فترة طويلة وتكشف عن مشكلات أعمق ، يجب أن تكون كذلك. تمتص GitHub لأشياء مثل هذا.

لقد تحققت من أن النظام الثنائي الجديد يعمل بشكل متوافق على تطبيق محلي واحد. لا عجب هناك. حاولت بعد ذلك قص تلك التبعيات ولصقها في مشروع webjob الخاص بي ولم أتمكن من تشغيله على Azure. يتم تحميل Webjob بشكل جيد ولكنه يفشل عند تشغيله ، غير قادر على تحميل System.Net.Http. من الواضح أن هذا خطأي وأنا أعرف التدريبات لإصلاحها. لكنني عدت كثيرًا إلى حيث كنت عندما تم فتح هذا الخطأ لأول مرة: إعادة رسم خرائط ملزمة مضغوطة وعندما أتطرق إلى NuGet ينفصل كل الجحيم ، أضيع قدرًا هائلاً من الوقت ، ويجتاز مشروعي جميع الاختبارات محليًا ولكنه ينقطع في وقت التشغيل عند النشر .

إذن سيناريوهاتنا هي:

1. تستخدم الحزمة التابعة (Raven.Database) WebRequestHandler ، والتي كانت تتعطل في وقت التشغيل كما ورد في هذه المشكلة.
2. يستخدم الكود الخاص بنا نوع HttpClientHandler الجديد وخصائصه.

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

لقد قمت بالتحديث إلى الإصدار التجريبي وأزلت جميع أكواد الاختراق ، ويبدو أن كل شيء (تطبيقنا ، من البداية إلى النهاية ، من المتصفح إلى قاعدة البيانات) يعمل محليًا! لم أجرب الكود على منصة Azure حتى الآن ، لذا سأؤكد مرة أخرى بمجرد الانتهاء من ذلك ، لكنني أعتبر هذا تقدمًا كبيرًا.

أيضًا ، عند تحديث الحزم ، وجدت أنه من المقبول استخدام Visual Studio Package Manager Console واستخدام هذا الأمر لتحديث الحزم (بدلاً من إضافة تكوين موجز آخر ثم استخدام واجهة المستخدم ، وهو أمر مؤلم بشكل لا يصدق):

Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core

استغرق هذا 6 دقائق و 53 ثانية لتحديث 20 مشروعًا.

لاحظ أن جميع مشاريعنا تحتوي على إعادة توجيه الربط التالية التي تم إنشاؤها تلقائيًا ، ولم أكن بحاجة إلى العبث بعمليات إعادة التوجيه الملزمة على الإطلاق:

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
      </dependentAssembly>
    </assemblyBinding>

حان الوقت تقريبا لطفولة الخمسات!

jahmai عندما استخدمت سطر الأوامر هذا ، لم يقم بتحديث المرجع الخاص بي من 4.0 إلى 4.2 ولم يضيف إشارات النسخ الضرورية. تأكد من تعيينها لـ System.Net.Http والتبعيات ويجب أن تعمل بشكل جيد على Azure.

السيناريو الخاص بنا هو اعتماد مباشر على الأنواع في System.Net.Http.
لقد اختبرت Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core في مشروع واحد ويبدو أنه يعمل بشكل جيد حتى الآن. هذه أخبار جيدة جدًا.
تحديث نسيت أن أذكر أنه تم تطبيق عمليات إعادة توجيه الربط من 4.0.0.0 إلى 4.2.0.0 تلقائيًا.

فيما يتعلق بقضايا Nuget / MyGet ، حصلت على المخرجات التالية لهذا المشروع الفردي:

استغرق جمع معلومات التبعية 37.47 ثانية
استغرق تنفيذ إجراءات nuget 35.15 ثانية
الوقت المنقضي: 00: 01: 14.7537429

لاحظ أنني في المنطقة الزمنية UTC +01: 00 ، لا أعرف متى تحصل MyGet على أكبر عدد من الزيارات.

pollax شكرا. وجدنا المشكلة (انظر تعليقي الأخير أعلاه) - تركيبة العميل + الخادم. العمل على جعله أفضل.

يمكنني التأكد من استخدام مكتبة بيتا System.Net.Http من MyGet مع السيناريو الخاص بي:

• .NET 4.6 تطبيق وحدة التحكم مع تبعية مكتبة تستخدم System.Net.Http

استغرق الأمر حوالي 90 ثانية لتنزيل حزمة nuget من MyGet وتم تطبيق رابط إعادة التوجيه في app.config بشكل صحيح.

يسعدني المساعدة في اختبار المزيد من السيناريوهات إذا تم وصفها في مكان ما.

أثر جانبي مثير للاهتمام: أدت إضافة الإصدار التجريبي 4.4.0 من مكتبة .NET الخاصة بنظام التشغيل Windows فقط إلى تعطيل نشر تطبيق .NET Core على Linux.

يتم ترميز "استعادة النقاط" بشكل ثابت حتى 60 ثانية من مرات استرجاع الحزم. وليس هناك علم لتحديد نظام أساسي معين فقط مثل دعم "dotnet publish". لذلك بالنسبة لمكتبة تعمل عبر الأنظمة الأساسية ، تقوم عقدة عامل Linux الصغيرة الخاصة بك بتنزيل مجموعة من ثنائيات Windows دون داع - ثم تنتهي المهلة وتفشل عندما تصل إلى MyGet. من الممتع أن مشكلة نفاد الذاكرة التي تعطل Visual Studio على جهاز 32 جيجا بايت لا تؤثر على عامل Linux 0.75 جيجا بايت لأنه يتم تبديله حتى الموت بدلاً من ذلك.

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

شكرا للجميع لمساعدتنا في التحقق من السيناريوهات! لقد تلقينا حتى الآن 5 تأكيدات - انظر القائمة التفصيلية التي تحتوي على روابط في أعلى منشور. أنا أعتبرها جيدة بما يكفي للتحقق من الصحة للانتقال إلى المراحل التالية.

• [4.a.ii] ما زلت أطارد تحليل NuGet.
• [ 5.a ] سأطلب من

• [5.b] أقوم بالتحضير لعملية الإصدار (نحتاج إلى موافقة على مستوى المدير ، ولكن نظرًا للتأثير على العملاء ، لا أتوقع أي معارضة).

• أقوم بإعداد معلومات رسمية حول إصدار التصحيح - حيث يتم سرد جميع التغييرات التقنية والحلول البديلة (بفضل davidsh للحصول على البيانات).

إذا اكتشف أي شخص أي مخاوف في هذه الأثناء (تتعلق بهذه المشكلة المحددة) ، يرجى ذكر ذلك في أسرع وقت ممكن. تشابك الاصابع.

onovotny - يبدو أن المشكلة تتقدم الآن إلى الأمام ، لذا دعنا نواصل هذه المشكلة. إنه لأمر رائع أن نرى الناس يحرزون تقدمًا إيجابيًا.

karelz يمكنك التحقق من السيناريوهات الخاصة بي التي تتضمن 4.6 سطر أوامر (Azure webjob) مع تبعية ServiceBus وتطبيق 4.6 مع تبعيات على Azure Batch. أيضًا تطبيق ثالث له تبعيات على AWS و Dropbox والذي انتقلت إليه سابقًا إلى .NET Core فقط للابتعاد عن هذه المشكلة (لقد سحبت إصدارًا قديمًا لاختباره اليوم).

DOTNET استعادة مشكلة أحيت في https://github.com/NuGet/Home/issues/2534 ، مساهم العهد الثابتة باكشانيل، إطارات بدأت في https://github.com/Azure/azure-storage-net/issues/372 ، MyGet تم إرسال السجلات ، وطلبت سجلات أداء إضافية على https://github.com/dotnet/cli/issues/5328 ، واشتريت كيسًا ضخمًا من الفشار لمناقشة ما بعد الوفاة.

شكرًا لك chadwackerman على مساعدتك
لقد قمت بتحديث أعلى وظيفة.

من قائمتي أعلاه:

أقوم بإعداد معلومات رسمية حول إصدار التصحيح - حيث يتم سرد جميع التغييرات التقنية والحلول البديلة (بفضل davidsh للحصول على البيانات).

لقد أضفت معلومات إلى أعلى مشاركة - راجع قسم "تأثير التغيير - كسر التغييرات" للحصول على قائمة بالتغييرات العاجلة التقنية (4) ، لكل منها حل بديل.

تأثرت مكتبات NuGet بالتغيير التقني (الموصوف في أعلى المنشورات) - لحسن الحظ "فقط" 4 مكتبات NuGet تستخدم أيًا من واجهات برمجة التطبيقات الجديدة هذه:

System.Private.ServiceModel_4.3.0

• https://www.nuget.org/packages/System.Private.ServiceModel/
• المؤلف: dotnetframework
• التنزيلات: 11 ألف (أحدث إصدار) / 800 ألف (إجمالي)
• الوصف: حزمة التنفيذ الداخلي غير مخصصة للاستهلاك المباشر. من فضلك لا تشير مباشرة. يوفر تنفيذ حزم System.ServiceModel.
• ملاحظات:
• الحالة: الحزمة لم تتأثر - أكد zhenlanmconnew من فريق WCF أنهم يستخدمون الخصائص فقط في

القنصل_0.7.2.1

• https://www.nuget.org/packages/Consul/
• الاسم: القنصل
• المؤلف: https://www.nuget.org/profiles/highlyunavailable
• التنزيلات: 500 (أحدث إصدار) / 65 ألف (إجمالي)
• الوصف: https://github.com/PlayFab/consuldotnet/blob/master/CHANGELOG.md
• ملاحظات:
  
  
  
  • 2 الاستخدامات: https://github.com/PlayFab/consuldotnet/search؟utf8=٪E2٪9C٪93&q=ServerCertificateCustomValidationCallback
  
  
  • تم حفظ المشكلة على GitHub: https://github.com/PlayFab/consuldotnet/issues/79
  
  
  • تم إرسال بريد إلكتروني للمؤلف عبر nuget.org
  
  
• الحالة: الحزمة لم تتأثر (مشكلة GitHub https://github.com/PlayFab/consuldotnet/issues/79 مغلقة)

Octopus.Client_4.6.1

• https://www.nuget.org/packages/Octopus.Client/
• مؤلف:
  
  
  
  • https://www.nuget.org/profiles/paulstovell
  
  
  • https://www.nuget.org/profiles/OctopusDeploy
  
  
• التنزيلات: 250 (أحدث إصدار) / 55 ألف (إجمالي)
• الوصف: لا شيء
• ملاحظات:
  
  
  
  • تم حفظ المشكلة على GitHub: https://github.com/OctopusDeploy/OctopusClients/issues/121
  
  
  • تم إرسال البريد الإلكتروني لدعم الاسم المستعار: [email protected]
  
  
  • تم إرسال البريد الإلكتروني إلى المؤلف (المؤلفين) عبر nugget.org
  
  
• الحالة: الحزمة لم تتأثر (التفاصيل في مشكلة GitHub https://github.com/OctopusDeploy/OctopusClients/issues/121)

علامة جغرافية. Checkmate.ObjectModel_5.7.1701

• https://www.nuget.org/packages/Geotab.Checkmate.ObjectModel/
• الاسم: Geotab SDK
• المؤلف: https://www.nuget.org/profiles/neilcawse
• التنزيلات: 150 (أحدث إصدار) / 10 آلاف (إجمالي)
• وصف:
  
  
  
  • مكتبة SDK للوصول إلى قواعد بيانات العملاء MyGeotab
  
  
  • شاهد قائمة التغييرات الكاملة على https://my.geotab.com/sdk/default.html#/whatsNew
  
  
• ملاحظات:
  
  
  
  • تم إرسال بريد إلكتروني للمؤلف (geotab.com CEO) عبر nugget.org
  
  
• الحالة: تم الاتصال بالمالك ، في انتظار الرد

آسف للإزعاج لجميع مؤلفي الحزم المتأثرين.

في تعطل / تبديل Visual Studio / NuGet على Linux: السبب في ذلك هو الطريقة التي يعمل بها بروتوكول NuGet. لقد وثقت النتائج في هذه المشكلة: https://github.com/NuGet/Home/issues/4448

على جانب MyGet ، سنقوم بنشر تغيير بعد عطلة نهاية الأسبوع (حاليًا قيد الاختبار ، ETA في الإنتاج يوم الاثنين 7 فبراير) الذي يخفف من جانب الخادم هذا.

الإصلاح على جانب MyGet مباشر. يجب أن تعمل بشكل جيد في Visual Studio. عند استخدام NuGet.exe ، تأكد من استخدام NuGet.exe المضمن في https://dotnet.myget.org/F/nuget-build/api/v2/package/NuGet.CommandLine (4.0 ليلاً) - 3.5 يبدو أن https://github.com/NuGet/Home/issues/4512

شكرًا على الغوص العميق في هذاmaartenba. لا تقلل أبدًا من التأثير الذي يمكن أن يحدثه حتى إصلاح الأدوات البسيط!

من المثير للاهتمام أن فريق .NET بأكمله قد يفقد كلاً من تعطل Visual Studio ومشكلة NuGet.

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

لأشهر لم يتمكن أحد من تحديد نقطة توقف. على منصتين لا يمكنك حتى الحصول على تتبع مكدس! تم استدعائي إلى معمل الإنشاء في الساعة الواحدة صباحًا لأنني الشخص الوحيد الآخر الموجود بالجوار ، أحصل على شاشة مليئة بالتجميع لمعالج لم أرَ مستندات له من قبل ، وسحب تتبعًا خلفيًا ويتعطل مصحح الأخطاء في مصحح الأخطاء.

عندما تقوم بتغيير تنسيق المشروع أثناء قيامك بتغيير الرمز الذي يوزع تنسيق المشروع أثناء قيامك بتجربة إصدار جديد من مدير الحزم الذي يتم توصيله بالإصدار الجديد من Visual Studio - أشياء مثل هذه النتائج. يمكن للبشر فقط التعامل مع الكثير من التغيير مرة واحدة وهذا هو السبب في أن المطورين يواصلون إسقاط الكرة في كل مكان. كلا منا وهم!

إذا كان شخص ما يريد نص برمجي بوويرشيل بسيط لإصلاح الربط ، فأعد التوجيه في جميع app.config هنا. ربما ليس هذا هو الحل الأفضل ولكن لدي الآن مشروع به الكثير من المشاريع الفرعية webjobs وهو أمر محبط حقًا تغيير كل ربط الملفات يدويًا بعد تحديث بعض الحزم.

param(
    [string]$SourceDirectory,
    [string]$Package,
    [string]$OldVersion,
    [string]$NewVersion
)

Write-Host "Start fixing all app.config"

[array]$files = get-childitem $sourceDirectory -Include app.config App.config -Recurse | select -expand FullName
foreach ($file in $files)
{
    Write-Host $file
    $xml = [xml](Get-Content $file)
    $daNodes = $xml.configuration.runtime.assemblyBinding.dependentAssembly
    foreach($node in $daNodes)
    {
        if($node.assemblyIdentity.name -eq $package)
        {
            $updateNode = $node.bindingRedirect
            $updateNode.oldVersion = $OldVersion
            $updateNode.newVersion =$NewVersion
        }
    }
    $xml.Save($file)
}

Write-Host "Done"`

استخدام المثال:
./scripts/FixAppConfig.ps1 -SourceDirectory "--project-path--" -Package "System.Net.Http" -OldVersion "0.0.0.0-4.3.0.0" -NewVersion "4.0.0.0"

متى يصبح هذا علنيا مرة أخرى؟ :)

دخل التغيير الذي أجريناه إلى الإصدار / 1.1.0 الفرع يوم الثلاثاء - إصدار الحزمة 4.3.1. تم قلب جميع الحزم في الفرع إلى حالة مستقرة أمس (جهد مستقل ، ولكنه يساعدنا أيضًا :)).
سيجريdavidsh اختبارًا للعقل على myget feed (ETA: today) ، ثم سنطلب التحقق الأخير من المجتمع (ETA: today ، EOD) بمجرد الانتهاء من التحقق النهائي من هذا الإصدار ، سنقوم بدفع الحزمة إلى NuGet. أتوقع أن الأمر سيستغرق أقل من أسبوع.

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

هذه أخبار مرحب بها ، وستجعل استخدام netstandard2.0 أسهل.

تحقق davidsh من الحزمة 4.3.1 من فرع الإصدار (تحذير: كانت myget بطيئة جدًا بالنسبة له - 5 دقائق)
فيما يلي خطوات التحقق من صحة:

يرجى تجربة أحدث الحزم في موجز MyGet dev. ستحتاج إلى استخدام أحدث إصدار من حزمة System.Net.Http.dll الثابتة (وليس الإصدار التجريبي) - 4.3.1 :
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

يمكنك استخدام حزم موجز dev عن طريق تغيير موجز مصدر حزمة NuGet إما باستخدام أدوات سطر الأوامر أو Visual Studio.

تعليمات:

سطر الأوامر:
أضف ما يلي في nuget.config ، أسفلجزء:

<add key="myget.org dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />

استوديو مرئي:
في VS ، Tools-> Options-> Nuget Package Manager-> Package Sources -> Add ، ضمن المصدر ، استخدم عنوان url هذا ، https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

في كلتا الحالتين ، تأكد من إدراج موجز MyGet dev كأول موجز في القائمة.

[تعديل]
توقع إعادة توجيه الربط لـ 4.1.1.0 في ملف التكوين الخاص بك:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

لقد قمت بتحديث أعلى منشور "خطة التنفيذ" بالخطوات التالية:

• 5.c التحقق النهائي / الأخير (لمعظم) السيناريوهات السبعة الشاملة - الأشخاص الذين ساعدوا من قبل (أو أي شخص آخر) ، هل يمكنك الرد بمجرد التحقق من الوصف الموجز للسيناريو؟ شكر! (نحن على وشك الانتهاء)
  
  
  
  • سم مكعب: @ annemartijn0karelkrivanekjahmaipollaxMikeGoldsmithchadwackermandluxfordhpfonovotny
  
  
• 5.d انشر الحزمة على myget.org

حاولت التحقق ولكني أتلقى أخطاء أثناء محاولة تثبيت تلك الحزمة.

عندما قمت بالتحقق من الصحة ، قمت بذلك بمشروع جديد تمامًا.

أظن أن الخطأ الذي تحصل عليه مع "فشل تحديث عمليات إعادة توجيه الربط" يرجع إلى الرجوع إلى إصدار أقدم في إصدارات الحزمة والتجميع. يبدو أن مشروعك الحالي يعتمد على الحزم من الفرع [الرئيسي]. System.Net.Http.4.4. * هو ترقيم الحزمة من الفرع [الرئيسي] (جزء من الإصدار التجريبي لـ .NET Core 2.0). يحتوي على إصدار تجميع لـ System.Net.Http وهو 4.2. *.

حزمة System.Net.Http الإصدار 4.3.1 عبارة عن حزمة ثابتة (ليست ما قبل الإصدار) وهي مبنية من فرع خدمة .NET Core 1.1 (متوافق مع إصدار خدمة .NET Core 1.1.1). يحتوي على ثنائي System.Net.Http dll بإصدار تجميع مختلف.

أعتقد أن الخطأ الذي اكتشفته هو عندما يحاول Visual Studio / NuGet إعادة كتابة عمليات إعادة توجيه الربط الخاصة بك لإصدار التجميع المتغير من System.Net.Http.

لذلك ، يمكنك محاولة إنشاء حل / مشروع جديد. أو ربما حذف عمليات إعادة التوجيه الملزمة الخاصة بك ثم إعادتها.

لمعلوماتك. السجل الخاص بي من تثبيت الحزمة الخاصة بي:

Attempting to gather dependency information for package 'System.Net.Http.4.3.1' with respect to project 'Net46HttpTest3', targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 4.27 min
Attempting to resolve dependencies for package 'System.Net.Http.4.3.1' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'System.Net.Http.4.3.1'
Resolved actions to install package 'System.Net.Http.4.3.1'
Retrieving package 'System.Security.Cryptography.Encoding 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Primitives 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Algorithms 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.X509Certificates 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Net.Http 4.3.1' from 'CoreFx Dev Feed'.
  GET https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1
Adding package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
  OK https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1 302ms
Installing System.Net.Http 4.3.1.
Added package 'System.Security.Cryptography.Encoding.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Encoding 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Primitives 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Algorithms 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.X509Certificates 4.3.0' to Net46HttpTest3
Adding package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to 'packages.config'
Successfully installed 'System.Net.Http 4.3.1' to Net46HttpTest3
Executing nuget actions took 2.41 sec
========== Finished ==========
Time Elapsed: 00:06:40.8451462

حسنًا ، أنا محتار عند الاختبار. لقد قمت بالتحديث إلى 4.3.1 وحصلت على إعادة توجيه الربط التالية في web.config الخاص بي.

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

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

بناء وتشغيل Works On My Machine ™ ️.

بالمناسبة ، لست متأكدًا تمامًا من سبب انخفاض هذا الإصدار من 4.4 إلى 4.3.1 ولكن حسنًا.

انخفض الإصدار في الترقيم لأن الإصدار 4.4 سيكون الأحدث ولكنه لا يزال ما قبل الإصدار وسيتم شحنه كجزء من .NET Core 2.0. طلب karelz من الأشخاص اختبار هذه الحزمة أولاً لأن الإصلاح كان موجودًا أولاً.

تعتمد حزم 4.3. * على RTM .NET Core 1.1. وسيكون هناك تحرير خدمة لذلك. لذلك ، فإن الحزمة المحدثة بناءً على هذا البرنامج هي 4.3.1 لـ System.Net.Http (حيث أن حزمة .NET Core 1.0 كانت 4.3.0 لـ System.Net.Http.

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

نعم ، هذا محير. إصدار حزمة NuGet ليس هو نفسه إصدار تجميع .NET من البرنامج الثنائي.

بالنسبة لحزمة System.Net.Http 4.3.1 NuGet ، فإنها تحتوي على ثنائي System.Net.Http الذي يحتوي على إصدار تجميع 4.1.1.0. لذلك ، أنت تحصل على النتائج الصحيحة.

شكرًا pollax على التحقق من صحة السيناريو الخاص بك (تم تحديث
في انتظار مزيد من عمليات التحقق ، قبل أن نتمكن من شحنها كإصلاح نهائي على nuget.org ... هناك تقريبًا ...

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

davidsh ، هل يمكنك تنسيق عمليات التحقق من الصحة leecow / weshaggard بنشر الحزمة على nuget.org. شكر!

مرحبا شباب،

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

شكرا على الدعم يا رفاق واستمروا في العمل الجيد. الأخطاء تحدث. شكرًا لإصلاحه ، أتفهم أنه يستغرق وقتًا.

إليك تأكيد آخر على أن الإصدار الجديد يصلح المشكلة.

نحن نستخدم KeyVault ، والارتداد إلى 4.3.1 لإصلاح المشكلة.

مرحبًا ، لدي هذه المشكلة مع SignalR. ولكن كيف يمكنني الحصول على System.Net.Http 4.3.1؟ أرى فقط 4.3.0 بوصة
https://www.nuget.org/packages/System.Net.Http/

عفوًا ، الرسائل الفائتة حول CoreFx - https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

يعمل على إصلاح مشكلة SignalR الخاصة بي.

كما لاحظ الآخرون ، فإن التغذية بطيئة للغاية. هل هناك أي فرصة للحصول على 4.3.1 في قناة nuget العادية؟ إنه السبت الساعة 1:30 مساءً و قف .... (8 دقائق في انتظار التقسيمات)

محاولة جمع معلومات التبعية للحزمة 'System.Net.Http.4.3.1' فيما يتعلق بالمشروع 'Translate \ Kumquat.Translate.Tests' ، والتي تستهدف '.NETFramework، Version = v4.6'
استغرق جمع معلومات التبعية 5.85 دقيقة
محاولة حل التبعيات لحزمة 'System.Net.Http.4.3.1' مع ​​DependencyBehavior 'Lowest'
تم اكتشاف واحد أو أكثر من قيود تبعية الحزمة التي لم يتم حلها في ملف package.config الحالي. يجب حل جميع قيود التبعية لإضافة أو تحديث الحزم. إذا كان يتم تحديث هذه الحزم ، فقد يتم تجاهل هذه الرسالة ، إذا لم يكن الخطأ (الأخطاء) التالية يحظر عملية الحزمة الحالية: "System.Net.Http 4.3.0"
استغرق حل معلومات التبعية 0 مللي ثانية
حل إجراءات تثبيت الحزمة "System.Net.Http.4.3.1"
الإجراءات التي تم حلها لتثبيت الحزمة 'System.Net.Http.4.3.1'

محاولة جمع معلومات التبعية للحزمة 'System.Net.Http.4.3.1' فيما يتعلق بالمشروع 'Dict \ Kumquat.Dict.CE.Tests' ، والتي تستهدف '.NETFramework، Version = v4.6'
استغرق جمع معلومات التبعية 3.84 دقيقة
محاولة حل التبعيات لحزمة 'System.Net.Http.4.3.1' مع ​​DependencyBehavior 'Lowest'
تم اكتشاف واحد أو أكثر من قيود تبعية الحزمة التي لم يتم حلها في ملف package.config الحالي. يجب حل جميع قيود التبعية لإضافة أو تحديث الحزم. إذا كان يتم تحديث هذه الحزم ، فقد يتم تجاهل هذه الرسالة ، إذا لم يكن الخطأ (الأخطاء) التالية يحظر عملية الحزمة الحالية: "System.Net.Http 4.3.0"
استغرق حل معلومات التبعية 0 مللي ثانية
حل إجراءات تثبيت الحزمة "System.Net.Http.4.3.1"
الإجراءات التي تم حلها لتثبيت الحزمة 'System.Net.Http.4.3.1'

تمت إعادة التحقق من سيناريو

آسف لعدم الاستجابة عاجلا.

تبعيات جمع https://github.com/NuGet/Home/issues/4448

تصورت ذلك. هل هناك أي وقت متوقع للوصول إلى nuget.org؟

davidsh مرحبًا ديفيد ، هل سيكون هذا الأسبوع 4.3.1 يصل إلى nuget؟ لدي مشروع معقد إلى حد ما ويبدو أن وقت الانتظار يجب أن يتناسب مع عدد الحزم في المشروع. ومع ذلك ، فإن الحصول على حل أفضل من لا شيء. أفترض أنه يمكنني نسخ nupkg في مكان ما.

محاولة جمع معلومات التبعية للحزمة 'Kumquat.Translate.8.6.2' فيما يتعلق بالمشروع 'qi' ، باستهداف '.NETFramework، Version = v4.6'
استغرق جمع معلومات التبعية 8.76 دقيقة

آخرها 8.76 دقيقة

davidsh ظهر هذا للتو في القائمة البريدية لـ OwlMQ. يمكنني الإبلاغ عن أن الحزمة المحدثة تحلها.

شكرًا جزيلاً للفريق على استباقهم لهذا الأمر. عمل رائع!

شكرا لك على جميع عمليات التحقق من صحة الحزمة.

تمت ترقية حزمة System.Net.Http 4.3.1 إلى NuGet.org.

https://www.nuget.org/packages/System.Net.Http/4.3.1

حسنًا ، غريب جدًا - يشتكي عميل RavenDB الآن من أنه لا يمكنه العثور على التجميع 4.1.1

تحرير: تحذير - يشير Acme.Core إلى RavenDB.Client و Acme.Main المراجع Acme.Core. لن يقوم VS2015 بنسخ System.Net.Http كتبعية ولكن إعادة التوجيه الملزمة موجودة -> boom. هل هذا سلوك متوقع؟ إصلاح بسيط بما فيه الكفاية بالطبع ...

إغلاق المشكلة على أنه تم إصلاحه. شكرًا @ davidsh و @ CIPop على عملهم هنا!
شكرا للجميع على صبرهم. ونعتذر عن التأخير. الخطوة التالية: بعد الوفاة (كما وعدت) - يرجى إعطائي أسبوعين تقريبًا لمعرفة جميع التفاصيل التاريخية هنا ...

georgiosd ، هل يمكنك تسجيل مشكلة جديدة وتقديم نسخة عنها؟ (من الأفضل البدء بمشروع جديد)

@ karelz شكرا لك!

لمعلوماتك:

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

@ karelz سؤال سريع: أين سنجد معلومات حول التشريح عند اكتماله. في هذا الموضوع _or_ موضوع آخر / مكان؟

PureKrome سأقوم بالتأكيد بتحديث هذا الموضوع - إنه من الأسهل على كل شخص مهتم بالفعل الحصول على الإشعار. كما أن هدفي ليس التقليل من أهمية تشريح الجثة وإخفائها عن الناس.
سأقوم على الأرجح بإنشاء مشكلة جديدة للمناقشة بالرغم من (كما أتوقع البعض) ؛-).
على مستوى عالٍ ، أخطط لتغطية:

1. كيف انتقلت المشكلة إلى الإصدار؟ كيف نمنع مثل هذا الوضع في المستقبل؟
2. لماذا استغرق إصلاحه 6 أشهر؟ لماذا لم يتم التعامل معها / الإبلاغ عنها على أنها مشكلة عالية التأثير في وقت سابق؟ كيف تتعرف وتتفاعل مع القضايا عالية التأثير في وقت مبكر في المستقبل؟
3. مخاوف أخرى (مثل التواصل العام)

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

شكرا لك @ Karelz (و MS Team). سأبقى مشتركًا في هذا الموضوع بعد ذلك. 👍

استمر في القتال الجيد ، أيها الفريق! 💯

أود أيضًا أن أشكر @ chadwackerman2

تهانينا للجميع مرة أخرى لحل واحدة من أكثر الأخطاء المزعجة في تاريخ .NET :)

karelz سعيد للقيام بذلك ولكني تساءلت عما إذا كان هذا هو السلوك المتوقع بطريقة ما؟

georgiosd لا أعرف - سيكون من الأسهل مناقشتها في قضية منفصلة ؛-) (بما في ذلك جذب الخبراء المناسبين)

شكرًا لقيادة هذا العمل ،karelz

أعلم أنني تأخرت في التشريح هنا ، اعتذاري.
لم أنس ، لم أتمكن من الوصول إليها بعد بسبب الأولويات الأعلى (التخطيط / التتبع 2.0 ، والنظر بشكل أعمق في مشكلة إعادة التوجيه الملزمة التي ظهرت هنا أيضًا - dotnet / runtime # 17770)
سأبذل قصارى جهدي لإنهاء التشريح بعد 1-2 أسبوع.

مرحبًا ، أحسنت جميع المشاركين في حل هذا الأمر. لا يمكنني القول إنني أفهم جميع الصواميل والمسامير ولكن هناك شيء واحد ما زلت لا أفهمه وهو سبب حدوث ذلك فقط عندما قمنا بترقية الحل الخاص بنا من VS 2015 Update 3 إلى VS 2017. كان الحل المعني عبارة عن مجموعة من مشاريع ASP.Net Core التي تستهدف .net framework 4.6. تم تشغيل المشكلة من خلال استخدامنا لـ Azure KeyVaultClient.

شكرا دونال

مرحبًا karelz ، لقد كنت أبحث وأعمل لليلتين متتاليتين حتى الآن ولكني غير قادر على إصلاح هذا. تم تحديث جميع حزم System.Net.Http الخاصة بي إلى الإصدار 4.3.1 ولكن لا يزال هناك نفس الخطأ. الرجاء مساعدتي ، لا أعرف ماذا أحاول أو إلى أين أذهب. شكر!

FileNotFoundException: تعذر تحميل الملف أو التجميع 'System.Net.Http ، الإصدار = 4.1.1.0 ، الثقافة = محايد ، PublicKeyToken = b03f5f7f11d50a3a'. لا يمكن للنظام العثور على الملف المحدد.

هنا بلدي .csproj

netcoreapp1.1

$ (PackageTargetFallback) ؛ portable-net45 + win8 + wp8 + wpa81 ؛

aspnet-IbmVcaCore-5aa05652-04e7-4a42-9fd6-8dbc1c8b98fe

parismiguel آسف لسماع ذلك :(. هل لديك توجيهات ملزمة من 4.0.0.0 إلى 4.1.1.0 في تطبيقك؟

<dependentAssembly> 
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> 
</dependentAssembly> 

نحن نبحث في كيفية جعل قصة إعادة التوجيه الملزمة أكثر سلاسة: https://github.com/dotnet/corefx/issues/9846#issuecomment -287941109

تحديث: بالنظر إلى الخطأ الخاص بك ، يبدو أن المشكلة تكمن في عدم العثور على الإصدار 4.1.1.0. هل يمكنك التحقق من دليل التطبيق الخاص بك إذا كان إصدار التجميع الصحيح موجودًا بالفعل؟

@ Karelz كان ذلك سريعًا ، شكرًا جزيلاً لك! لقد رأيت عناصر إعادة التوجيه الملزمة في المنشورات السابقة ولكني لست متأكدًا من مكان وضعها ... لقد حاولت داخل .csproj ولكن لدي أخطاء (مرفقة بتنسيق txt.) بخصوص الإصدار 4.1.1.0 I ' لست متأكدًا من المتابعة ... أليس من المفترض أن أقوم بترقيته إلى 4.3.1؟

IbmVcaCore.csproj.txt

تنتقل عمليات إعادة التوجيه الملزمة إلى ملف app.config أو web.config:

انظر هذا للحصول على التفاصيل:
https://msdn.microsoft.com/en-us/library/7wd6ex19 (v = مقابل 110) .aspx

مرحبًا davidsh ، شكرًا لك على مساعدتك!
لا يحتوي مشروعي على أي من هذه الملفات ... إنه عبارة عن مشروع NET Core باستخدام قالب Visul Studio 2017 ... ما الذي أفتقده؟

رد: 4.3.1 مقابل 4.1.1 - 4.3.1 هو إصدار حزمة NuGet ، 4.1.1.0 هو إصدار التجميع (ildasm / ILSpy / VS سيظهر لك).
تعد إصدارات NuGet مقابل التجميع مربكة بعض الشيء ويصعب الاتصال بأي منها. إنها مدرجة في قائمة الأشياء التي يجب النظر فيها بشكل أعمق إذا كان بإمكاننا توصيل النقاط عبر الوثائق (على سبيل المثال في صفحة NuGet).

إذا كنت تستخدم .NET Core ، فلن تحتاج إلى التوجيهات الملزمة ، وعلاوة على ذلك ، فإن هذه المشكلة لا تؤثر عليك على الإطلاق. هذه المشكلة خاصة بسطح المكتب (= .NET Framework).
قامت حزمة 4.3.1 NuGet بتعديل تجميع سطح المكتب الخاص بها فقط ، وليس تجميع .NET Core.

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

للجميع : لقد قمت بإنشاء إصدار جديد dotnet / corefx # 17522 لتتبع ما بعد الوفاة الذي وعدت به.
للأسف ، لم أحرز تقدمًا كبيرًا نحو ذلك حتى الآن :( ... ولكن على الأقل يمكن لكل شخص مهتم البدء في متابعة هذه المشكلة وتجنب الضوضاء المحتملة بشأن هذه المشكلة (محاولة مساعدة الأشخاص على التركيز على ما يهتمون به).

karelz شكرًا ،

parismiguel ليس في الإصدار الجديد الذي أنشأته ، يرجى إنشاء علامة تجارية جديدة. المشكلة التي قمت بإنشائها (# 17522) مخصصة لتحليل ما بعد الوفاة لماذا استغرقت هذه المشكلة (# 11100) وقتًا طويلاً لحلها.

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

يبدو أنني واجهت هذا عبر عاصفة كاملة.

أنا أستخدم معاينة وظائف Azure مع مزيج من Azure Key Vault (2.0.6) و Octopus Client (4.15.3).

لقد حاولت الترقية إلى System.Net.Http إلى 4.3.2 ومع ذلك لا يزال فشل عند محاولة استخدام Key Vault .

أي نصائح؟

تضمين التغريدة

هل يمكنك التأكد من استخدام التجميع من حزمة 4.3.2 nuget بالفعل في وقت التشغيل؟ (تم إصلاحه في 4.3.1)