Nunit: .NET Framework 2.0 के लिए समर्थन समाप्त करें (2005 में जारी)

जबकि मैं पूरी तरह से सहमत हूं, मुझे लगता है कि हमें इसे धीरे-धीरे लेने की जरूरत है ताकि यह सुनिश्चित हो सके कि समुदाय जागरूक है कि परिवर्तन आ रहा है और प्रतिक्रिया प्रदान कर सकता है। हमने पिछली बार समुदाय को कई साल पहले मतदान किया था, लेकिन मुझे उम्मीद है कि तब से परिदृश्य बदल गया है। मैं भी उन्हीं कारणों से कंसोल और इंजन को 3.5 में अपडेट करना चाहता हूं।

एमएसटीएस्ट और एक्सयूनीट दोनों वर्तमान में न्यूनतम .NET 4.5 पर हैं और मैंने इसमें कोई गंभीर पुशबैक नहीं देखा है। हम 4.0 समर्थन और हमारे पास मौजूद सभी Async वर्कअराउंड को छोड़ने पर भी विचार कर सकते हैं और परीक्षणों के लिए 4.5 की आवश्यकता होती है। 2.0/3.5 की तरह, यह वही सीएलआर है। मैं ऐसा करने के लिए कम इच्छुक हूं, लेकिन मैं इसे चर्चा के लिए टेबल पर रख रहा हूं।

कई साल पहले हमारे पास एक बग था जिसमें NUnit .NET 3.5 का समर्थन नहीं कर रहा था। इसे रिपोर्ट किए जाने में कई महीने लग गए जो इस बात का संकेत है कि इसका कितना उपयोग किया जाता है। मुझे उम्मीद है कि 2.0 गायब हो रहा है।

मैं प्रस्ताव करता हूं कि मैं एनयूनीट डिस्कस मेलिंग सूची को एक ईमेल भेजूं जिसमें .NET 2.0 के लिए एनयूनीट का उपयोग करने वाले किसी भी व्यक्ति से फीडबैक मांगा जाए, अगर कोई अनिवार्य कारण वापस नहीं आते हैं तो अगली रिलीज में समर्थन छोड़ने की योजना है।

प्रश्न - क्या यह एक महत्वपूर्ण बदलाव है जो 4.0 रिलीज की गारंटी देगा? हमने अपने पीसीएल और .NET मानक रिलीज को 4.0 पर जाए बिना बदल दिया है।

मुझे आपका प्रस्ताव पसंद है।

xUnit 3.0 के लिए न्यूनतम .NET Framework 4.7.2 की आवश्यकता होगी। https://github.com/xunit/xunit/issues/1732

एक ही समय में net40 के लिए समर्थन छोड़ना समझ में आता है और async सामान के साथ हमारे भार को हल्का करता है। शायद हमें 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 रिलीज की गारंटी देगा? हमने अपने पीसीएल और .NET मानक रिलीज को 4.0 पर जाए बिना बदल दिया है।

हमें लगता है कि शायद ही कोई प्रभावित होगा। इसके बजाय मैं इसके लिए संस्करण संख्या 4.0 नहीं लूंगा, जब तक कि हम अन्य ब्रेकिंग परिवर्तन भी करने का अवसर नहीं लेते।

/ सीसी @ChrisMaddock जो 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 पर - मैं काफी उदासीन हूं। मेरी चिंता कई प्लेटफार्मों का समर्थन करने वाले पुस्तकालय होंगे। मैं असहमत हूं कि एनयूनीट को अन्य पुस्तकालयों को समर्थन छोड़ने के लिए 'प्रोत्साहित' करना चाहिए, मैं व्यक्तिगत रूप से सोचता हूं कि परीक्षण पुस्तकालय _last_ लोगों को समर्थन छोड़ने के लिए होना चाहिए - जब तक वहां पुस्तकालय हैं, उन्हें परीक्षण की आवश्यकता है! 🙂 मुझे यह भी नहीं लगता कि XUnit/MSTest के विकल्पों में कारक होना चाहिए - पिछड़ा कॉम्पैट एनयूनीट की ताकत है, और पारिस्थितिक तंत्र में एक अंतर है जिसे हम भरते हैं। यह तो अच्छी बात है!

जो कुछ भी कहा गया है, .NET 2.0 अब _old_ है, और मुझे इसे छोड़ने का कोई विरोध नहीं होगा - ऐसे पुस्तकालय रखरखाव NUnit 3.11 पर चलने के लिए अपने .NET 2.0 परीक्षणों को लॉक कर सकते हैं। मुझे लगता है कि Microsoft EOL'd के 7 साल पहले का समर्थन पर्याप्त है!

मैं सक्रिय रूप से इंजन से .NET 2.0 को हटाने का समर्थन करता हूं, जहां यह सक्रिय रूप से हमें समस्याएं पैदा कर रहा है जैसे मोनो और रिमोटिंग प्रतिस्थापन। मैं ढांचे में सक्रिय रूप से समान बाधाओं को नहीं देखता हूं।

@ChrisMaddock यह .NET 4.0 समर्थन का एक उचित विश्लेषण है और इसकी लागत क्या होगी, धन्यवाद। मुझे लगता है कि उन सभी परीक्षण सूटों को 4.5 को लक्षित करने के लिए अद्यतन करना भी एक मुद्दा होगा?

कोई समस्या नहीं है, क्योंकि हमें उपयोगकर्ता मशीनों पर .NET स्थापनाओं के बारे में चिंता करने की आवश्यकता नहीं होगी। लेकिन इसका मतलब यह होगा कि हम एक ऐसे प्लेटफॉर्म पर परीक्षण नहीं कर सकते जिसका हम 'समर्थन' करते हैं, जो आदर्श नहीं है - हमने पिछले कुछ वर्षों में 4.0 और 4.5 के बीच कुछ सूक्ष्म अंतरों को मारा है।

.NET कोर और स्व-निहित परिनियोजन लाएं!

मैंने nunit-discuss एक ईमेल भेजकर किसी ऐसे व्यक्ति से पूछा जो .NET 2.0 का उपयोग कर रहा है और जो अपने परीक्षणों में .NET 3.5 को लक्षित नहीं करना चाहता, इस मुद्दे पर टिप्पणी करने के लिए कह रहा है।

@rprouse शायद

उत्कृष्ट विचार @mikkelbu , धन्यवाद। कृपया सभी को रीट्वीट करें, https://twitter.com/nunit/status/1055845383400767490

ट्वीट के लिए 1,911 ट्विटर इंप्रेशन और अब तक कोई प्रतिक्रिया नहीं...

आपने विशेष रूप से कहा था कि जिन लोगों से हम सुनना चाहते हैं, वे लोग हैं कि दोनों के पास सक्रिय विकास में net20 परीक्षण हैं और परीक्षण परियोजना को net35 पर नहीं ले जाना चाहते हैं, इसलिए शायद 1,911 संख्या एक मजबूत कथन है कि हर कोई है या तो अप्रभावित या net35 में जाने के लिए खुश?

2.0-4.5 के लिए समर्थन छोड़ना पूरी तरह से उचित लगता है; हम वर्तमान में 4.5.2+ पर हैं और धीरे-धीरे 4.6 पर माइग्रेट कर रहे हैं।

:+1: बस स्पष्ट करने के लिए, मुझे लगता है कि हम इस बिंदु पर केवल .NET Framework 2.0 को छोड़ने और हमारे 3.5–4.5 .NET फ्रेमवर्क को बनाए रखने पर विचार कर रहे हैं।

अगर लोग .net 2.0 पर हैं और ढांचे को अपडेट नहीं करते हैं, तो मुझे गंभीरता से संदेह है कि वे एनयूनीट के एक नए संस्करण को अपडेट करने पर भी विचार करेंगे। पुराने संस्करण अभी भी काम करेंगे, इसलिए मुझे 2.0 पर बने रहने का कोई ठोस कारण नहीं दिखता, 3.5 भी नहीं। शायद, शायद 4.0, लेकिन इसके बारे में निश्चित भी नहीं है।

चर्चा सूची में या ट्विटर पर हमें यहां कोई नकारात्मक प्रतिक्रिया नहीं मिली है। @ नूनिट/फ्रेमवर्क-एंड-इंजन-टीम क्या हम इसके साथ आगे बढ़ेंगे? जैसा कि @ क्रिसमैडॉक ने उल्लेख किया है, मैं भी इंजन में ऐसा करने के पक्ष में हूं, लेकिन हम वहां चर्चा कर सकते हैं।

इसको एक महीना बीत गया; मुझे अच्छा लगता है। क्या मुझे https://github.com/nunit/nunit/compare/master...jnm2 :drop_net20 पर पीआर करना चाहिए?

आगे बढ़ो और अपना पीआर जमा करो। हालांकि विलय करने से पहले इस पर टिप्पणियों के लिए कुछ दिन प्रतीक्षा करें।

cc @JamesNK जागरूकता के लिए, न्यूटनसॉफ्ट एक पुस्तकालय है जो मुझे पता है कि अभी भी .NET 2.0 NUnit का उपयोग करता है।

मैंने न्यूटनसॉफ्ट.JSON परीक्षण परियोजना की जाँच की और यह NUnit का उपयोग कर रहा है और इसका लक्ष्य net20 । https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json.Tests/Newtonsoft.Json.Tests.csproj

मैं

अगर आपको लगता है कि यह नूनिट के लिए सबसे अच्छा है। मैं हमेशा 3.5 लक्ष्य पर नेट 20 डीएलएल चला सकता था

हम लोगों को दुखी नहीं करना चाहते। क्या आप ऐसे उपयोगकर्ताओं की उम्मीद करेंगे जिन्हें विशेष रूप से कई और वर्षों के लिए net20 की आवश्यकता है?

(सामान्य नोट) मैंने इसे अभी खोजा जब vstest.console.exe 15.9 के साथ net35 परीक्षण चला रहा था:

फ्रेमवर्क 35 समर्थित नहीं है। .Net Framework 3.5 को लक्षित करने वाली परियोजनाओं के लिए, कृपया CLR 4.0 "संगतता मोड" में परीक्षण चलाने के लिए Framework40 का उपयोग करें।

आउच!

मैंने सुना है कि वीएस 3.5 धावक के लिए समर्थन छोड़ रहा था, लेकिन मैंने कुछ अपडेट पहले चेक किए थे और यह अभी भी वहां था। मुझे लगता है कि यह आखिरकार हुआ। अजीब, मुझे लगा कि यह अपडेट के बजाय वीएस 2019 में आएगा।

मुझे लगता है कि इसे इस पीआर में पेश किया गया था - माइक्रोसॉफ्ट/vstest#1723, लेकिन रिलीज नोट्स में इसका उल्लेख नहीं किया गया है - https://github.com/Microsoft/vstest-docs/blob/master/docs/releases.md

यह VSTest.Console .NET Core SDK 2.1.500 में पैक किया गया था, जो dotnet test माध्यम से संचालित था। मुझे लगता है कि यह वीएस 15.9 द्वारा स्थापित किया गया था।

क्या आप ऐसे उपयोगकर्ताओं की उम्मीद करेंगे जिन्हें विशेष रूप से कई और वर्षों के लिए net20 की आवश्यकता है?

मुझे नहीं पता। किस लक्ष्य का उपयोग किया गया है, इसके कोई आंकड़े नहीं हैं। मेरे हिसाब से नेट20 का टारगेट रखने में ज्यादा मेहनत नहीं है। मेरी योजना इसे तब तक छोड़ने की है जब तक कि इसे बनाए रखने में दर्द न हो जाए।