Nunit: نهاية دعم .NET Framework 2.0 (تم إصداره عام 2005)

تم إنشاؤها على ١٨ أكتوبر ٢٠١٨  ·  27تعليقات  ·  مصدر: nunit/nunit

إن دعم net20 كحد أدنى بدلاً من net35 يزيد من تعقيد تطورنا. لدينا NUnit.System.Linq ونحدد نظامنا الخاص. الإجراء واكتب NET35 || NET20 حيث يمكن أن يكون لدينا NET35 . نحن نأخذ وقتًا إضافيًا في انتظار الاختبارات. ولدينا المزيد من العمل للقيام به على net20 فقط: https://github.com/nunit/NUnit.System.Linq/issues/12

للاقتباسNN - من https://github.com/nunit/NUnit.System.Linq/issues/12#issuecomment -430979252:

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

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

ما زلت أؤيد دعم net35 (الذي تم إصداره عام 2008) لأنني أعرف مشروعات حقيقية تعمل باستخدام CLR v2 (يدعم حتى net35) ولن أكون واثقًا من إجراء اختبارات لذلك على محرك CLR v4. أيضًا ، لا يزال VSTest يشحن باستخدام عداء net35. ومع ذلك ، أتساءل عما إذا كان إسقاط هذا الدعم يمكن أن يكون له تأثير مضاعف مفيد.

أخيرًا ، لم يعد منتج .NET Framework 2.0 مدعومًا من قبل الشركة المصنعة الخاصة به:

انتهى دعم .NET Framework 2.0 في 12 يوليو 2011. NET 3.5 SP1 هو مستوى حزمة الخدمة المدعوم الوحيد بعد هذا التاريخ. نحن نشجع العملاء بشدة على الترحيل إلى .NET Framework 3.5 SP1. لمزيد من المعلومات ، يرجى زيارة الأسئلة المتداولة حول نهج دورة حياة دعم .NET Framework

https://support.microsoft.com/lifecycle/search؟alpha=.NET Framework 2.0

done

التعليق الأكثر فائدة

لا أرغب في إسقاط دعم .NET 4.0. معظم عناصر سطح المكتب الخاصة بنا لا تزال .NET 4. لقد تم إصلاحنا فيها لفترة طويلة نظرًا لكونها الإصدار الأخير المتاح على XP. إنه دين تقني الآن ، بالتأكيد - لكن الترقية لها تكلفة. ضع في اعتبارك ، لقد شعرت بالانزعاج عندما أسقط NUnit 3.0 دعم ملف تعريف عميل .NET 4.0. 😉

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


على .NET 2.0 - أنا لا مبالي إلى حد ما. إن قلقي سيكون المكتبات التي تدعم منصات متعددة. لا أوافق على أنه يجب على NUnit "تشجيع" المكتبات الأخرى على التخلي عن الدعم ، وأعتقد شخصيًا أن مكتبة الاختبار يجب أن تكون آخر الأشخاص الذين يتخلى عن الدعم - طالما أن هناك مكتبات هناك ، فهم بحاجة إلى الاختبار! 🙂 لا أعتقد أيضًا أن اختيارات XUnit / MSTest يجب أن تأخذ في الاعتبار - التوافق العكسي هو قوة NUnit ، وفجوة في النظام البيئي الذي نملأه. هذا شيء جيد!

بعد كل ما قيل ، إن .NET 2.0 هو _ قديم _ الآن ، ولن أكون مترددًا في إسقاطه - يمكن لمشرفي المكتبة هؤلاء قفل اختبارات .NET 2.0 الخاصة بهم للتشغيل على NUnit 3.11. أعتقد أن 7 سنوات تدعم الماضي عندما يكون Microsoft EOL كافياً!

كنت أؤيد بشدة إزالة .NET 2.0 من المحرك ، حيث يتسبب في حدوث مشكلات لنا ، مثل استبدال Mono و Remote. أنا فقط لا أرى بنشاط نفس الحواجز في إطار العمل.

ال 27 كومينتر

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

كلا من MSTest و xUnit يبلغان حاليًا كحد أدنى .NET 4.5 ولم أر أي تراجع جدي لذلك. يمكننا أيضًا التفكير في إسقاط 4.0 الدعم وجميع حلول Async لدينا في ذلك وتتطلب 4.5 للاختبارات. مثل 2.0 / 3.5 ، إنه نفس CLR. أنا أقل ميلًا للقيام بذلك ، لكنني أطرحه على طاولة المناقشة.

منذ عدة سنوات ، كان لدينا خطأ في NUnit لا يدعم .NET 3.5. استغرق الأمر عدة أشهر قبل أن يتم الإبلاغ عنه وهو مؤشر على مقدار استخدامه. أتوقع أن الإصدار 2.0 صغير للغاية.

أقترح أن أرسل بريدًا إلكترونيًا إلى القائمة البريدية لـ NUnit Discuss لطلب التعليقات من أي شخص يستخدم NUnit لـ .NET 2.0 مع خطة لإسقاط الدعم في الإصدار التالي في حالة عدم ظهور أسباب مقنعة.

سؤال - هل هذا تغيير جذري من شأنه أن يضمن إصدار 4.0؟ لقد قمنا بتغيير إصداري PCL و .NET Standard دون الانتقال إلى 4.0.

يعجبني اقتراحك.

سيتطلب xUnit 3.0 حد أدنى من .NET Framework 4.7.2. https://github.com/xunit/xunit/issues/1732

إن إسقاط دعم net40 في نفس الوقت سيكون منطقيًا ويخفف حملنا بأشياء غير متزامنة. ربما يجب علينا التفكير في نقل net45 إلى net452:

انتهى دعم .NET Framework 4 و 4.5 و 4.5.1 في 12 يناير 2016. توصي Microsoft العملاء بالترقية إلى .NET Framework 4.5.2 لمواصلة تلقي الدعم الفني وتحديثات الأمان. لمزيد من المعلومات ، يرجى زيارة الأسئلة الشائعة حول نهج دورة حياة دعم .NET Framework https://support.microsoft.com/help/17455.

https://support.microsoft.com/en-us/lifecycle/search؟alpha=.NET Framework 4

هل هذا تغيير جذري من شأنه أن يضمن إصدار 4.0؟ لقد قمنا بتغيير إصداري PCL و .NET Standard دون الانتقال إلى 4.0.

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

/ ccChrisMaddock الذي عمل مؤخرًا مع مشاريع net40.

لا أرغب في إسقاط دعم .NET 4.0. معظم عناصر سطح المكتب الخاصة بنا لا تزال .NET 4. لقد تم إصلاحنا فيها لفترة طويلة نظرًا لكونها الإصدار الأخير المتاح على XP. إنه دين تقني الآن ، بالتأكيد - لكن الترقية لها تكلفة. ضع في اعتبارك ، لقد شعرت بالانزعاج عندما أسقط NUnit 3.0 دعم ملف تعريف عميل .NET 4.0. 😉

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


على .NET 2.0 - أنا لا مبالي إلى حد ما. إن قلقي سيكون المكتبات التي تدعم منصات متعددة. لا أوافق على أنه يجب على NUnit "تشجيع" المكتبات الأخرى على التخلي عن الدعم ، وأعتقد شخصيًا أن مكتبة الاختبار يجب أن تكون آخر الأشخاص الذين يتخلى عن الدعم - طالما أن هناك مكتبات هناك ، فهم بحاجة إلى الاختبار! 🙂 لا أعتقد أيضًا أن اختيارات XUnit / MSTest يجب أن تأخذ في الاعتبار - التوافق العكسي هو قوة NUnit ، وفجوة في النظام البيئي الذي نملأه. هذا شيء جيد!

بعد كل ما قيل ، إن .NET 2.0 هو _ قديم _ الآن ، ولن أكون مترددًا في إسقاطه - يمكن لمشرفي المكتبة هؤلاء قفل اختبارات .NET 2.0 الخاصة بهم للتشغيل على NUnit 3.11. أعتقد أن 7 سنوات تدعم الماضي عندما يكون Microsoft EOL كافياً!

كنت أؤيد بشدة إزالة .NET 2.0 من المحرك ، حيث يتسبب في حدوث مشكلات لنا ، مثل استبدال Mono و Remote. أنا فقط لا أرى بنشاط نفس الحواجز في إطار العمل.

ChrisMaddock هذا تحليل عادل لدعم .NET 4.0 وما

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

جلب NET Core وعمليات النشر القائمة بذاتها!

لقد أرسلت بريدًا إلكترونيًا إلى nunit-discuss لأطلب من أي شخص يستخدم .NET 2.0 ولا يريد استهداف .NET 3.5 في اختباراتهم للتعليق على هذه المشكلة.

rprouse ربما بث السؤال أيضًا عبر حساب تويتر nunit (أعتقد / آمل أن "نحن" نتحكم فيه؟)

فكرة ممتازة @ mikkelbu ، شكرا. يرجى إعادة تغريد الجميع ، https://twitter.com/nunit/status/1055845383400767490

1،911 انطباع على Twitter للتغريدة ولا يوجد رد حتى الآن ... 🤔

لقد قلت تحديدًا أن الأشخاص الذين نود أن نسمع منهم هم الأشخاص الذين لديهم اختبارات net20 قيد التطوير النشط ولا يريدون نقل مشروع الاختبار إلى net35 ، لذلك ربما يكون الرقم 1،911 بيانًا قويًا بأن الجميع إما غير متأثر أو سعيد للانتقال إلى net35؟

يبدو إسقاط الدعم لـ 2.0-4.5 معقولًا تمامًا ؛ نحن حاليًا على 4.5.2+ وننتقل ببطء إلى 4.6.

: +1: فقط للتوضيح ، أعتقد أننا نفكر فقط في إسقاط .NET Framework 2.0 في هذه المرحلة والاحتفاظ ببنيات .NET Framework 3.5–4.5 الخاصة بنا.

إذا كان الأشخاص يستخدمون .net 2.0 ولا يقومون بتحديث إطار العمل ، فأنا أشك بشدة في أنهم سيفكرون في التحديث إلى إصدار أحدث من NUnit. ستظل الإصدارات القديمة تعمل ، لذلك لا أرى أي سبب مقنع للبقاء على 2.0 ، ولا حتى 3.5. ربما 4.0 ، لكني لست متأكدًا من ذلك.

ليس لدينا أي ردود فعل سلبية هنا ، في قائمة المناقشة أو على تويتر. @ nunit / framework-and-engine-team هل علينا المضي قدمًا في هذا الأمر؟ كما ذكر ChrisMaddock ، أنا أيضًا أؤيد فعل الشيء نفسه في المحرك ، لكن يمكننا مناقشة ذلك هناك.

لقد مر شهر؛ يبدو أمرا جيدا لي. هل يجب علي العلاقات العامة https://github.com/nunit/nunit/compare/master...jnm2 : drop_net20؟

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

ccJamesNK للتوعية ، Newtonsoft هي مكتبة واحدة أعرف أنها لا تزال تستخدم .NET 2.0 NUnit.

لقد راجعت مشروع اختبار NewtonSoft.JSON وهو يستخدم NUnit ولديه هدف net20 . https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json.Tests/Newtonsoft.Json.Tests.csproj

😢

إذا كنت تعتقد أنه من الأفضل للراهبة. يمكنني دائمًا تشغيل net20 DLL على هدف 3.5

لا نريد أن نجعل الناس حزينين. هل تتوقع وجود مستخدمين يحتاجون إلى net20 على وجه التحديد لسنوات عديدة أخرى؟

ℹ (ملاحظة عامة) لقد اكتشفت هذا للتو عند إجراء اختبارات net35 مع vstest.console.exe 15.9:

Framework35 غير معتمد. بالنسبة للمشاريع التي تستهدف .Net Framework 3.5 ، يرجى استخدام Framework40 لتشغيل الاختبارات في CLR 4.0 "وضع التوافق".

أوتش!

سمعت أن VS كان يسقط دعم عداء 3.5 ، لكنني تحققت من بعض التحديثات منذ ذلك الحين وكان لا يزال موجودًا. أعتقد أنه حدث أخيرا. غريب ، اعتقدت أنه سيأتي في VS 2019 بدلاً من التحديث.

أعتقد أنه تم تقديمه في هذه العلاقات العامة - Microsoft / vstest # 1723 ، لكن لم يتم ذكره في ملاحظات الإصدار - https://github.com/Microsoft/vstest-docs/blob/master/docs/releases.md

كان هذا هو VSTest.Console المعبأ في .NET Core SDK 2.1.500 ، مدفوعًا عبر dotnet test . أعتقد أنه تم تثبيته بواسطة VS 15.9.

هل تتوقع وجود مستخدمين يحتاجون إلى net20 على وجه التحديد لسنوات عديدة أخرى؟

انا لا اعرف. لا توجد أي إحصائيات حول الهدف المستخدم. من وجهة نظري ، ليس هناك الكثير من الجهد في الحفاظ على هدف net20. خطتي هي تركها حتى يصبح من الصعب الحفاظ عليها.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات