Aspnetcore: चर्चा: ASP.NET Core 3.0 केवल .NET कोर पर चलेगा

मुझे लगता है कि यह अब समग्र चित्र में बहुत मायने रखता है। .NET कोर और ASP.NET Core दोनों अब तक काफी लंबे समय से हैं जो पहले से ही लोगों के पास थे या अभी भी इसे स्विच करने का मौका है, बिना भारी मुद्दों के कारण (जब समर्थन पहले 2.0 के साथ अतीत में गिरा दिया गया था) ।

हालाँकि, मैं ASP.NET कोर के कुछ घटकों के लिए निहितार्थों से दुखी हूं, जो वर्तमान में अलग-अलग निर्भरता के रूप में मौजूद हो सकते हैं। क्योंकि इसका मतलब यह होगा कि व्यक्तिगत घटक नेटस्टेपर समर्थन को छोड़ देंगे, इसके बजाय netcoreapp3.0 की आवश्यकता होगी; और विशेष रूप से # 3756 के साथ उन घटकों को ASP.NET कोर संदर्भ के बाहर अनुपयोगी किया जाएगा।

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

यह बहुत से ऐसे लोगों को छोड़ने जा रहा है जो 3 साल से कम समय में एक असमर्थित प्लेटफॉर्म पर ठंड में बाहर एक समर्थित और सक्रिय रूप से विकसित प्लेटफॉर्म पर रहने के लिए अपने संगठन में नए ASP.NET कोर प्रोग्रामिंग मॉडल की ओर बढ़ रहे हैं। नेट कोर 2.1 एलटीएस)।

मुझे यकीन नहीं है कि आपने इस कदम को सही ठहराने के लिए क्या एनालिटिक्स का उपयोग किया है, लेकिन .NET फ्रेमवर्क पर ServiceStack ASP.NET Core Apps चलाने के लिए हम देख रहे हैं कि ASP.NET Core प्रोजेक्ट को चलाने के लिए सबसे लोकप्रिय वेब-कोरफैक्स टेम्पलेट है .NET फ्रेमवर्क 1/3 (33.8%) से अधिक है, फिर वही खाली वेब टेम्पलेट जो .NET कोर पर चलने के लिए हमारा सबसे लोकप्रिय प्रोजेक्ट टेम्पलेट है।

IMO 3 साल का समय उन ग्राहकों को छोड़ने के लिए पर्याप्त नहीं है, जिन्होंने नए ASP.NET प्रोग्रामिंग मॉडल के लिए शुरुआत की है या करने के लिए कदम रखा है (केवल स्थिर ASP.NET फ्रेमवर्क प्लेटफॉर्म से बचने के लिए) अब यह पता लगाने के लिए कि वे जिस प्लेटफॉर्म को बेच चुके हैं उनके संगठन को स्थानांतरित करने के लिए छोड़ दिया गया है।

जो भी कारण से ऐसे ग्राहक हैं जो .NET फ्रेमवर्क पर निर्भर होने के कारण .NET कोर में नहीं जा सकते हैं, यदि MS ASP.NET Core 3.0 में .NET फ्रेमवर्क के लिए समर्थन बनाए रखना नहीं चाहता है तो भविष्य में IMO आपको समर्थन का विस्तार करना चाहिए .NET फ्रेमवर्क पर ASP.NET कोर 2.1 के लिए 7 साल की तरह विस्तारित अवधि के लिए। मौजूदा उत्पादन प्रणालियों के माइग्रेशन में वर्षों लग सकते हैं। .NET कोर शुरू करने के बाद से यह ASP.NET फ्रेमवर्क को आधिकारिक रुख के साथ स्थिर करने के लिए छोड़ दिया गया है क्योंकि ASP.NET Core .NET के लिए भविष्य का प्रोग्रामिंग मॉडल है, अब वही ग्राहक होंगे जल्द ही यह पता लगाना शुरू कर दिया जाएगा कि नए प्रोग्रामिंग मॉडल जो उन्होंने स्थानांतरित किए हैं / कुछ वर्षों में असमर्थित हो जाएंगे। इन मौजूदा .NET ग्राहकों को समायोजित करने का सबसे अच्छा तरीका है। अतिरिक्त एलटीएस अवधि के लिए .NET 2.1 का समर्थन करना, सुरक्षा पैच के लिए कम से कम (आदर्श रूप से बग को हल करने के लिए)।

"हत्या .NET फ्रेमवर्क", एपिसोड 2: एक ही कहानी, एक ही चरित्र : rofl:

अफसोस की बात है, यह सिर्फ एक बात पर प्रकाश डालता है: आप पूरी तरह से .NET पारिस्थितिकी तंत्र के सामने की कार को मानक बनाने में विफल रहे । यह उतनी तेजी से नहीं चलता है जितना कि यह एक सामान्य सामान्य भाजक से अधिक कुछ नहीं है जो हमेशा बहुत ही अंतिम समय में अपडेट किया जाता है, जब सभी प्लेटफार्मों में नए एपीआई शामिल होते हैं (या शामिल करने वाले होते हैं)।

शायद यह सिर्फ मेरे लिए है, लेकिन मुझे कभी समझ में नहीं आया कि यह netcoreapp रूप में तेज़ी से क्यों नहीं चला (जो परिभाषा के अनुसार, नए एपीआई प्राप्त करने के लिए सबसे पहले है)।

आप एक NuGet पैकेज लेखक हैं और चाहते हैं कि वे नवीनतम सामग्री का उपयोग करें? सबसे हाल के netstandard संस्करण को लक्षित करें: निश्चित रूप से, शुरू में, केवल netcoreapp -आधारित अनुप्रयोग उनका उपयोग करने में सक्षम होंगे, लेकिन अंततः अन्य प्लेटफ़ॉर्म - जैसे Xamarin, मोनो या .NET फ्रेमवर्क - पकड़ लेंगे और लोग आपको कुछ भी बदलने की आवश्यकता के बिना आपके पैकेज का उपयोग करने में सक्षम होंगे। इसी तरह काम करना चाहिए।

बेशक, गैर- .NET कोर प्लेटफ़ॉर्म के लिए कुछ समय लग सकता है। जैसे कि .NET फ्रेमवर्क रिलीज करने के लिए पकड़ता है क्योंकि रिलीज़ दुर्लभ हैं और स्थिरता बार बहुत अधिक है, लेकिन भले ही इसमें 6, 12 या 18 महीने लगते हों, मैं डॉन ' t लगता है कि यह एक समस्या है, क्योंकि .NET फ्रेमवर्क का उपयोग करते समय लोग यही चाहते हैं: एक स्थिर ढांचा, तेज गति से लक्ष्य नहीं।

IMHO, यह ASP.NET Core 3.0 को एक नया netstandard TFM लक्ष्य बनाने के लिए होगा, जो आपके लिए आवश्यक सभी .NET कोर APIs को उजागर करेगा। एक बार जब आप सुनिश्चित कर लेते हैं कि नए एपीआई पर्याप्त रूप से स्थिर हैं, तो उन्हें .NET फ्रेमवर्क में वापस भेज दें ताकि यह नवीनतम मानक के अनुकूल हो।

मुझे यकीन है कि लोग सुपर .NET 3-वर्ष के समर्थन के साथ पुराने संस्करण पर हमेशा के लिए अवरुद्ध होने के बजाय अपने ASP.NET कोर संस्करण को नवीनतम ASP.NET कोर संस्करण में ले जाने में सक्षम होने से पहले कुछ महीने इंतजार करना पसंद करेंगे।

आपने जो वादा किया था उसे करें: .NET फ्रेमवर्क को एक स्थिर ढांचा बनाएं जो ASP.NET कोर की ओर पलायन करने पर उन लोगों के लिए एक मृत अंत के बजाय धीमी गति से विकसित होता है, जिन्होंने आप पर भरोसा किया था।

मुझे यह पसंद नहीं है। .Net कोर की शुरुआत में, माइक्रोसॉफ्ट ने mono या .net framework क्रॉस प्लेटफॉर्म के रूप में नहीं चुना था, और कहा कि वहाँ कई .net रनटाइम हैं इसलिए यू .netstandard डिज़ाइन करते हैं। .net standard केवल नाम में मौजूद होंगे (कम से कम asp.net कोर के लिए, लोग netcoreapp केवल पैकेज बनाना शुरू करते हैं)।
शायद oneday, .net कोर विंडो पर .net फ्रेमवर्क को बदल सकता है, लेकिन मोनो के बारे में क्या है, और अन्य प्लेटफॉर्म मोनो (xamarin, unity3d) पर भरोसा करते हैं।
और कुछ समय के लिए एक और कारण जो मुझे पसंद है। नेट फ्रेमवर्क वह है। नेट कोर शेयर फ्रेमवर्क वास्तव में बहुत बड़ा है, यदि आपके ऐप को .net कोर 2.0 से नवीनतम .net core 2.1 में अपग्रेड करने पर आपका C:/program file/dotnet फोल्डर कितना बड़ा है? मेरे फ़ोल्डर में GBs फ़ाइल है, और यह तब बढ़ता है जब मैं .net कोर रनटाइम अपडेट करता हूं। लेकिन .net फ्रेमवर्क पुराने संस्करण को बदल देगा।

आपने जो वादा किया था उसे करें: .NET फ्रेमवर्क को एक स्थिर ढांचा बनाएं जो ASP.NET कोर की ओर पलायन करने पर उन लोगों के लिए एक मृत अंत के बजाय धीमी गति से विकसित होता है, जिन्होंने आप पर भरोसा किया था।

एफडब्ल्यूआईडब्ल्यू यह इष्टतम रणनीति होगी, एलटीएस को विस्तारित करने का मेरा सुझाव मौजूदा ग्राहकों को अधिक समय देने के लिए न्यूनतम बार है जो कि एएसपी.नेट कोर में माइग्रेट करने के लिए आक्रामक रूप से विपणन किया गया है जिन्हें अब भविष्य में असमर्थित प्लेटफॉर्म पर छोड़ दिया गया है। घोषणा।

तो .net मानक एक मजाक है? आशा है कि मोनो टीम एस्पेनेटकोर रिपोज को फोर्क करेगी और नाम बदलकर एस्पेनेटो को देगी, अन्यथा मैं .net स्टैक छोड़ सकता हूं। '

मुझे लगता है कि इसका मतलब है कि मेरे काम में हम ASP.NET Core का उपयोग कभी नहीं करेंगे। हम ASP.NET पर हमेशा के लिए एक ऐप को कोर में रखने का कभी भी मन नहीं करेंगे क्योंकि अब इसमें और भी बदलाव होंगे।

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

परिवर्तन को बंद किया जा सकता है, लेकिन यह ऐसी चीज नहीं है जिसे आप हमेशा के लिए ले सकते हैं या उससे बचना चाहिए - प्रौद्योगिकी _is_ परिवर्तन और एक डेवलपर की नौकरी को हमेशा नई चीजें सीखने की आवश्यकता होगी। यदि आप आज .NET फ्रेमवर्क पर ASP.NET Core का उपयोग कर रहे हैं, तो इसे .NET Core में स्थानांतरित करने के लिए तीन साल का काम लेने की संभावना नहीं है।

.NET Core में आएं, पानी की गर्माहट ...

जो भी कारण ऐसे ग्राहक हैं जो .NET फ्रेमवर्क पर निर्भर होने के कारण .NET कोर में नहीं जा सकते हैं केवल निर्भरता ...

अधिक गंभीर रूप से, आप .NET मानक 2.0 के बाद से .NET कोर 2.0 पर .NET 4.x पुस्तकालयों का उपयोग कर .NET कोर के लिए विंडोज कम्पेटिबिलिटी पैक है जो इन छेदों को बहुत अधिक प्लग करता है और कई और फीचर्स .NET कोर 3.0 में समर्थित हैं जिनमें COM इंटरॉप और अन्य ऐप मॉडल जैसे WinForms और WPF आदि शामिल हैं।

.NET फ्रेमवर्क से .NET कोर पर जाने वाले ASP.NET Core एप्लिकेशन को रोकने वाले किसी भी ब्लॉकर्स को शायद डॉटनेट / कोरफैक्स में उठाया जाना चाहिए।

ज़मीरिन के लिए; मैं गलत हो सकता है, लेकिन मुझे लगता है कि आप इसका इस्तेमाल iOS या Android पर वेबसर्वर चलाने के लिए नहीं करेंगे।

मोनो क्लाइंट ऐप्स के लिए वेबसर्वर प्रक्रिया से बाहर हो सकता है और .NET कोर पर चल सकता है जबकि मोनो में UI चलता है। Kestrel कभी भी बिग एंडियन प्लेटफॉर्म पर नहीं चल सका है जो मोनो के कुछ अन्य प्लेटफॉर्म को काटता है हालांकि बीएसडी फ्लेवर वर्तमान में एक .NET कोर गैप है।

एकता के लिए; खेल सभी प्रकार की अजीब चीजें करते हैं, इसलिए हो सकता है कि एक परिदृश्य कवर न हो; यदि खेल ग्राहक में वेबसर्वर का उपयोग कर रहा था; बजाय एक सर्वर पर या खरीद से बाहर; जब .NET Core उस हिस्से को चला सकता है।

ASP.NET कोर ऐप मॉडल के बाहर; पुस्तकालयों के लिए। .NET मानक अधिक महत्वपूर्ण है क्योंकि ASP.NET कोर में सभी प्रकार की उपयोगी विशेषताएं हैं, रेजर एक विशेष उदाहरण है।

सभी पुस्तकालयों केवल .NET कोर पर नहीं जा रहे हैं (जैसे Microsoft.Extensions.* .NET मानक के रूप में रह रहे हैं) और यह संभवतः उन विशिष्ट परिदृश्यों को प्रदान करने में सहायक होगा जो कि प्रभावित होंगे जैसा कि @daveaglick ने https: // में किया है।

ASP.NET Core .NET कोर में बहुत से बदलाव और नई एपिस चला रहा है और मैं तब उन सुविधाओं का उपयोग करने की इच्छा को समझ सकता हूं (क्योंकि यह उनके उपयोग के मामलों में से एक था); अन्यथा यह थोड़ा आत्म-पराजित है।

दूसरी ओर यह अच्छा होगा यदि वे एक .NET मानक संस्करण में भी थे तो अन्य रनटाइम्स ASP.NET Core 3.0 का समर्थन कर सकते हैं जब वे इसे लागू करने के लिए चारों ओर हो जाते हैं। वास्तविक रूप से यह जल्द ही नहीं होगा (क्योंकि .NET मानक 2.1 को अभी तक अंतिम रूप नहीं दिया गया है और इसके आगे एक संस्करण होने की आवश्यकता होगी)।

शायद ASP.NET कोर ऐप मॉडल बाद की तारीख में .NET मानक पर वापस आ जाएगा जब चीजें पकड़ी जाती हैं? हालाँकि यह हमेशा .NET मानक प्रक्रिया के लिए बहुत तेजी से आगे बढ़ सकता है क्योंकि यह वर्तमान में काम करता है?

@gulbanana। कॉम का उपयोग करने पर आपके asp.net कोर पर क्या होगा? या वहाँ एक nuget पैकेज है जो केवल .net फ्रेमवर्क का समर्थन करता है?

मेरा मानना ​​है कि यह कभी भी सवाल नहीं था कि यह कदम उठाया जाना चाहिए या नहीं, लेकिन केवल जब।
पिछली बार इसने एक ~ चर्चा ~ shitstorm के कारण, पारिस्थितिकी तंत्र मौजूदा एप्लिकेशन को पोर्ट करने की अनुमति देने के लिए तैयार नहीं था।
अब विंडोज़ संगतता पैकेज हैं और WinForms और WPF .NET कोर पर आ रहे हैं।

मुझे लगता है कि .NET फ्रेमवर्क के लिए आसपास के 2.1 पैकेज एक अच्छा माइग्रेशन पथ प्रदान करते हैं: नेटफैक्स पर 2.1 पर माइग्रेट करें और फिर .NET कोर पर।

यह AngularJS बनाम Angular के समान है: नवीनतम 1. * में मौजूदा कोड को कंपोनेंट (हार्ड) में माइग्रेट करें, फिर लेट्स को Angular वर्जन में ले जाएं। यह सुपर कठिन है, लेकिन उल्लेखनीय है।

CoreCLR और मोनो दोनों के लिए रोमांचक नई सुविधाओं को जोड़ा जा रहा है (उदाहरण के लिए डिफ़ॉल्ट इंटरफ़ेस विधियाँ या सिर्फ तेज़ स्पैनs) जो इसे .NET फ्रेमवर्क के लिए कभी नहीं बनाएगा, कुछ बिंदु पर .NET फ्रेमवर्क को पीछे छोड़ना उचित होगा।
जरूरी नहीं कि इसका अर्थ ".NET फ्रेमवर्क का समर्थन नहीं करना" है, बल्कि इसे जैसा है वैसा ही छोड़ना है।

अभी भी कुछ साइटें हैं जो क्लासिक ASP (ASP.NET का उपयोग नहीं करती हैं, लेकिन वास्तव में पुराना सामान हैं)। यह अभी भी विंडोज में काम करता है और जहाज करता है, आप इसके साथ नए ऐप नहीं बनाएंगे।
मेरा मानना ​​है कि <10 साल में, यह .NET फ्रेमवर्क के साथ स्थिति हो सकती है।

मैं 2.1 के लिए अनुरोधित विस्तारित समर्थन से सहमत हूं, लेकिन मैं चाहूंगा कि टीम 2-3 वर्षों में निर्णय लेने के लिए 2.1 पैकेज डाउनलोड की निगरानी करे, यदि उन्हें समर्थन की आवश्यकता होगी (= महत्वपूर्ण सुरक्षा मुद्दों को ठीक करें) थोड़ी देर और।

@ John0King COM को .NET Core 3.0 में सपोर्ट किया जाएगा।

इसके अलावा: हमारे पास .NET रीमोटिंग जैसी चीजों का उपयोग करके विरासत अनुप्रयोग हैं।
लेकिन वे विरासत पहले से ही हैं।

दुनिया मूल रूप से विरासत कोड पर चलती है और ऐसा करना जारी रखेगी। यह एक व्यावसायिक निर्णय है कि किसी चीज़ को "समर्थित" या यहाँ तक कि "नई" चीज़ में पोर्ट करना है या नहीं, लेकिन तब तक, जब तक @dylanbeattie इसे डालता है:

हाँ, यह ध्यान देने योग्य है कि क्या कुछ "समर्थित" है वह सब प्रासंगिक नहीं है - पुराने ऐप को वास्तव में एक नए ढांचे में पोर्ट नहीं किया जाना है क्योंकि यह उपलब्ध है। वेब सर्वर सुरक्षा के खतरों के कारण एक विशेष मामले के एक बिट हैं। एलटीएस के लिए सुरक्षा पैच समर्थन की एक लंबी अवधि लोगों को बाहर निकालने में मदद करेगी।

@gulbanana यह केवल System.Web से ASP.NET Core में एप्लिकेशन को पोर्ट करने के लिए एक उच्च बार जोड़ रहा है, क्योंकि आपको वेब फ्रेमवर्क, अंतर्निहित एप्लिकेशन फ्रेमवर्क को बदलने और फिर किसी असंगत निर्भरता को अपग्रेड या स्वैप करने की आवश्यकता है (जिसमें नया खरीदना शामिल हो सकता है) लाइसेंस)।

यदि आप एक लागत / लाभ विश्लेषण करते हैं, तो मुझे यकीन नहीं है कि यह ASP.NET कोर के लाभ में होगा।

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

यदि आप एक लागत / लाभ विश्लेषण करते हैं, तो मुझे यकीन नहीं है कि यह ASP.NET कोर के लाभ में होगा।

तो .. अच्छा .. छोड़ो? यदि आपको ASP.NET Core में माइग्रेट करने की आवश्यकता नहीं है, तो इसे न करें ..
व्यंग्यात्मक या कुछ भी करने की कोशिश नहीं कर रहा है, लेकिन अगर कोई व्यवसाय "नवीनतम चीजों" पर आवेदन रखने की आवश्यकता नहीं है, तो इसे पोर्ट न करें। लाभ यह है कि .NET फ्रेमवर्क / ASP.NET क्लासिक अभी भी समर्थित है और आपका एप्लिकेशन जैसा है वैसा ही चलेगा।

पोर्टिंग अक्सर बेकार है, मैं मानता हूं - ASP.NET से ASP.NET Core एक बड़ा बदलाव है, और उस बदलाव का एक हिस्सा यह है कि कोर अधिक तेजी से चलता है (3.0 में एपीआई ब्रेकिंग परिवर्तन भी होंगे, जैसा कि 2.0 था)। इस चर्चा मुद्दा corefx परिवर्तन, हालांकि, और सबसे ASP.NET मुख्य ऐप्स के लिए करने के लिए netfx कि एक बड़ा परिवर्तन अब और नहीं है के बारे में है,

यह "ASP.NET Core on .NET Framework" मध्यवर्ती बिंदु को हटाने के लिए लगता है जो पलायन को बहुत अधिक क्रमिक और आसान बना देगा। इसके बाद, ASP.NET MVC / WebAPI / etc को माइग्रेट करना। ASP.NET कोर के लिए एप्लिकेशनटोन एक बहुत बड़ा धमाकेदार बदलाव होगा, जो वेब फ्रेमवर्क और अंतर्निहित रनटाइम दोनों को एक साथ बदल देगा।

बड़े एंटरप्राइज़ ऐप के लिए मुझे उम्मीद है कि यह काफी दर्दनाक होगा। मेरी टीम एक या दो साल से इसे करीब से देख रही है, लेकिन:

• EntityFrameworkCore को हमारी आवश्यकता के अनुसार सब कुछ नहीं करना है, और केवल .NET कोर 3.0 के साथ अब EntityFramework ही .NET कोर पर आ रहा है। यह कितना और किन प्लेटफार्मों पर चलेगा, मुझे विश्वास नहीं है कि स्पष्ट रूप से संचार किया गया है, और मुझे शायद देखने के लिए पूर्वावलोकन पूर्वावलोकन का परीक्षण करना होगा।

• बड़े पैमाने के अनुप्रयोगों के मामले में अभी भी ओडटा की कहानी हवा में उठ रही है। OData 3 / System.Data.Services से OData 4 / WebAPI और उसके बाद स्थानांतरित करने के लिए आवश्यक (_-) कार्य का _substantial_ राशि है। यह कुछ ऐसा है जिसे कई वर्षों से हल नहीं किया गया है, और मुझे यकीन है कि यह कभी नहीं होगा।

इसके अतिरिक्त, अब हमें अन्य सभी असमर्थित तकनीकों (AppDomains, Remoting, आदि) से ट्रिम करना होगा, बजाय इसके कि समानांतर में या बाद के चरण में उस काम को करने में सक्षम होने के बजाय _first_।

इसके अतिरिक्त, अब हमें अन्य सभी असमर्थित तकनीकों (AppDomains, Remoting, आदि) को पहले ट्रिम करना होगा, बजाय इसके कि वह समानांतर या बाद के चरण में उस काम को करने में सक्षम हो।

आप पहले 2.1 में माइग्रेट क्यों नहीं कर सकते?

@davidfowl हम शायद एक मध्यस्थ के रूप में उपयोग कर सकते हैं, जब तक कि हम 3.0 / 3.1 / आदि में कुछ नई सुविधा नहीं देते। कि हमें प्रवास करने की आवश्यकता है। मैंने अभी तक एक पूर्ण विश्लेषण नहीं किया है, हम ज्यादातर ईएफ और ओडटा पर अब तक अवरुद्ध हैं।

ASP.NET Core 2.1 में नई सुविधा जो माइग्रेट करने के लिए आवश्यक है? मैं .NET फ्रेमवर्क पर ASP.NET Core 2.1 का मतलब था।

जब यह मुद्दा कुछ साल पहले आया था, तो मुझे याद आया कि शिकायत करना बहुत मुश्किल था। यहाँ एक पुराने गितुब टिप्पणी का एक उद्धरण है जो मैंने वापस किया है:

वेब निर्देशिका की कल्पना करें, जो सक्रिय निर्देशिका या कार्यालय COM स्वचालन का उपयोग करते हैं, या जो कुछ System.Drawing आधारित पुस्तकालय का उपयोग करके थंबनेल करते हैं, या WPF ऐप के साथ कोड साझा करते हैं

अच्छी बात यह है कि .NET कोर 3.0 के रूप में, उन सभी परिदृश्यों का समर्थन किया जाता है। इसे आसान बनाने के लिए भारी मात्रा में काम किया गया है।

@davidfowl मैंने किया।

Hypothetically कुछ ऐसी सुविधा हो सकती है जिसका उपयोग हम ASP.NET/MVC/WebAPI में कर रहे हैं जो 2.1 में लागू नहीं है लेकिन बाद के संस्करण में आता है। उस स्थिति में, 2.1 एक व्यावहारिक कदम नहीं होगा।

मुझे एक अधिक गहन विश्लेषण करना होगा, हालांकि यह देखने के लिए कि वास्तव में कुछ भी महत्वपूर्ण है जिसकी हमें 2.1 में आवश्यकता नहीं है।

@PinpointTownes

अफसोस की बात है, यह सिर्फ एक बात पर प्रकाश डालता है: आप पूरी तरह से .NET पारिस्थितिकी तंत्र के सामने की कार को मानक बनाने में विफल रहे । यह उतनी तेजी से नहीं चलता है जितना कि यह एक सामान्य सामान्य भाजक से अधिक कुछ नहीं है जो हमेशा बहुत ही अंतिम समय में अपडेट किया जाता है, जब सभी प्लेटफार्मों में नए एपीआई शामिल होते हैं (या शामिल करने वाले होते हैं)।

आप गलत नहीं हैं, लेकिन आप .NET मानक के लक्ष्यों से कुछ अनभिज्ञ हैं। मानक का लक्ष्य कभी भी नवाचार को चलाने के लिए नहीं है, बल्कि अभिसरण ड्राइव करने के लिए है। यदि आप इसे उस कोण से संपर्क करते हैं, तो यह एक ऐसी चीज़ है जिसे डिज़ाइन करना है, क्योंकि यह पीछे है क्योंकि हमें यह सोचना होगा कि कौन सी अवधारणाएँ सार्वभौमिक हो सकती हैं या यहां तक ​​कि सार्वभौमिक भी होनी चाहिए। यदि आप उत्सुक हैं कि यह कैसा दिखता है, तो मैं आपको सभी .NET कार्यान्वयन मालिकों द्वारा समीक्षा के बाद पिछले तीन हफ्तों में विलय किए गए 35+ पीआर पर एक नज़र डालने के लिए आमंत्रित करता हूं।

हम .NET कोर को अत्याधुनिक मंच के रूप में देखते हैं जहां नवाचार होता है। हमने कई क्षमताओं का निर्माण किया है जो हमें मंथन और जोखिमों से निपटने की अनुमति देते हैं जो .NET फ्रेमवर्क की तुलना में बहुत बेहतर हैं। हालाँकि, .NET ईकोसिस्टम के लिए मायने रखने वाली सभी क्षमताएं .NET कोर अनुभव का हिस्सा नहीं हैं। उदाहरण के लिए, आगे का संकलन ज़ामरीन और यूनिटी पर अधिक प्रमुख है। और जब हम .NET कोर सुविधाएँ लेते हैं और उन्हें मानक में जोड़ते हैं, तो हमें उनके रनटाइम वातावरण, ऑपरेटिंग सिस्टम और हार्डवेयर बाधाओं पर विचार करने की आवश्यकता होती है।

शायद यह सिर्फ मेरे लिए है, लेकिन मुझे कभी समझ में नहीं आया कि यह netcoreapp रूप में तेज़ी से क्यों नहीं चला (जो परिभाषा के अनुसार, नए एपीआई प्राप्त करने के लिए सबसे पहले है)।

वास्तविकता यह है कि "तेजी से और टूटती चीजें" कुछ ऐसा नहीं है जो हमारे पूरे दर्शकों की सराहना करता है। यह काफी बुरा है अगर हमें .NET कोर के प्रमुख संस्करणों में एपीआई को निकालना है लेकिन .NET मानक के साथ ऐसा करना लगभग असंभव है। इसलिए हमें कुछ धीमी गति से आगे बढ़ना होगा और केवल उन अवधारणाओं को शामिल करना चाहिए जिनके बारे में हमारा मानना ​​है कि इसके अलावा पर्याप्त परिपक्व हैं।

आपने जो वादा किया था उसे करें: .NET फ्रेमवर्क को एक स्थिर ढांचा बनाएं जो ASP.NET कोर की ओर पलायन करने पर उन लोगों के लिए एक मृत अंत के बजाय धीमी गति से विकसित होता है, जिन्होंने आप पर भरोसा किया था।

यह अभी भी यह धारणा बनाता है कि .NET फ्रेमवर्क को अंततः सभी सुविधाएँ मिलेंगी। .NET कोर में समय की देरी है। हमने सीखा कि यह वास्तविक नहीं है। हम या तो .NET कोर में अत्यधिक नवाचार नहीं करने का निर्णय ले सकते हैं या इंजीनियरिंग वास्तविकता को स्वीकार कर सकते हैं कि नई सुविधाओं का एक अच्छा हिस्सा कभी भी .NET फ्रेमवर्क में वापस नहीं आएगा। हमारा मानना ​​है कि हम अपने ग्राहकों को .NET फ्रेमवर्क के कोर वैल्यू प्रोप (एक परिपक्व और समृद्ध विकास मंच) को संरक्षित करने के लिए सबसे अच्छी सेवा देते हैं, जबकि ग्राहकों को .NET कोर पर नई क्षमताओं का दोहन करने की भी अनुमति देते हैं। आगे बढ़ते हुए, मैं उम्मीद करूँगा कि हम उन क्षेत्रों में नया करने के लिए और अधिक तैयार होंगे जिन्हें रनटाइम, लाइब्रेरी और भाषा परिवर्तन की आवश्यकता है जैसे हमने Span<T> । जबकि ये चीजें महंगी हैं, वे हमें लोगों को कोड लिखने के तरीके को बदलने की भी अनुमति देते हैं। इसका एक अच्छा उदाहरण इंटरफेस का डिफ़ॉल्ट कार्यान्वयन है, लेखक जेनेरिक कोड को समाहित करने की क्षमता, हार्डवेयर इंट्रिंसिक्स आदि का उपयोग करने में सक्षम है और उन सुविधाओं की संभावना बिल्कुल उसी तरह है जैसे हम जोखिम के कारण .NET फ्रेमवर्क में वापस नहीं जा रहे हैं। ।

मुझे लगता है कि यह हमारे वेब स्टैक के लिए इन क्षमताओं का फायदा उठाने में सक्षम होने के लिए कुल समझ में आता है; और ऐसा करने का एकमात्र तरीका .NET फ्रेमवर्क पर चलने के लिए ASP.NET Core के लिए सीमा को हटाना है। ध्यान रखें कि हमने .NET फ्रेमवर्क पर ASP.NET Core रन बनाने का मूल कारण था। .NET कोर में बस पर्याप्त API नहीं थे। .NET Core 3.0 में हमारे पास मौजूदा API के 120k से अधिक होंगे। यह पूरे .NET फ्रेमवर्क के आधे से अधिक है और यहां तक ​​कि WinForms और WPF भी शामिल है। हां, अभी भी बड़ी संख्या में एपीआई मौजूद हैं जो गायब हैं, लेकिन हमने लंबी पूंछ में भारी अशुद्धि बना ली है। जबकि हमारे पास कभी भी 100% समानता नहीं होगी, मैं उम्मीद करता हूं कि ग्राहक डेटा के आधार पर हम इस अंतर को और भी अधिक आगे बढ़ा सकते हैं।

@ याकोव-एच मुझे आश्चर्य होगा अगर ऐसा ही होता। जब आप विश्लेषण करते हैं, तो मुझे बताएं।

आप गलत नहीं हैं, लेकिन आप .NET मानक के लक्ष्यों से कुछ अनभिज्ञ हैं। मानक का लक्ष्य कभी भी नवाचार को चलाने के लिए नहीं है, बल्कि अभिसरण ड्राइव करने के लिए है।

और आप बिलकुल विपरीत दिशा की ओर जा रहे हैं: ASP.NET Core के लिए .NET मानक को त्यागना क्योंकि यह बहुत तेज़ी से नहीं चलता है, मजबूरन NuGet संकुल को ASP.NET Core को लक्षित करते हुए इसे भी छोड़ देना पड़ा। मुझे मत समझो कि यह अभिसरण है, मैं वह अज्ञानी नहीं हूँ : rofl:

यदि आप इसे उस कोण से संपर्क करते हैं, तो यह एक ऐसी चीज़ है जिसे डिज़ाइन करना है, क्योंकि यह पीछे है क्योंकि हमें यह सोचना होगा कि कौन सी अवधारणाएँ सार्वभौमिक हो सकती हैं या यहां तक ​​कि सार्वभौमिक भी होनी चाहिए।

यह एक विकल्प है, न कि एक तकनीकी समस्या: कुछ भी आपको यह निर्धारित करने से रोकता है कि कोर एफएक्स / कॉर्क्लर में शामिल करने के लिए किसी दिए गए एपीआई को .NET मानक के नए संस्करण में शामिल किया जाना चाहिए या नहीं।

यदि आप उत्सुक हैं कि यह कैसा दिखता है, तो मैं आपको सभी .NET कार्यान्वयन मालिकों द्वारा समीक्षा के बाद पिछले तीन हफ्तों में विलय किए गए 35+ पीआर पर एक नज़र डालने के लिए आमंत्रित करता हूं।

मैं यह नहीं कह रहा हूं कि यह एक आसान काम है और यह मेरी बात साबित करता है: आप बहुत अधिक प्रतीक्षा कर रहे हैं कि आप netstandard संस्करण और आपके द्वारा किया गया दुर्लभ समय, यह एक दर्दनाक प्रक्रिया है क्योंकि यह टन के साथ आता है एक ही समय में नए एपीआई।

वास्तविकता यह है कि "तेजी से और टूटती चीजें" कुछ ऐसा नहीं है जो हमारे पूरे दर्शकों की सराहना करता है।

फिर भी यह ठीक है कि हर ASP.NET कोर इटरेशन कैसे काम करता है: यह (कभी-कभी बड़े पैमाने पर) ब्रेकिंग परिवर्तनों के साथ आता है जो एक संस्करण के लिए लिखे गए पैकेजों को अगले लोगों के साथ असंगत बनाते हैं। फिर भी, आप हमें कई विकल्प नहीं देते हैं: एक समर्थन नीति के साथ, जो हमारे पास कुछ भी नहीं है, के साथ हमेशा के लिए अद्यतन करना या विरासत संस्करणों पर रहना (यह सिर्फ ASP.NET/.NET नहीं है, विंडोज का जीवनचक्र भी बहुत अधिक है इन दिनों कम)।

आगे बढ़ते हुए, मैं उम्मीद करता हूँ कि हम उन क्षेत्रों में नया करने के लिए अधिक इच्छुक होंगे जिन्हें रनटाइम, लाइब्रेरी और भाषा परिवर्तन की आवश्यकता होती है जैसे कि हमने स्पैन के लिए किया था।। जबकि ये चीजें महंगी हैं, वे हमें लोगों को कोड लिखने के तरीके को बदलने की भी अनुमति देते हैं। इसका एक अच्छा उदाहरण इंटरफेस का डिफ़ॉल्ट कार्यान्वयन है, लेखक जेनेरिक कोड को समाहित करने की क्षमता, हार्डवेयर इंट्रिंसिक्स आदि का उपयोग करने में सक्षम है और उन सुविधाओं की संभावना बिल्कुल उसी तरह है जैसे हम जोखिम के कारण .NET फ्रेमवर्क में वापस नहीं जा रहे हैं। ।

आपको एक नया साइड-बाय-साइड .NET फ्रेमवर्क संस्करण पेश करने से रोकता है (मान लीजिए कि .NET फ्रेमवर्क 5) जिसमें "जोखिम भरा" परिवर्तन शामिल हैं? फिर, यह कोई तकनीकी समस्या नहीं है।

Microsoft.AspNetCore.Razor.Language और Microsoft.AspNetCore.Razor aspnet बाहर प्रचार करने का कोई भी मौका या netstandard लहर पर रखने का कोई मौका? हालांकि रेजर सिर्फ html के लिए है लेकिन कई लाइब्रेरी हैं जो इसे मेल टेम्प्लेट के लिए उपयोग करते हैं और यह बहुत अच्छा होगा यदि हम इसका उपयोग कर सकते हैं।

यह कदम .NET रोडमैप में netstandard के लिए समर्थन की कमी दर्शाता है, जो पहले बताए गए हैं। यदि मुख्य नए पुस्तकालयों में से एक निवल को छोड़ देता है, तो यह अपने गोद लेने के लिए अच्छी तरह से नहीं झुकता है।

क्या यह एक चाल है जो अब .NET डेवलपर्स को खुले में Microsoft द्वारा विकसित अन्य सभी नए पुस्तकालयों के लिए पूर्वानुमानित करना चाहिए? क्या नेटवर्थ के भविष्य और इसके अपनाने पर समुदाय को अधिक आधिकारिक बयान मिल सकता है?

@terrajobst मैं पूरी तरह से समझता हूं कि आप उन API को जोड़ने से संबंधित नहीं हैं जो उन APIs को जोड़ते हैं जो सभी प्लेटफार्मों को पूरा करने के लिए तैयार नहीं हैं (और संभवतः कभी भी नहीं होगा)। हालाँकि, जब आपने (MS) को netstandard2.0 शुरू करने से नहीं रोका था, उदाहरण के लिए, UWP इसका समर्थन करने के लिए तैयार नहीं था। जैसा कि मैं समझता हूं, कुछ समय बाद उस समर्थन को जोड़ने के लिए ध्यान देने योग्य प्रयास किया, लेकिन आपने ऐसा किया। क्या वह किसी तरह एक अलग कहानी थी?

और आप बिल्कुल विपरीत दिशा की ओर जा रहे हैं: ASP.NET कोर के लिए .NET मानक को छोड़ देना क्योंकि यह काफी तेजी से आगे नहीं बढ़ता है।

ASP.NET Core केवल .NET फ्रेमवर्क और .NET कोर पर समझ में आता है, लेकिन .NET मानक को सभी के द्वारा लागू किया जाना है। यह केवल उदाहरण के लिए समझ में नहीं आता है, Xamarin / Unity API प्रदान करते हैं जो मुख्य रूप से एक गंभीर वेब स्टैक द्वारा उपयोग किया जाता है।

यह एक विकल्प है, न कि एक तकनीकी समस्या: कुछ भी आपको यह निर्धारित करने से रोकता है कि कोर एफएक्स / कॉर्क्लर में शामिल करने के लिए किसी दिए गए एपीआई को .NET मानक के नए संस्करण में शामिल किया जाना चाहिए या नहीं।

हमने .NET कोर v1 दिनों में यही किया है। हमने v2 के साथ .NET कोर से मानक को अलग कर दिया है। तो हाँ, यह एक विकल्प है, लेकिन यह एक मनमाना नहीं था। लक्ष्य .NET कोर के साथ तेजी से आगे बढ़ने में सक्षम था। केवल यह विचार करने में अधिक समय लगता है कि एक एकल की तुलना में एन अन्य रनटाइम के संदर्भ में कैसे काम करता है।

यह एक दर्दनाक प्रक्रिया है क्योंकि यह एक ही समय में नए एपीआई के टन के साथ आता है।

यह एक दर्दनाक प्रक्रिया नहीं है क्योंकि आपको कई कार्यान्वयनकर्ताओं और कई अलग-अलग रनटाइम के साथ डिज़ाइन की समीक्षा करनी होगी। हालांकि, इस तथ्य के बाद ऐसा करना, एकत्रित और बंडल करना समन्वयित होने की तुलना में बहुत सस्ता है जैसा कि हम जाते हैं। CoreFx रेपो एक उच्च मात्रा वाला रेपो है। फायरहॉज़ से पीने की तुलना में बंडल किए गए फीचर्स की समीक्षा करना और CoreFx पर सभी API चर्चाओं की सदस्यता लेने के लिए Xamarin और Unity के लिए बहुत आसान है।

फिर भी यह ठीक है कि हर ASP.NET कोर इटरेशन कैसे काम करता है: यह (कभी-कभी बड़े पैमाने पर) ब्रेकिंग परिवर्तनों के साथ आता है जो एक संस्करण के लिए लिखे गए पैकेजों को अगले लोगों के साथ असंगत बनाते हैं।

और क्योंकि आप इसे पसंद नहीं करते हैं। आप इसे .NET स्टैंडर्ड मैच .NET कोर बनाकर सभी पर थोपना चाहते हैं? क्षमा करें, लेकिन इस तर्क से मुझे कोई मतलब नहीं है।

आपको एक नया साइड-बाय-साइड .NET फ्रेमवर्क संस्करण पेश करने से रोकता है (मान लीजिए कि .NET फ्रेमवर्क 5) जिसमें "जोखिम भरा" परिवर्तन शामिल हैं? फिर, यह कोई तकनीकी समस्या नहीं है।

क्या आपको लगता है कि यह एक तकनीकी मुद्दा नहीं है? .NET फ्रेमवर्क के साइड-बाय-साइड संस्करण शिपिंग योग्य समाधान नहीं है। सबसे पहले, यह इस तथ्य के कारण काफी महंगा है कि यह एक ओएस घटक है और इस प्रकार इसे सेवित करने की आवश्यकता है। आपको पता नहीं है कि .NET फ्रेमवर्क 3.5 और 4.x के लिए हमारी ब्रांचिंग / सर्विसिंग / पैचिंग रणनीति कितनी जटिल है। एक तीसरा जोड़ना अव्यवहारिक के करीब है। दूसरी बात, बस ऐसा करना भी जोखिम है, क्योंकि हमें सक्रियण में बदलाव करने की आवश्यकता है ताकि COM सक्रिय अन्य घटकों जैसी चीजों के लिए सही क्रम का चयन करें। और यह सवाल है कि हम साथ-साथ और साथ-साथ कितने संयोजनों का समर्थन करते हैं या नहीं। यह एक सरल कार्य नहीं है और जोखिम से मुक्त भी नहीं है।

मुझे मत समझो कि यह अभिसरण है

@PinpointTownes यह .NET कोर

यह केवल उदाहरण के लिए समझ में नहीं आता है, Xamarin / Unity API प्रदान करते हैं जो मुख्य रूप से एक गंभीर वेब स्टैक द्वारा उपयोग किया जाता है।

ऐसे लोग हैं जो ASP.NET Core का उपयोग न केवल .NET कोर पर करना चाहते हैं, बल्कि UWP पर भी करना चाहते हैं, तो Xamarin पर भी क्यों नहीं? https://aspnet.uservoice.com/forums/41199-general-asp-net/suggestions/32626766-support-for-asp-net-core-running-on-uwp-as-windows

आप के लिए कोई मतलब नहीं है कि कुछ के बीच एक अंतर है - और कुछ आप का समर्थन नहीं करना चाहते हैं।

CoreFx रेपो एक उच्च मात्रा वाला रेपो है। फायरहॉज़ से पीने की तुलना में बंडल किए गए फीचर्स की समीक्षा करना और CoreFx पर सभी API चर्चाओं की सदस्यता लेने के लिए Xamarin और Unity के लिए बहुत आसान है।

क्या मैंने ऐसा चरम दृष्टिकोण सुझाया? मुझे यकीन है कि आपके द्वारा .NET कोर में पेश किए जाने के कुछ समय बाद (जैसे कुछ सप्ताह) नए मानक एपीआई पर चर्चा करने के बाद, आप एक समझौता पा सकते हैं, एक बार धूल थोड़ा जमने के बाद।

और क्योंकि आप इसे पसंद नहीं करते हैं। आप इसे .NET स्टैंडर्ड मैच .NET कोर बनाकर सभी पर थोपना चाहते हैं? क्षमा करें, लेकिन इस तर्क से मुझे कोई मतलब नहीं है।

आप मानते हैं कि मुझे यह पसंद नहीं है, लेकिन आप गलत हैं: मुझे तेज गति वाली चीजें पसंद हैं - भले ही 60 NuGet पैकेज के अनुरक्षक के रूप में यह कभी-कभी बहुत दर्दनाक हो। मुझे जो पसंद नहीं है वह सभी को उसी गति से आगे बढ़ने के लिए मजबूर कर रहा है, सड़क के बीच में लोगों को छोड़ देना क्योंकि वे नहीं रख सकते।

मुझे यकीन नहीं है कि कैसे .NET मानक के रूप में उपवास के रूप में तेज कदम। .NET कोर को सजा के रूप में देखा जा सकता है: कुछ भी नहीं आपको नवीनतम netstandard TFM को लक्षित करने के लिए मजबूर करता है। आप केवल ऐसा करेंगे यदि आपको नवीनतम एपीआई सेट की आवश्यकता है। यदि आपको इसकी आवश्यकता नहीं है, तो एक पुराने संस्करण को लक्षित करें ताकि आपके पैकेज प्लेटफ़ॉर्म के व्यापक सेट द्वारा उपयोग किए जा सकें।

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

सबसे पहले, यह इस तथ्य के कारण काफी महंगा है कि यह एक ओएस घटक है और इस प्रकार इसे सेवित करने की आवश्यकता है। आपको पता नहीं है कि .NET फ्रेमवर्क 3.5 और 4.x के लिए हमारी ब्रांचिंग / सर्विसिंग / पैचिंग रणनीति कितनी जटिल है। एक तीसरा जोड़ना अव्यवहारिक के करीब है।

मैं निश्चित रूप से कल्पना कर सकता हूं कि यह आपके लिए आदर्श नहीं है, जैसे ASP.NET Core 3.0 के लिए .NET फ्रेमवर्क सपोर्ट को हटाना उन लोगों के लिए आदर्श नहीं है जो .NET कोर में नहीं जा सकते। लेकिन क्या मैं आपको पूरी तरह से गलत समझ रहा हूँ - Microsoft - के पास इससे निपटने के लिए और अधिक संसाधन हैं। औसत कंपनी की तुलना में .NET कोर में जाना है? (मैं बाहरी निर्भरता के बारे में भी बात नहीं कर रहा हूं जो आपके पास नहीं है और नियंत्रण नहीं है)।

दूसरी बात, बस ऐसा करना भी जोखिम है, क्योंकि हमें सक्रियण में बदलाव करने की आवश्यकता है ताकि COM सक्रिय अन्य घटकों जैसी चीजों के लिए सही क्रम का चयन करें। और यह सवाल है कि हम साथ-साथ और साथ-साथ कितने संयोजनों का समर्थन करते हैं या नहीं। यह एक सरल कार्य नहीं है और जोखिम से मुक्त भी नहीं है।

यकीन है, यह आसान नहीं है। और यह जोखिम भरा है। लेकिन यह है कि प्रमुख संस्करण क्या संकेत देते हैं: जोखिम वाली चीजें टूट सकती हैं। अब, ASP.NET Core 2.2 पर हमेशा के लिए रहने के लिए मजबूर होने और ASP.NET Core 3.0 का उपयोग करने के लिए .NET फ्रेमवर्क 5 में जाने के लिए जोखिम लेने के बीच, आपको क्या लगता है कि लोग इसका विकल्प चुनेंगे?

लेकिन क्या मैं आपको पूरी तरह से गलत समझ रहा हूँ - Microsoft - के पास इससे निपटने के लिए और अधिक संसाधन हैं। औसत कंपनी की तुलना में .NET कोर में जाना है?

मेरे अनुभव में लोग लगातार यह अनुमान लगाते हैं कि हमारे पास कितने संसाधन हैं और अकेले यथास्थिति का समर्थन करने के लिए हमारे पास कितने संसाधन हैं।

लेकिन इस मामले में यह संसाधनों का मामला भी नहीं है। हमारे पास बस खुले हुए .NET फ्रेमवर्क हो सकते हैं और फिर सभी पीआरओ सीधे .NET फ्रेमवर्क में चले जाएंगे। यह मशीनरी और जटिलता के जोखिम के साथ करना है। यह एक केंद्रीकृत ढांचा है और यहां तक ​​कि साइड रिलीज भी संसाधनों का एक सामान्य सेट साझा करता है, जैसे सक्रियण। हम बार-बार गलत साबित हुए हैं कि हम स्मार्ट लोगों को बता सकते हैं कि यह सही तरीके से सामने आया है।

अब, ASP.NET Core 2.2 पर हमेशा के लिए रहने के लिए मजबूर होने और ASP.NET Core 3.0 का उपयोग करने के लिए .NET फ्रेमवर्क 5 में जाने के लिए जोखिम लेने के बीच, आपको क्या लगता है कि लोग इसका विकल्प चुनेंगे?

मेरे विचार में, .NET कोर पर .NET कोर सुविधाओं को बैकपार्ट करने के लिए अधिक से अधिक लोगों को सुचारू रूप से माइग्रेट करना संभव बनाने के लिए .NET कोर पर समर्थित API के लिफाफे को पुश करना अधिक व्यावहारिक है। हम सभी कर सकते हैं वहाँ दु: ख का कारण है। ध्यान रखें कि साइड-बाय-साइड रिलीज़ अन्य चुनौतियों के साथ आती हैं, जैसे कि आईटी प्राप्त करना आपको इसे स्थापित करने की अनुमति देता है, इसे इंस्टॉलर में जंजीर करना, या मशीनों के साथ आपको प्रदान करने के लिए अपने होस्टर की प्रतीक्षा करना।

क्या यह ASP.NET कोर के सभी भागों पर लागू होता है, या कुछ उपयोगी, आम तौर पर पुन: प्रयोज्य भागों (जैसे Microsoft.AspNetCore.Http.Extensions ) .NET मानक पर बने रहेंगे?

@andriysavin

@terrajobst मैं पूरी तरह से समझता हूं कि आप उन API को जोड़ने से संबंधित नहीं हैं जो उन APIs को जोड़ते हैं जो सभी प्लेटफार्मों को पूरा करने के लिए तैयार नहीं हैं (और संभवतः कभी भी नहीं होगा)। हालाँकि, जब आपने (MS) को netstandard2.0 शुरू करने से नहीं रोका था, उदाहरण के लिए, UWP इसका समर्थन करने के लिए तैयार नहीं था। जैसा कि मैं समझता हूं, कुछ समय बाद उस समर्थन को जोड़ने के लिए ध्यान देने योग्य प्रयास किया, लेकिन आपने ऐसा किया। क्या वह किसी तरह एक अलग कहानी थी?

हाँ। .NET मानक 2.0 में शून्य शुद्ध-नया एपीआई था। इसे .NET फ्रेमवर्क और Xamarin के प्रतिच्छेदन के रूप में परिभाषित किया गया था। डेल्टा जो भी हो, हमें मौजूदा कोड के साथ उचित कॉम्पिटिटर बार प्राप्त करने के लिए बस इसकी आवश्यकता है। केवल काम UWP और .NET कोर में था। और उन कोड आधारों को मूल रूप से .NET के एक आधुनिक रीसेट के रूप में डिज़ाइन किया गया था, जिसे हमने व्यवहार्य नहीं होना सीखा। चूंकि ऐड-टू-एडेड एपीआई / प्रौद्योगिकियां काफी हद तक परिपक्व थीं और विवश वातावरण (ज़ामरीन आईओएस) में समर्थित थीं, इसलिए जटिलता कम थी - पोर्टिंग कार्य का सिर्फ एक टन।

लेकिन अब हम एकदम नई क्षमताओं और अवधारणाओं को जोड़ने की बात कर रहे हैं और यह ड्राइव करने के लिए एक अलग जानवर है।

मेरे अनुभव में लोग लगातार यह अनुमान लगाते हैं कि हमारे पास कितने संसाधन हैं और अकेले यथास्थिति का समर्थन करने के लिए हमारे पास कितने संसाधन हैं।

अपने अनुभव में, Microsoft ने लगातार यह अनुमान लगाया है कि हमारे पास कितने संसाधन हैं और अकेले यथास्थिति का समर्थन करने के लिए हमें कितना काम करना है। आपका तर्क वास्तव में दोनों दिशाओं में काम करता है:

मेरे विचार में, .NET कोर पर .NET कोर सुविधाओं को बैकपार्ट करने के लिए अधिक से अधिक लोगों को सुचारू रूप से माइग्रेट करना संभव बनाने के लिए .NET कोर पर समर्थित API के लिफाफे को पुश करना अधिक व्यावहारिक है।

आइए स्पष्ट हों: मैं उसके लिए सभी हूं , लेकिन यह तब तक काम करने वाला नहीं है जब तक .NET कोर पकड़ नहीं लेता है और अधिकांश / सभी विशेषताओं को लागू करता है। जब तक यह नहीं होता है, तब भी आप लोगों को एक लापता सुविधा या एक लापता एपीआई द्वारा अवरुद्ध होते हुए देखेंगे। बहुत सारी गायब चीजें हैं जो बड़े-विरासत-अखंड एप्लिकेशन को सोचने के लिए उचित नहीं है। बिना मुद्दों के साथ .NET कोर में स्थानांतरित करने में सक्षम होंगे।

मैं निश्चित रूप से आपकी चिंताओं को समझता हूं। लेकिन आखिरकार, जो आपके जीवन को आसान बनाता है, वह हमारे लिए अधिक दर्दनाक बनाने का मौका है: .NET फ्रेमवर्क का समर्थन नहीं करना हमारे लिए एक PITA होने जा रहा है।

मैं निश्चित रूप से आपकी चिंताओं को समझता हूं। लेकिन आखिरकार, जो आपके जीवन को आसान बनाता है, वह हमारे लिए अधिक दर्दनाक बनाने का मौका है: .NET फ्रेमवर्क का समर्थन नहीं करना हमारे लिए एक PITA होने जा रहा है।

वह हिस्सा मैं समझता हूं। लेकिन विकल्प .NET फ्रेमवर्क में अधिक सुविधाएँ नहीं होगी, लेकिन बस एक कम शक्तिशाली ASP.NET कोर।

हमने पिछले वर्षों में .NET फ्रेमवर्क और .NET कोर को विकसित करने की कोशिश की है। ऐसा नहीं है कि हम काम से बचने की कोशिश कर रहे थे। मैंने व्यक्तिगत रूप से हमारे रनटाइम इंजीनियरों से बात करने के लिए एक bazillion घंटे बिताए हैं, उदाहरण के लिए, बाध्यकारी पुनर्निर्देशन दुःस्वप्न। या 4.6.1 में टूटे हुए .NET मानक 2.0 समर्थन। हमने कोशिश की। यह इच्छाशक्ति की बात नहीं है, यह व्यावहारिकता की बात है।

यह तब तक काम नहीं करने वाला है जब तक .NET कोर पकड़ नहीं लेता है और सबसे अधिक / सभी सुविधाओं को लागू करता है। .NET फ्रेमवर्क था

मेरे अनुभव में, कुछ एपीआई की उपलब्धता भी है कि प्रासंगिक नहीं है। कॉरपोरेट परिवेश में बहुत मायने रखता है समर्थन और परिनियोजन जटिलता। और "ऑपरेटिंग सिस्टम के साथ स्वचालित रूप से अद्यतन, समर्थित और स्वचालित रूप से अपडेट किया गया" एक बहुत अधिक आकर्षक है जो हमें .NET कोर एलटीएस रिलीज से प्राप्त होने वाले 3 साल के समर्थन और वर्तमान में अभी भी शामिल फ़िक्की तैनाती से है। और चलो यहाँ ईमानदार रहें: अभी भी .NET कोर और ASP.NET कोर के लिए एक स्थिर टूलिंग नहीं है मैं आत्मविश्वास से कह सकता हूं कि यह अभी भी एक वर्ष में यथास्थिति होगी। हमारे पास हर रिलीज़ के साथ बदलाव थे और कौन जानता है कि 3.0 के साथ नया फ्रेमवर्क संदर्भ सही समाधान होगा। इसलिए कॉरपोरेट्स के साथ काम करते समय निश्चित रूप से एक बहुत बड़ा दर्द बिंदु है जहां आप चीजों को अपडेट नहीं कर सकते हैं या इसे जिस तरह से किया जाना चाहिए; आमतौर पर, वे चाहते हैं कि यह पिछले 5+ वर्षों से कर रहे हैं। वे फ्रेमवर्क द्वारा खराब हो गए हैं और जो कुछ भी उनके लिए आरामदायक नहीं

लेकिन विकल्प .NET फ्रेमवर्क में अधिक सुविधाएँ नहीं होगी, लेकिन बस एक कम शक्तिशाली ASP.NET कोर।

यह बहुत ज्यादा है जो मैंने पिछले साल सुझाया था: ASP.NET कोर पैकेज जो अभी भी .NET फ्रेमवर्क पर काम करते हैं (जैसे netstandard20 और netcoreapp30 लक्ष्य करके) लेकिन अधिक सीमित सुविधा सेट की पेशकश, बहुत कम के साथ दिलचस्प प्रदर्शन। कभी-कभी लोग जो चाहते हैं वह काम होती है। नई चमकदार चीजें नहीं। सुपर फास्ट सामान नहीं।

हमने पिछले वर्षों में .NET फ्रेमवर्क और .NET कोर को विकसित करने की कोशिश की है। ऐसा नहीं है कि हम काम से बचने की कोशिश कर रहे थे। मैंने व्यक्तिगत रूप से हमारे रनटाइम इंजीनियरों से बात करने के लिए एक bazillion घंटे बिताए हैं, उदाहरण के लिए, बाध्यकारी पुनर्निर्देशन दुःस्वप्न। या 4.6.1 में टूटे हुए .NET मानक 2.0 समर्थन। हमने कोशिश की। यह इच्छाशक्ति की बात नहीं है, यह व्यावहारिकता की बात है।

हम स्पष्ट रूप से सब कुछ पर सहमत नहीं हैं, लेकिन यह कहने की ज़रूरत नहीं है कि आप लोगों ने जो किया उससे मैं बहुत प्रभावित हूं (हाँ, भले ही HttpClient हिचकी जैसी चीजें निपटने के लिए काफी दर्दनाक थीं)।

मुझे उस आदमी के होने पर बहुत अफ़सोस है:

ASP.NET Core मोर्चे पर अब तक, मैंने रेजर को कुछ ठोस के रूप में देखा है जो लोग सामान्य रूप से ASP.NET कोर के बाहर उपलब्ध होना चाहेंगे। मुझे लगता है कि यह उचित है और हमें इस तरह के और क्षेत्रों की पहचान करनी चाहिए (यह एक अधिक उपयोगी चर्चा होगी)। ASP.NET Core 2.1 और 2.2 अभी भी .NET फ्रेमवर्क का समर्थन करेंगे, लेकिन मुझे नहीं लगता कि .NET फ्रेमवर्क को हमेशा के लिए समर्थन करना उचित है।

@terrajobst

इसका एक अच्छा उदाहरण इंटरफेस के डिफ़ॉल्ट कार्यान्वयन है, ... और उन सुविधाओं की संभावना ठीक उसी तरह है जैसे हम जोखिम के कारण .NET फ्रेमवर्क में वापस नहीं जा रहे हैं।

और उस बयान से डीआईएम की मौत हो गई। यह पूरी बात विरासत का विकास है। यदि यह विरासत पर लागू नहीं होता है, और विरासत और नए को पाटने के लिए पुस्तकालयों पर भी लागू नहीं हो सकता है, तो यह किसी की मदद नहीं करता है।

ASP.NET Core मोर्चे पर अब तक, मैंने रेजर को कुछ ठोस के रूप में देखा है जो लोग सामान्य रूप से ASP.NET कोर के बाहर उपलब्ध होना चाहेंगे।

आप सूची में Microsoft.Owin.Security.Interop backcompat 'पैकेज, ASP.NET कोर डेटा सुरक्षा और अंतर्निहित निर्भरताएँ जोड़ सकते हैं।

यह बहुत ज्यादा है जो मैंने पिछले साल सुझाया था: ASP.NET कोर पैकेज जो अभी भी .NET फ्रेमवर्क पर काम करते हैं (जैसे netstandard20 और netcoreapp30 लक्ष्य करके) लेकिन अधिक सीमित सुविधा सेट की पेशकश, बहुत कम के साथ दिलचस्प प्रदर्शन। कभी-कभी लोग जो चाहते हैं वह काम होती है। नई चमकदार चीजें नहीं। सुपर फास्ट सामान नहीं।

हमने इस पर भी चर्चा की है। वहाँ चुनौती यह है कि हम पूरी तरह से अंतर्निहित API और क्षमताओं में से कुछ को सार्वजनिक API में ब्लीड नहीं कर सकते हैं। इसका मतलब है कि ASP.NET कोर के मध्य-वेयर में एकीकृत पुस्तकालयों को कई कार्यान्वयन प्रदान करने होंगे। लेकिन इससे भी बदतर, यह संभव नहीं हो सकता है कि एक विद्वान बनाए बिना, क्योंकि सार्वजनिक एक्सचेंज प्रकार केवल कोर हो सकता है, जो ASP.NET कोर के दो संस्करण बनाएगा जो अब संगत नहीं हैं।

@HaloFour

और उस बयान से डीआईएम की मौत हो गई। विरासत के विकास के पूरे बिंदु। यदि यह विरासत पर लागू नहीं होता है, और विरासत और नए को पाटने के लिए पुस्तकालयों पर भी लागू नहीं हो सकता है, तो यह किसी की मदद नहीं करता है।

मुझे लगता है कि आप मौजूदा प्रतिष्ठानों के साथ

@terrajobst आप एकता का उल्लेख करते रहें। क्या उनका अपना सीएलआर कार्यान्वयन है? मैं इस धारणा के तहत था कि वे मोनो का उपयोग कर रहे हैं।

एकता के पास अपने स्वयं के गैर-मोनो एओटी संस्करण, IL2CPP सहित कई .NET कार्यान्वयन हैं। उनकी कक्षा पुस्तकालय और समर्थित एपीआई भी मानक मोनो से अलग हैं।

@terrajobst

मुझे लगता है कि आप मौजूदा प्रतिष्ठानों के साथ विरासत कोड का सामना कर रहे हैं।

"विरासत" अनुप्रयोगों की बात आती है तो बहुत अंतर नहीं है फिर भी सक्रिय रूप से बनाए रखा और विकसित किया जा रहा है। .NET कोर में माइग्रेट करने के लिए फ्रेमवर्क को अपग्रेड करने के बीच एक बड़ा अंतर है।

हालाँकि यह .NET कोर-ओनली फ़ीचर है, लेकिन यह sill हमें .NET कोर को विकसित करने की अनुमति देता है, जबकि अभी भी .NET फ्रेमवर्क में संकलित कोड का उपभोग करने में सक्षम है।

किस हद तक? .NET कोर में "विकसित" एपीआई में से कोई भी कभी भी .NET मानक पर लागू नहीं होगा। और कोई भी पुस्तकालय लेखक यह नहीं बताएगा कि यह कैसे अपने स्वयं के एपीआई में असंगत विचलन पैदा करेगा।

मैं @HaloFour से सहमत हूं। केवल वही लोग जो डीआईएम का उपयोग करने में सक्षम होंगे, वे पुस्तकालय लेखक हैं जो केवल .NET कोर को लक्षित कर रहे हैं ... इसलिए मूल रूप से सिर्फ Corefx और Aspnetcore। मैं सोच भी नहीं सकता कि कोई और इसके पास जाएगा।

केवल वही लोग जो डीआईएम का उपयोग करने में सक्षम होंगे, वे पुस्तकालय लेखक हैं जो केवल .NET कोर को लक्षित कर रहे हैं ... इसलिए मूल रूप से सिर्फ Corefx और Aspnetcore।

ठीक है, फिर से काम करने का एक और तरीका यह होगा कि एकमात्र प्लेटफ़ॉर्म जहाँ आप इसका उपयोग नहीं कर सकते हैं। .NET फ्रेमवर्क होगा जबकि आप .NET कोर, ज़ामरीन, मोनो और यूनिटी पर कर सकते हैं।

मैं सोच भी नहीं सकता कि कोई और इसके पास जाएगा।

मुझे लगता है कि इस तरह की सुविधाओं की कल्पना पुस्तकालयों में एक हॉकी स्टिक अपनाने का तरीका होगा, जो समझ में आता है। अंत में पुस्तकालय लेखक हमेशा पहुंच बनाम फीचर सेट पर विचार करेंगे। एप्लिकेशन के लिए यह तय करना आसान है, क्योंकि आप जानते हैं (और अक्सर अपने लक्षित वातावरण को नियंत्रित करते हैं)।

@ याकोव-ज

क्या यह ASP.NET कोर के सभी भागों पर लागू होता है ...

पैकेज क्या हो रहा है, इसकी अस्थायी सूची यहां है: https://github.com/aspnet/AspNetCore/issues/3756

@terrajobst मुझे लगा कि डिफ़ॉल्ट इंटरफ़ेस कार्यान्वयन C # की एक भाषा सुविधा होने जा रही है। यह कहते हुए कि .NET फ्रेमवर्क इसका समर्थन नहीं करेगा, आप व्यावहारिक रूप से कह रहे हैं कि .Net फ्रेमवर्क हमेशा सी # संस्करण 7.3 या सबसे अधिक के साथ अटक जाएगा। वह विचलन कुछ ऐसा नहीं है जिसे कोई भी पारिस्थितिकी तंत्र में होना चाहेगा।

हम कुछ .NET कोर वर्कलोड चलाते हैं, लेकिन बहु-वर्ष .NET एफएक्स वाले प्रोजेक्ट भी चलाते हैं।

.NET कोर (यहां तक ​​कि .NET फ्रेमवर्क पर शुरू करने के लिए) को सुरक्षित रूप से अपग्रेड करना एक बहुत बड़ा काम है।

क्या Microsoft के लिए कुछ टूलिंग जारी करने में मदद करने के लिए "उन्नयन" परियोजनाओं को कम से कम ASP.NET से .NET FX से ASP.NET कोर से .NET FX में मदद करने के लिए जारी करना है?

नए VS प्रोजेक्ट्स बनाने और व्यूज और रिजेक्ट करने के प्रोजेक्ट्स के बारे में MSDN लेख हैं, लेकिन बहुत सारी विरासत सामान (ग्लोबल असैक्स, राउटिंग, ....) है कि मैं चाहता हूं कि एक केंद्रीय स्थान था जो पुराने बनाम नए तरीके से मदद करने के लिए प्रलेखित किया गया था सब कुछ पोर्ट करना।

आपको एक नया साइड-बाय-साइड .NET फ्रेमवर्क संस्करण पेश करने से रोकता है (मान लीजिए कि .NET फ्रेमवर्क 5) जिसमें "जोखिम भरा" परिवर्तन शामिल हैं?

उस बिंदु पर। NET Core 3.0 नहीं होने का कोई फायदा है? इसके पहले से ही साथ-साथ है और इसमें "जोखिम भरा" बदलाव हैं। क्या .NET कोर के लिए सुविधाओं का अगला सेट तब .NET फ्रेमवर्क 6 आदि की आवश्यकता होगी?

पहले से ही .NET कोर 2.0 में मौजूद एपीआई के साथ और .NET कोर 3.0 में आने वाला नया फीचर। .NET कोर फ्रेमवर्क 4.x के साथ ".NET फ्रेमवर्क 5" को पूरा नहीं करता है और यह बेहद लंबा एलटीएस संस्करण है?

एक अनुमान पर; इस बिंदु पर, किसी भी विशिष्ट पहचाने गए अंतराल को कवर करने के लिए यह एक छोटी इंजीनियरिंग चुनौती होगी। .NET कोर 3.0 में .NET फ्रेमवर्क के बजाय .NET फ्रेमवर्क 4.x से परिवर्तन होता है।

व्यावहारिक सुझाव: क्या कोई मौका है। ASP.NET Core 2.2 आम 3 साल से ऊपर _extended_ समर्थन अवधि के साथ LTS बन जाएगा?

मुझे यकीन है कि उन लोगों को संतुष्ट करेगा जिन्हें अभी के लिए पूर्ण ढांचे के साथ रहना है, जबकि उन्हें (1) वास्तव में .NET कोर में माइग्रेट करने के लिए पर्याप्त समय देना और (2) ASP.NET MVC से ASP को माइग्रेट करने के लिए पर्याप्त प्रेरणा .NET Core (जब वे .NET Core _yet_ पर नहीं जा सकते)।

मुझे अभी भी नहीं लगता कि यह स्पष्ट है, .NET फ्रेमवर्क पर ASP.NET कोर .NET कोर 2.1 LTS का पालन करता है या क्या यह .NET फ्रेमवर्क v4.6.1 + समर्थन चक्र का अनुसरण करता है (यानी जब से यह .NET FX पर चल रहा है) यह निकट भविष्य के भीतर समर्थित है?

@mythz ASP.NET Core .NET कोर समर्थन जीवनचक्र के अंतर्गत आता है, भले ही आप इसे किस प्लेटफॉर्म पर चलाते हों।

मुझे लगता है कि यहां सबसे अच्छी चाल वास्तव में कम से कम 3.0, 4.0 और 5.0 के लिए .net मानक को अद्यतन रखने के लिए होगी और वास्तव में आगे यह संचार करेगी कि कुछ बिंदुओं के लिए .net फ्रेमवर्क पूरी तरह से .net कोर में माइग्रेट हो जाएगा।
बाकी सब सिर्फ आधा बेक किया हुआ है।

क्या आप लोगों के पास आज एलटीएस समर्थन के लिए पहले से ही ग्राहक हैं? (सिर्फ एक जांच प्रश्न)। पर्याप्त समय कितना समय है?

@terrajobst यह वास्तविक समस्या है कि netstandard अखंड है लगता है। ऐसा लगता है कि हमें इसके बजाय netstandard लेकिन संस्करण एपीआई सेट की आवश्यकता नहीं है। वे भी TFM होंगे, उदाहरण के लिए base2.0 + स्पैन दो API सेट होंगे।

फिर आप API सेट के आधार पर मानक विकसित कर सकते हैं और संभवतः केवल कुछ API सेट को पूरे ढांचे में लागू कर सकते हैं। (यह भी अन्य प्लेटफार्मों के लिए नेटस्टैड को लागू करने के लिए आसान बना देगा, क्योंकि कुछ एपीआई सेट को छोड़ा जा सकता है)।

एपीआई सेट के साथ ASP.NET कोर का एक अलग बिल्ड पूर्ण ढांचे की तरह कम-सहायक लक्ष्य के लिए बनाया जाएगा।

@Sebazzz यह बेहद अजीब विषय है। क्या हम इस धागे को netstandard को फिर से डिजाइन करने के प्रयासों से पटरी से नहीं उतार सकते हैं? आप इसके लिए डॉटनेट / मानक पर एक समस्या दर्ज कर सकते हैं, लेकिन मैं आपको बताऊंगा कि यह विचार पहले से ही प्रस्तावित था और इसे शूट किया गया था।

@davidfowl मुझे नहीं लगता कि यह "अजीब" या "अपमानजनक" है। यह ठीक वैसा ही लगता है जैसा हमें चाहिए, अगर वह जिस तरह से प्रस्तावित करता है, उससे थोड़ा कम बारीक होता है। अगर इस सब के साथ समस्या यह है कि हम अंत में इस सभी वेब सर्वर सामान को ज़ैमरिन और यूनिटी जैसे कार्यान्वयन में शामिल कर लेंगे जो वेब सर्वर की परवाह नहीं करते हैं, तो IMO एक अलग ".NET वेब सर्वर स्टैंडर्ड" एपीआई समूह बना रहा है आदर्श समाधान होगा।

@ सिज़्ज़्ज़ @masonwheeler

@terrajobst यह वास्तविक समस्या है कि netstandard अखंड है लगता है। ऐसा लगता है कि हमें इसके बजाय netstandard लेकिन संस्करण एपीआई सेट की आवश्यकता नहीं है। वे भी TFM होंगे, उदाहरण के लिए base2.0 + स्पैन दो API सेट होंगे।

हमने विभिन्न स्वादों (प्रोफाइल, पीसीएल, ढीले अनुबंध, और फिर अनुबंधित सेट जो .NET मानक 1.x बन गए) में यह कोशिश की। समय के साथ अनुकूलता नियमों को समझना और समझना कठिन है (जब प्लेटफॉर्म संस्करण और एपीआई सेट विकसित होते हैं)। .NET मानक जैसा कि यह आज है, हम कभी भी एक व्यावहारिक मॉडल के सबसे करीब थे। सही नहीं है, यह कम से कम कुछ है जो मैं मिनटों में समझा सकता हूं और लोगों के सिर में विस्फोट नहीं हुआ है।

मैं .NET मानक पर अधिक विस्तार से चर्चा करने में प्रसन्न हूं, लेकिन मैं @davidfowl से सहमत https://github.com/dotnet/standard में एक समस्या दर्ज

मैं संपादित करें विषय से हटकर के रूप में हमारे नेट स्टैंडर्ड टिप्पणियों में चिह्नित किया है।

@ शायन करने

@terrajobst मुझे लगा कि डिफ़ॉल्ट इंटरफ़ेस कार्यान्वयन C # की एक भाषा सुविधा होने जा रही है। यह कहते हुए कि .NET फ्रेमवर्क इसका समर्थन नहीं करेगा, आप व्यावहारिक रूप से कह रहे हैं कि .Net फ्रेमवर्क हमेशा सी # संस्करण 7.3 या सबसे अधिक के साथ अटक जाएगा। वह विचलन कुछ ऐसा नहीं है जिसे कोई भी पारिस्थितिकी तंत्र में होना चाहेगा।

यह एक ऐसी सुविधा है जिसके लिए भाषा परिवर्तन के साथ-साथ रनटाइम परिवर्तन की आवश्यकता होती है। यह जेनरिक के समान है क्योंकि यह प्रकार प्रणाली के नियमों को बदलता है। सामान्यतया, C # यह नहीं जानता कि आप किस फ्रेमवर्क के लिए संकलन कर रहे हैं (यह सिर्फ संदर्भ असेंबली का एक सेट है जो APIs का वर्णन करता है कि फ्रेमवर्क प्रदान करता है)। कोई भी # सुविधा जिसे एपीआई परिवर्तन की आवश्यकता नहीं है (उदाहरण के लिए अशक्त-संचालक ऑपरेटर ?. या _ को अभिव्यक्त करने के लिए Task का उपयोग करने के लिए 4.5 या उससे ऊपर की आवश्यकता होगी।

यार मैं आप लोगों के लिए महसूस करता हूं .. .net कोर पर पूर्ण रूप से आगे बढ़ना, imo, लंबी अवधि के लिए सही काम है और मैं नवाचार की उच्च गति को प्राथमिकता देता हूं जो प्रदान करेगा।

हालाँकि लोग _will_ इस बारे में परेशान हैं .. इसका एक महत्वपूर्ण हिस्सा संचार है। जब 2.1 3 वर्ष के एलटीएस की घोषणा की गई थी, तो फुलफैक्स पर लोगों को 3.0 में ओ कदम रखने में सक्षम होने की उम्मीद थी और अभी भी फुलफैक्स चलाते हैं, उन्होंने अपने नियोक्ताओं और ग्राहकों को लाइन पर अपनी प्रतिष्ठा डालते हुए asp.net core बेचा होगा, और अब वे महसूस करेंगे कि गलीचा उनके नीचे से बाहर निकाला गया है। क्या वे एक दीर्घकालिक समाधान के रूप में बेचा, asp.net के भविष्य, अब (अवधारणात्मक) 3 साल के समर्थन पर छाया हुआ है

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

अधिकांश डेवलपर्स .net core 3 में जाने के लिए _want_ करेंगे, लेकिन संभावित निर्भरता होने के अलावा वे बदल नहीं सकते (या जोखिम को बदलना शामिल है) अब उन्हें माइग्रेशन _again_ पिच करना होगा और वादा करना होगा कि _this time_ यह एक दीर्घकालिक निवेश होगा। , यह एक कठिन बिक्री हो सकती है, लेकिन वे 3 साल के समर्थन चक्र के कारण इसे करने के लिए मजबूर महसूस करेंगे।

फिर से, मैं फुलफिक्स को छोड़ने के लिए हूं, लेकिन मुझे वास्तव में लगता है कि आपको अंतिम संस्करण के लिए एलटीएस का विस्तार करने पर विचार करना चाहिए जो इसे काफी मात्रा में समर्थन करते हैं। बहुत स्पष्ट रूप से संवाद करते हुए, जैसा कि ब्लॉग, सम्मेलन / सत्र और इतने पर, क्या भागों अभी भी शुद्ध होंगे और 2.1 / पूर्ण ढांचे पर लोग अभी भी कैसे उनका लाभ उठा सकते हैं।

अन्यथा आपको कथा बनने का एक बड़ा खतरा है "Microsoft अपने समर्पित डेवलपर्स को फिर से पीछे छोड़ रहा है" यह कहते हुए कि यह उचित नहीं है , बस आपको इसके बारे में चेतावनी देने की कोशिश कर रहा है कि क्या हो सकता है।

LTS के लिए समय के बारे में क्या उचित है?

6 साल शायद? मुझे लगता है कि मैसेजिंग रिसेप्शन में एक बड़ी भूमिका निभाने जा रहा है .. हालांकि अंत में, कुछ लोग परेशान होंगे कि क्या हो सकता है: /

@davidfowl @ aL3891

संदर्भ के लिए, जावा LTS "प्रीमियर सपोर्ट" एक अतिरिक्त तीन साल के "विस्तारित समर्थन" (भुगतान) के साथ 5 साल है। जावा 11, जो एक एलटीएस रिलीज़ है और पिछले महीने रिलीज़ हुई थी, क्रमशः सितंबर 2023 और सितंबर 2026 के माध्यम से समर्थित होगी

हम एक "विस्तारित समर्थन" एलटीएस की पेशकश की जांच कर रहे हैं और जब हमारे पास होगा तो अधिक विवरण प्रदान करेगा। यह संभावित रूप से उन ग्राहकों की पेशकश करेगा, जिन्हें .NET फ्रेमवर्क संस्करण (2.1.x) पर एक समर्थित ASP.NET कोर की जरूरत है, जो वर्तमान LTS समर्थन अवधि की तुलना में लंबा विकल्प है।

FYI करें, मैंने ASP.NET कम्युनिटी स्टैंडअप पर आज की घोषणाओं के बारे में थोड़ी बात की: https://www.youtube.com/watch?v=-b59KvkWBUo&list=PL1rZQsJPBU2StrNg0aqvQswETPcYnNKL&index=0

लक्ष्य .net मानक, कृपया। asp.net core .netstandard2.1 या 3.0 लक्ष्य कर सकता है और मोनो और .netframework कैचअप को बाद में ले सकता है, लेकिन यदि asp.net core netcoreapp लक्षित करता है, तो कोई भी लाइब्रेरी किसी प्रकार तक पहुँचने का प्रयास करती है उन Aspnetcore लाइब्रेरी में .netcoreapp लाइब्रेरी होनी चाहिए।

और .net कोर हमेशा .net framework और mono से अधिक तेज़ी से रिलीज़ होगा
मोनो और .netframework अंततः .netcoreapp असेंबलियों का उपभोग करेगा यदि Microsoft Microsoft से अधिक फ्रेमवर्क / लाइब्रेरीज़ को netcoreapp लक्षित करना शुरू कर देता है (जिसके कारण nuget लक्ष्य .netcoreapp बहुत अधिक हो जाएगा)।

यदि ऐसा है, तो .netstandard .netcoreapp .netstandard हो जाएंगे

@ John0King कृपया ASP.NET Core के बाहर आपको आवश्यक प्रकार के उदाहरण दें।

1. रेजर @poke के रूप में उल्लेख किया गया है
2. MVC फ़िल्टर इंटरफ़ेसेस / एट्रीब्यूट्स (मेरे पास एक सहायक श्रेणी पुस्तकालय है जिसमें कुछ ActionFilters और TagHelpers और स्ट्रिंग के लिए सामान्य स्थैतिक / extention विधि है, int, long ect। मैं MVC पैकेजों को संदर्भित करने के लिए PrivateAssert="All" का उपयोग करता हूं ताकि मैं इसका उपयोग करूं। पुस्तकालय कुछ और जहां उस परियोजना को MVC विधानसभाओं को संदर्भित करने की आवश्यकता नहीं है, मुझे लगता है कि मुझे पुस्तकालय को दो से अलग करना होगा, एक .netstandard और दूसरा .netcoreapp )

एक और सवाल यह है कि क्या मुझे किस प्रकार की क्लास लाइब्रेरी बनानी चाहिए, यह एक समस्या है? ( .netstandard बनाम .netcoreapp )। आज asp.net कोर 2.1 में बहुत सरल है। क्लास लाइब्रेरी के लिए .netstandard चुनें, वेब प्रोजेक्ट के लिए .netcoreapp या net461 ।

मोनो और .netframework आखिरकार .netcoreapp असेंबलियों का उपभोग करेगा, यदि microsoft netcoreeapp को अधिक चौखटे / लाइब्रेरीज़ को लक्षित करना शुरू कर देता है (जो nuget लक्ष्य पर अधिक लाइब्रेरी का कारण बन जाएगा)।

यह तब होगा जब लोग .netstandard लाइब्रेरी में आने के लिए अधिक प्रयास नहीं करेंगे और .netcoreapp लाइब्रेरी में क्या आएगा

MVC फ़िल्टर इंटरफ़ेसेस / एट्रीब्यूट्स (मेरे पास एक सहायक श्रेणी पुस्तकालय है जिसमें कुछ ActionFilters और TagHelpers शामिल हैं और स्ट्रिंग, इंट, लॉन्ग ect के लिए सामान्य स्थैतिक / बाहर निकालने की विधि है। मैं MVC पैकेज का संदर्भ देने के लिए PrivateAssert = "All" का उपयोग करता हूं, जब मैं इस लाइब्रेरी का उपयोग करता हूं। कुछ और जहां उस परियोजना को MVC विधानसभाओं को संदर्भित करने की आवश्यकता नहीं है, मुझे लगता है कि मुझे लाइब्रेरी को दो से अलग करना होगा, एक .netstandard और दूसरा .netcoreapp)।

क्या आप विस्तार से समझा सकते हैं? यह समझ में नहीं आ रहा है। MVC एक ASP.NET कोर फ्रेमवर्क है और इसका उपयोग स्टैंडअलोन नहीं किया जा सकता है।

@davidfowl यह लाइब्रेरी एक सहायक श्रेणी की लाइब्रेरी है, मैं उन फिल्टर का उपयोग कर सकता हूं जब मैं एक asp.net कोर MVC प्रोजेक्ट में काम करता हूं और केवल एक कंसोल ऐप में इसके विस्तार के तरीकों का उपयोग करता हूं।

@davidfowl यह लाइब्रेरी एक सहायक श्रेणी की लाइब्रेरी है, मैं उन फिल्टर का उपयोग कर सकता हूं जब मैं एक asp.net कोर MVC प्रोजेक्ट में काम करता हूं और केवल एक कंसोल ऐप में इसके विस्तार के तरीकों का उपयोग करता हूं।

मुझे अभी भी समझ नहीं आया। क्या आप किसी ऐसे पुस्तकालय के बारे में बात कर रहे हैं जिसमें एमवीसी चीजें और अन्य यादृच्छिक चीजें हैं?

दुर्भाग्य से, इस तरह की बात एंटरप्राइज़ सॉफ़्टवेयर में आम है - 'हेल्पर लाइब्रेरीज़', जैसे कि, MVC के लिए कंपनी की उपयोगिताओं + WPF के लिए कंपनी की उपयोगिताओं + टेलरेक के लिए कंपनी की उपयोगिताओं ...
यह अधिक समझ में आता है जब '.NET' एकल एकीकृत प्लेटफॉर्म था।

@davidfowl हाँ। सहायक पुस्तकालय में कुछ वर्ग / विधि हैं आप उन प्रकारों का उपयोग हर जगह कर सकते हैं। और जब आप इस लाइब्रेरी को mvc प्रोजेक्ट में रेफर करते हैं, तो u अपने mvc संबंधित वर्ग / विधि का उपयोग कर सकता है।

ओह अच्छा यह सिर्फ आपके पुस्तकालयों को बेहतर स्तरित करने के लिए मजबूर करता है your

दुर्भाग्य से इसका मतलब यह है कि जो कोई भी अभी भी आधार पर तैनाती करता है, वह अपने सॉफ़्टवेयर का 3 साल से अधिक समय तक समर्थन नहीं कर सकता है। जैसे ही आप एक ऐप लक्ष्यीकरण .netcore 3.0 जारी करते हैं, उदाहरण के लिए, आपके ग्राहकों को 3 साल मिल गए हैं और फिर अपग्रेड करने के लिए मजबूर किया गया है। कुछ उद्योग जो इसमें ठीक होंगे, कुछ निश्चित रूप से नहीं होंगे।

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

वास्तव में इस पर .net टीम की प्रतिक्रिया चाहेंगे।

बात यह है, ASP.NET Core एक वेब फ्रेमवर्क है। > तीन साल के लिए पूरी तरह से अनमॉडिफाइड वेबसाइट चलाना किस उद्योग में सुरक्षित है? यदि यह सुरक्षा भेद्यता नहीं है, तो यह ब्राउजर उस चीज़ को दर्शाएगा, जिस पर आप भरोसा करते हैं, या TLS 1.4, या उपयोगकर्ताओं की मांग है कि साइट उनके नए वॉचलेट पर काम करे।

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

मुझे लगता है कि अगर आप ASP.NET Core 2.1 से 5-7 साल के लिए LTS की अवधि बढ़ा देते हैं तो यह समुदाय के लिए अधिक उपयुक्त होगा।

हमारे अनुभव में, कॉर्पोरेट उद्यम-वाई विकास "आधुनिक" वेब विकास की तुलना में हिमानी गति से चलता है, और फिर भी वे अभी भी यह सुनिश्चित करना चाहते हैं कि वे काफी पुराने प्लेटफार्मों पर नए निवेश नहीं कर रहे हैं। इन अनुप्रयोगों में अक्सर _launch_ के लिए एक वर्ष से अधिक का समय लगता है, अकेले 3 साल के भीतर एक प्रमुख ब्रेकिंग अपग्रेड करने में सक्षम होने दें। ये उद्यम (आमतौर पर केवल आंतरिक-सामना करने वाले) वेब एप्लिकेशन अक्सर 7-10 वर्षों के लिए समर्थित होते हैं, हालांकि मुझे लगता है कि एएसटी.नेट कोर 2.1 के लिए एलटीएस के लिए 10 वर्ष होना अनुचित है। 5 साल 3 की तुलना में बेहतर समाधान की तरह लगता है, 7 साल एक ऐसा आंकड़ा है जो निश्चित रूप से लगभग सभी को आरामदायक बना देगा।

और यह केवल आवश्यक है क्योंकि ASP.NET Core 3.0 को .NET फ्रेमवर्क समर्थन को हटाने के लिए एक प्रमुख ब्रेकिंग परिवर्तन की आवश्यकता होती है। भविष्य के एलटीएस रिलीज को इस मानक पर नहीं रखा जाना चाहिए, यह मानते हुए कि ब्रेकिंग परिवर्तन इस बड़े नहीं हैं।

मुझे यकीन नहीं है कि कैसे .NET मानक के रूप में उपवास के रूप में तेज कदम। .NET कोर को सजा के रूप में देखा जा सकता है: कुछ भी नहीं आपको नवीनतम netstandard TFM को लक्षित करने के लिए मजबूर करता है। आप केवल ऐसा करेंगे यदि आपको नवीनतम एपीआई सेट की आवश्यकता है। यदि आपको इसकी आवश्यकता नहीं है, तो एक पुराने संस्करण को लक्षित करें ताकि आपके पैकेज प्लेटफ़ॉर्म के व्यापक सेट द्वारा उपयोग किए जा सकें।

अगर प्लेटफॉर्म कभी पकड़ में न आए तो क्या होगा? फिर आपके पास एक लाइब्रेरी होगी जो netstandard2.3 लक्ष्य रखती है जिसे A की आवश्यकता है जो केवल .NET कोर और Xamarin पर उपलब्ध है, लेकिन .NET फ्रेमवर्क के लिए असंभव है।

तब netstandard2.4 बाहर आता है, कुछ नए एपिस और इनमें से कुछ एपीआई .NET फ्रेमवर्क में पोर्ट करना संभव है। अब क्या?

आप एक ऐसी लाइब्रेरी को कैसे लक्षित करते हैं जिसे netstandad2.4 से एक सुविधा की आवश्यकता होती है जो .NET फ्रेमवर्क पर चलता है, लेकिन netstandard2.4 .NET फ्रेमवर्क को लक्षित नहीं कर सकता है, क्योंकि यह netstandard2.2 लागू नहीं कर सकता है।

फिर आपको तीन प्लेटफार्मों पर संकलन करना होगा:
पुराने प्लेटफार्मों के लिए netstandard2.2 और net4x शुद्ध मानक के लिए सिर्फ netstandad2.4 और जो net4x can also implement but not support because of APIs that went into netstandard2.3` में जोड़ा गया था उस सुविधा का समर्थन करने के लिए।

यह कैसे पैकेज लेखकों के लिए अपने नगेट पैकेजों को लिखना और शिप करना आसान बना देगा?

पूरी बात केवल तब काम कर सकती है जब सबसे कम आम भाजक कि सभी प्लेटफॉर्म netstandard में प्रवाह का समर्थन करने जा रहे हैं। जब तक आप चाहते हैं कि और भी अधिक एपीआई PlatformNotSupported अपवादों को न फेंकें, अन्यथा यह शुद्धतम के भीतर विखंडन को जन्म देगा।

मैं निश्चित रूप से कल्पना कर सकता हूं कि यह आपके लिए आदर्श नहीं है, जैसे ASP.NET Core 3.0 के लिए .NET फ्रेमवर्क सपोर्ट को हटाना उन लोगों के लिए आदर्श नहीं है जो .NET कोर में नहीं जा सकते। लेकिन क्या मैं आपको पूरी तरह से गलत समझ रहा हूँ - Microsoft - के पास इससे निपटने के लिए और अधिक संसाधन हैं। औसत कंपनी की तुलना में .NET कोर में जाना है? (मैं बाहरी निर्भरता के बारे में भी बात नहीं कर रहा हूं जो आपके पास नहीं है और नियंत्रण नहीं है)।

यहां असल मुद्दा क्या है? जो लोग ASP.NET लिगेसी से ASP.NET Core में स्थानांतरित नहीं हो सकते हैं, वे ASP.NET Core के लक्ष्य .NET फ्रेमवर्क को लक्षित कर सकते हैं या नहीं। सबसे संभावित कारण वे नहीं कर सकते हैं या नहीं System.Web विशिष्ट पुस्तकालय होंगे, जो .NET फ्रेमवर्क पर ASP.NET कोर पर न तो काम नहीं करेंगे। जिन लोगों के पास अभी आवेदन हैं, जाहिर है उनके पास पहले से ही काम कर रहे हैं।

और जो लोग पहले से ही .NET फ्रेमवर्क पर ASP.NET Core 2.1 पर हैं, अगर इसके काम करने के लिए क्यों स्थानांतरित करना चाहते हैं? जाहिर है कि सभी आवश्यक वस्तुएं पहले से ही मौजूद हैं और बाकी सब जो ASP.NET Core 3.0 के लिए नया है वह अच्छा है।

दूसरों के लिए के रूप में:
.NET कोर में किसी एप्लिकेशन को माइग्रेट करने के बहुत सारे तरीके हैं, यानी पुराने मोनोलिथिक एप्लिकेशन से कुछ हिस्सों को तोड़ना और उन्हें माइक्रोसेर्विस के रूप में फिर से लागू करना, वे इस तरह से आपको जोखिम कम करते हैं और समय के साथ इसे फैलाते हैं।

अगर प्लेटफॉर्म कभी पकड़ में न आए तो क्या होगा? तब आपके पास एक लाइब्रेरी होगी जो netstandard2.3 को लक्षित करती है, जिसमें ऐसी सुविधा की आवश्यकता होती है जो केवल .NET कोर और Xamarin पर उपलब्ध हो, लेकिन .NET फ्रेमवर्क के लिए असंभव हो।

यदि .NET मानक का समर्थन करने वाले अधिकांश प्लेटफार्मों द्वारा एक एपीआई को लागू नहीं किया जा सकता है, तो संभावना अधिक है कि यह मानक का हिस्सा नहीं होना चाहिए, नहीं? (व्यवहार में, यह बहुत संभव है कि चारों ओर का रास्ता हो, क्योंकि प्लेटफॉर्म ज़ारारिन आम तौर पर बहुत अधिक विवश है)। मुझे उम्मीद है कि .NET मानक में शामिल करने के लिए एपीआई की समीक्षा करते समय इस तरह के मुद्दे का पता लगाया जाएगा, लेकिन मैं गलत हो सकता हूं।

और जो लोग पहले से ही .NET फ्रेमवर्क पर ASP.NET Core 2.1 पर हैं, अगर इसके काम करने के लिए क्यों स्थानांतरित करना चाहते हैं?

• सहयोग? (3 साल का समर्थन बहुत कम है)
• एक बग फिक्स केवल 3.0 में मौजूद है? (एलटीएस संस्करण केवल महत्वपूर्ण बग और कमजोरियों के लिए सुधार प्राप्त करते हैं)
• आपको एक पुस्तकालय का संदर्भ देने की आवश्यकता है जो केवल नवीनतम ASP.NET कोर संस्करण के साथ संगत है?

.NET कोर में किसी एप्लिकेशन को माइग्रेट करने के बहुत सारे तरीके हैं, यानी पुराने मोनोलिथिक एप्लिकेशन से कुछ हिस्सों को तोड़ना और उन्हें माइक्रोसेर्विस के रूप में फिर से लागू करना, वे इस तरह से आपको जोखिम कम करते हैं और समय के साथ इसे फैलाते हैं।

हां, निश्चित रूप से, सिद्धांत रूप में, इससे निपटने का आदर्श तरीका है। परंतु:

• कुछ ऐप्स बाहरी पुस्तकालयों पर निर्भर करते हैं जिनका आपके पास कोई नियंत्रण नहीं है। यदि लाइब्रेरी .NET कोर पर काम नहीं करती है और विक्रेता इसे (या नहीं) पोर्ट नहीं कर सकता है, तो आप भाग्य से बाहर हैं।
• .NET कोर में माइग्रेट करना महंगा और समय लेने वाला हो सकता है। यदि Microsoft की सर्वश्रेष्ठ टीमें भी इससे जूझ रही हैं, तो क्या आप वास्तव में सोचते हैं कि यह किसी भी औसत टीम के लिए आसान होगा? Entity Framework 6 को अंतिम रूप से .NET मानक के साथ संगत देखने के लिए हमें 3.0 का इंतज़ार करना होगा।

जो मैं कह रहा हूं उसका गलत मतलब न निकालें: मैं नए ऐप्स के लिए .NET कोर का उपयोग करने के लिए तैयार हूं। लेकिन यह तथ्य ASP.NET Core के साथ संगत था। .NET फ्रेमवर्क ने उचित लागत के लिए ASP.NET Core को स्थानांतरित करने में कई कंपनियों की मदद की। मुझे यकीन है कि यह "इतना कठिन नहीं" प्रवास पथ के बिना कभी भी इतना लोकप्रिय नहीं होता।

Microsoft, क्या 2.1 समर्थन का विस्तार करने के लिए कहना बहुत अधिक होगा? 2021 हमारे लिए बहुत लंबा नहीं है और हमारे पास उस रूपांतरण को बनाने के लिए पर्याप्त संसाधन / समय नहीं है। शायद कम से कम 2022 तक? एक अतिरिक्त वर्ष वास्तव में हमें बदलाव करने का मौका देगा, भले ही दर्दनाक हो।

ध्यान रखें कि हमारे तीसरे पक्ष के कई विक्रेताओं को अभी तक अपने पुस्तकालयों को .Net कोर संगतता में स्थानांतरित करना है, जो आपके हैंग होने का सबसे बड़ा कारण है।

FYI करें https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434521855

जब भी मैं आवश्यक रूप से एलटीएस का विस्तार देख रहा हूं, तो .NET एफएक्स सपोर्ट चक्र में एएसपी.नेट रोलिंग पर एएसपीओ कोर को भी विचार करना चाहिए। शुरुआत के लिए यह अलग-अलग समर्थन चक्रों पर .NET फ्रेमवर्क के विभिन्न हिस्सों को भ्रमित करने के लिए है जहां इसे एक साथ रोल करना अधिक समझ में आता है। दूसरा 2.1 के लिए कोड पहले से ही लिखा, जारी और निर्भर है, इसलिए यह 2.1 कोर का समर्थन करने के लिए काफी कम संसाधन लेने जा रहा है। सक्रिय रूप से .NET कोर 3.0 के साथ इसे विकसित करने के लिए। यदि एक ही टीम दोनों को बनाए रख रही है, तो मैं हाल ही में और अधिक परिचित मान लेगा, मॉड्यूलर ASP.NET Core सक्रिय कोड-बेस पूरी तरह से अलग क्लासिक ASP.NET कोड-बेस की तुलना में समर्थन करने में आसान होने वाला है।

जब एमएस ने 2012 में सिल्वरलाइट 5 के ईओएल की घोषणा की तो वे अब भी अक्टूबर 2021 तक इसका समर्थन कर रहे हैं (बावजूद इसके कि इसे 2015 में क्रोम और 2017 में फ़ायरफ़ॉक्स में गिरा दिया गया है)। यह उस तकनीक के लिए है जिसे पूरी तरह से छोड़ दिया गया है जो कि यहां नहीं है, मोटे तौर पर समान कोड-आधार, प्रोग्रामिंग मॉडल, सक्रिय देव टीम अभी भी इस पर काम कर रही है, यह केवल .NET फ्रेमवर्क पर मौजूदा सॉफ़्टवेयर चला रहा है जिसे छोड़ दिया जा रहा है।

इस घोषणा से पहले, मजबूत संदेशवाहक MS ने कभी भी .NET फ्रेमवर्क को नहीं छोड़ा था कि यह केवल विंडोज वर्कलोड के लिए बहुत अच्छा था (क्रॉस प्लेटफॉर्म / हाई-पर-वर्कलोड के लिए .NET कोर के विपरीत) और ASP.NET Core भविष्य का था प्रोग्रामिंग मॉडल जो .NET फ्रेमवर्क के साथ .NET मानक के साथ भविष्य में .NET फ्रेमवर्क दोनों का समर्थन करेगा। कई प्लेटफार्मों को लक्षित करने वाले पुस्तकालयों के विकास के समाधान के रूप में।

यह अब स्पष्ट है कि .NET कोर सभी नई परियोजनाओं के लिए भविष्य है, लेकिन यह मौजूदा निवेश और मौजूदा ग्राहकों के साथ व्यवहार करने के बारे में है, जिन्होंने अब तक इस मार्गदर्शन के आधार पर निर्णय किए हैं। मौजूदा सिस्टम का समर्थन करने की आवश्यकता होने पर मौजूदा .NET देव टीमें कैसे प्रगति करती हैं, वे क्लासिक ASP.NET पर रहने के लिए मजबूर होने जा रहे हैं (जहां उनके मौजूदा कौशल / ज्ञान दिन से पुराने हो रहे हैं) नए एप्लिकेशन विकसित करने के लिए संदर्भ स्विचिंग .NET कोर पर।

अगर मुझे .NET फ्रेमवर्क पर सिस्टम बनाए रखने के लिए मजबूर किया गया था, तो मैं इसे नए ASP.NET प्रोग्रामिंग मॉडल पर एक सक्रिय ज्ञान-आधार / पारिस्थितिकी तंत्र तक पहुंच के साथ विकसित करना पसंद करूंगा, फिर पुराने ASP.NET का उपयोग करने के लिए वापस लौटने के लिए मजबूर होना चाहिए। अनिश्चित काल के लिए लेकिन यह संभव नहीं होने वाला है जब तक कि ASP.NET Core on FX में WebForms के समान समर्थन स्तर नहीं है।

MS के पास "स्थिर" विकास पर्यावरण (यानी ASP.NET Core 2.1 पर नियत) के रूप में ASP.NET Core को FX पर रखने का अवसर है। .NET कोर शुरू होने के बाद से पिछले कुछ वर्षों में .NET डेवलपर होना आसान नहीं है। हमने .NET कोर <1.x में पोर्ट करने की कोशिश करने के लिए प्रभावी रूप से अपने सभी प्रयासों को छोड़ दिया है। इसके साथ ही ब्रेकिंग परिवर्तनों की निरंतर धारा के साथ बनाए रखना मुश्किल है, यह केवल तब तक था जब तक .NET कोर 2.x हम सक्षम थे इसका समर्थन करने और मौजूदा ऐप्स को माइग्रेट करने के लिए। दूसरी तरफ मौजूदा ASP.NET फ्रेमवर्क डेवलपर्स ने अपने चुने हुए मंच को स्थिर और फिर नए ASP.NET कोर प्रोग्रामिंग मॉडल द्वारा और उनके मौजूदा कौशल / ज्ञान को मिटाते हुए विस्तार से देखा है। FX पर ASP.NET Core के लिए समर्थन को समाप्त करना .NET कोर की ओर एक लोकप्रिय मंचन रणनीति को मारता है, जहां वे जोखिम वाले (आकस्मिक वापसी के बिना) एक परित्यक्त मंच पर चल रहे हैं, जब तक कि वे अपने पूरे सिस्टम को .NET कोर (एक जोखिम) में अपग्रेड करने में सक्षम नहीं होते हैं अगर यह माइग्रेशन प्रयासों को विचार से रोक सकता है) यह भविष्य में ASP.NET कोर देव मॉडल में भाग लेने में सक्षम होने के लिए उनके अवसर को भी मारता है यदि वे अपने मौजूदा सिस्टम को स्थानांतरित करने में सक्षम नहीं हैं जो वे दिन-प्रतिदिन काम करते हैं, जिस पर वे केवल तभी संभव हो सकता है जब उसे WebForms के समान समर्थन प्राप्त हो - जो मुझे आशा है कि अभी भी विचार में है।

किसी ने उल्लेख नहीं किया: हमारे asp.net कोर एप्लिकेशन में हमें WCF सेवाओं की मेजबानी करने की आवश्यकता है और यह .net ढांचे से पलायन करने के लिए एकमात्र दर्द बिंदु है। मैं .net कोर 3 पर, दुख की बात है कि सर्वर साइड wcf समर्थन के बारे में कोई खबर नहीं दिखती।

@DamianEdwards @davidfowl @natemcmaster हम एक ही नाव में हैं। मेरी कंपनी के पास कई उत्पाद हैं जो एएसपी .नेट कोर पर। नेट फुल फ्रेमवर्क पर चलते हैं, और हम इनका समर्थन 3 साल की तुलना में बहुत अधिक समय तक करते हैं, क्योंकि धीरे-धीरे हम चालों में बेचते हैं। .Net core 2.2 के लिए LTS का विस्तार करना हमारी स्थिति में निरर्थक होगा क्योंकि हमें अपने ASP.net कोर अनुप्रयोगों को ASP .Net पर वापस पोर्ट करना होगा। निश्चित रूप से यह बिंदु लोगों को हरा रहा है! क्या आप केवल कम समय के लिए समर्थन अनुप्रयोगों का सुझाव देंगे? दुर्भाग्य से यह भी कुछ ऐसा है जिस पर हमारा नियंत्रण नहीं है। जिन उद्योगों में हम काम करते हैं, उन्हें हमारे नए सॉफ्टवेयर को रोल आउट करने में एक साल लग सकता है।

दुर्भाग्य से इसका मतलब यह है कि जो कोई भी अभी भी आधार पर तैनाती करता है, वह अपने सॉफ़्टवेयर का 3 साल से अधिक समय तक समर्थन नहीं कर सकता है। जैसे ही आप एक ऐप लक्ष्यीकरण .netcore 3.0 जारी करते हैं, उदाहरण के लिए, आपके ग्राहकों को 3 साल मिल गए हैं और फिर अपग्रेड करने के लिए मजबूर किया गया है। कुछ उद्योग जो इसमें ठीक होंगे, कुछ निश्चित रूप से नहीं होंगे।

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

वास्तव में इस पर .net टीम की प्रतिक्रिया चाहेंगे।

@davidfowl https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434594997

ओह अच्छा यह सिर्फ आपके पुस्तकालयों को बेहतर स्तरित करने के लिए मजबूर करता है your

क्या यह तर्क विपरीत दिशा में काम नहीं कर रहा है?

मुझे समझ नहीं आ रहा है कि वास्तव में ASP.NET Core की उचित लेयरिंग आर्किटेक्चर से आपको क्या रोकता है?
तो, हाँ, कुछ रनटाइम सुविधाएँ .Net फ्रेमवर्क पर उपलब्ध नहीं हैं, जैसे Span<T> , लेकिन इसका मतलब यह नहीं है कि यह बिल्कुल उपलब्ध नहीं है। यह उपलब्ध है , यह सिर्फ .Net कोर के रूप में प्रदर्शन करने वाला नहीं है। हम उससे निपट सकते थे।

कुछ निम्न स्तर के कार्यान्वयन को .net कोर के लिए विशेष रूप से और .net मानक के लिए विविधताओं में लागू किया जा सकता है। और मुझे संदेह है कि इसके लिए बहुत जगह है, क्योंकि एपीआई आमतौर पर नूगेट पैकेज के रूप में उपलब्ध होते हैं।
कई पुस्तकालय लेखक विभिन्न प्लेटफार्मों के लिए अलग-अलग कार्यान्वयन का समर्थन करते हैं, यह वही है जो हमेशा से रहा है।

क्या आप कृपया विस्तार से बता सकते हैं कि क्या वास्तव में आपको .Net फ्रेमवर्क / .Net स्टैंडर्ड को सपोर्ट करने से रोकता है। प्लेटफ़ॉर्म-विशिष्ट कार्यान्वयन के लिए कुछ सरल उदाहरण जिन्हें अमूर्त नहीं किया जा सकता है?

आपको .Net फ्रेमवर्क / .Net मानक का समर्थन करने से रोकता है। प्लेटफ़ॉर्म-विशिष्ट कार्यान्वयन के लिए कुछ सरल उदाहरण जिन्हें अमूर्त नहीं किया जा सकता है?

मेरे सिर के ऊपर, रनटाइम या फ्रेमवर्क परिवर्तन की आवश्यकता वाले आइटम

• आंतरिक जीसी पॉइंटर्स; तो एक रेफरी से केवल एक वस्तु के बिना एक सुरक्षित स्पैन बनाना: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• डिफ़ॉल्ट इंटरफ़ेस कार्यान्वयन
• थ्रेडपूल कस्टम कार्य आइटम
• आधार प्रकारों पर स्पैन ओवरलोड होता है: स्ट्रीम, सॉकेट्स, टेक्स्टरीडर / टेक्स्टविटर, वेबस्केट्स
• आधार प्रकारों पर IAsyncDisposable अधिभार: स्ट्रीम, सॉकेट्स, TextReader / TextWriter, Webbockets, आदि।
• IAsyncEnumeratorआधार प्रकारों पर अधिभार: स्ट्रीम, सॉकेट्स, टेक्स्टरीडर / टेक्स्टविटर, वेबसॉकेट्स आदि।

बोनस आइटम

• हार्डवेयर इंट्रिनिक्स (x86, x64, ARM)
• एस्केप विश्लेषण (स्टैक के लिए नए आवंटन)
• साइड-बाय-साइड रनटाइम संस्करण
• बाइंडिंग पुनर्निर्देशन और संस्करण निर्धारण

मुझे समझ में नहीं आता है कि हम सिर्फ एक netstandard संस्करण क्यों नहीं कर सकते हैं जो अब netframework का समर्थन नहीं करता है। जैसे विंडोज फोन में 1.2 से आगे कोई नेटस्टैड सपोर्ट नहीं है। हम मानक को आगे क्यों नहीं बढ़ा सकते हैं और नेटकोर, मोनो, ज़मरिन, आदि जैसे कार्यान्वयन को अंततः या कभी नहीं से मेल खाते हैं। फिर लाइब्रेरी निर्माता तक यह तय करना होगा कि कवरेज को अधिकतम करने के लिए वे कौन से शुद्ध संस्करण को लागू करना चाहते हैं।

यह परिवर्तन इसे इतना बड़ा बनाता है और मोनो अब एस्पेक्टकोर का उपयोग नहीं कर सकता है। ऐसा लगता है कि यह पुस्तकालय बनाता है दोनों netcore और netstandard या बदतर दोनों अभी तक एक साथ netstandard को छोड़ने के लिए और केवल netcore को लक्षित करने के लिए मजबूर किया जाता है।

यह अंततः netstandard की मौत का कारण होगा।

आपको .Net फ्रेमवर्क / .Net मानक का समर्थन करने से रोकता है। प्लेटफ़ॉर्म-विशिष्ट कार्यान्वयन के लिए कुछ सरल उदाहरण जिन्हें अमूर्त नहीं किया जा सकता है?

मेरे सिर के ऊपर, रनटाइम या फ्रेमवर्क परिवर्तन की आवश्यकता वाले आइटम

• आंतरिक जीसी पॉइंटर्स; तो एक रेफरी से केवल एक वस्तु के बिना एक सुरक्षित स्पैन बनाना: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• डिफ़ॉल्ट इंटरफ़ेस कार्यान्वयन
• थ्रेडपूल कस्टम कार्य आइटम
• आधार प्रकारों पर स्पैन ओवरलोड होता है: स्ट्रीम, सॉकेट्स, टेक्स्टरीडर / टेक्स्टविटर, वेबस्केट्स
• आधार प्रकारों पर IAsyncDisposable अधिभार: स्ट्रीम, सॉकेट्स, TextReader / TextWriter, Webbockets, आदि।
• आधार प्रकार पर IAsyncEnumerator अधिभार: स्ट्रीम, सॉकेट्स, TextReader / TextWriter, WebS कुर्सियां, आदि।

बोनस आइटम

• हार्डवेयर इंट्रिनिक्स (x86, x64, ARM)
• एस्केप विश्लेषण (स्टैक के लिए नए आवंटन)
• साइड-बाय-साइड रनटाइम संस्करण
• बाइंडिंग पुनर्निर्देशन और संस्करण निर्धारण

उस पहली सूची में आइटम उन चीजों की तरह हैं, जो हालांकि नेटस्टैंडर्ड में बदलाव के लिए उम्मीदवार होंगे?

उनमें से अधिकांश ऐसा नहीं लगता है कि वे अन्य रनटाइम में लाना असंभव होगा, लेकिन ऐसा प्रतीत होता है कि कोई भी .NET फ्रेमवर्क के लिए डिफ़ॉल्ट इंटरफ़ेस कार्यान्वयन लाने के लिए एक नए संस्करण के लिए CLR को संशोधित नहीं करना चाहता है।

उसी समय, Microsoft .NET मानक के एक संस्करण के साथ फॉरवर्ड को आगे बढ़ाना नहीं चाहता है जो .NET फ्रेमवर्क के साथ हमेशा असंगत है। अन्यथा यह वास्तव में एक समस्या नहीं होगी - बस netstandard30 या netstandard40 और ड्रॉप फ्रेमवर्क समर्थन के साथ आगे बढ़ें; और उन नए मानकों में से एक को .NET कोर लक्ष्य रखें।

मुझे ऐसा लगता है कि यह धागा आदि माइक्रोसॉफ्ट के एक कोने में खुद को प्रभावी ढंग से पेंट करने का परिणाम है।

उसी समय, Microsoft .NET मानक के एक संस्करण के साथ फॉरवर्ड को आगे बढ़ाना नहीं चाहता है जो .NET फ्रेमवर्क के साथ हमेशा असंगत है।

यह नासमझ; .NET मानक 2.1 को अंतिम रूप दिया जा रहा है और इसमें .NET मानक 2.0 पर Span ओवरलोड शामिल हैं; जो इसे .NET फ्रेमवर्क के साथ असंगत बना सकता है।

.NET मानक अभी भी आगे बढ़ रहा है।

अन्यथा यह वास्तव में एक समस्या नहीं होगी - बस netstandard30 या netstandard40 और ड्रॉप फ्रेमवर्क समर्थन के साथ आगे बढ़ाएं; और उन नए मानकों में से एक को .NET कोर लक्ष्य रखें।

समस्या हर रनटाइम बना रही है, न कि नए मानकों में से एक के साथ असंगत फ्रेमवर्क; और फिर उसके बाद हर मानक के साथ असंगत। क्या .NET मानक में चला जाता है विभिन्न runtimes द्वारा लागू किया जा सकता है कि चीजों के रूप में सहमत होने की जरूरत है।

क्या मोनो और यूनिटी के विभिन्न जीसी जल्द ही आंतरिक बिंदुओं का समर्थन करेंगे? यदि उन्हें .NET मानक में नहीं जोड़ा जाता है, तो उन्हें उस .NET मानक से किसी भी भावी .NET मानक से तब तक ब्लॉक किया जाएगा, जब तक कि उनसे निपटने के लिए उनके GC को बदल नहीं दिया जाता। तथापि; एपिस को जोड़ने के लिए बेहतर है कि वे अब लागू कर सकते हैं और लोगों को बचा सकते हैं कि वे भविष्य के मानक के लिए नहीं कर सकते।

क्या एपिस को कोर में जोड़ा जा रहा है, जो सही एपिस को हमेशा के लिए स्थाई रूप से तय करने और हर रनटाइम के लिए मजबूर करता है; लागू करने के लिए अगले मानक के साथ संगत होना चाहता है?

पूर्वावलोकन 1 और पूर्वावलोकन 2 (उपयोग प्रतिक्रिया के कारण) के बीच कुछ कोर 2.1 एपिस बदल गए; इसलिए यह जानना भी मुश्किल है कि कोर एक्स में कौन सी एप्स नई हैं, जब तक कि यह रिलीज नहीं हो जाती है, जिसके सेट पर पत्थर लगा हुआ है। फिर उनमें से कौन सा सही है जो सभी रनटाइम्स को लागू करने के लिए मानक को जोड़ने के लिए सही सेट है (या पीछे छोड़ दिया जाए)।

.NET मानक के लिए दृष्टिकोण अभी भी ब्राउज़र मानकों की तुलना में अधिक आक्रामक है जब 2 ब्राउज़रों को मानक को स्वीकार करने से पहले सुविधा को लागू करना होगा।

यह अच्छा होगा यदि कोई नया .NET मानक .NET कोर के रूप में एक ही समय में जहाज कर सकता है और सभी रनटाइम तुरंत इसे लागू कर सकते हैं और ASP.NET कोर .NET मानक के माध्यम से सभी नए एप का उपयोग कर सकता है; लेकिन एक आदर्श के रूप में अच्छा है, लेकिन यह भी व्यावहारिक नहीं है। बहुत कुछ स्वीकृत एपिस हैं जो .NET कोर में लागू नहीं किए गए हैं

मूल प्रश्न यह है कि ASP.NET Core उस एपीस का उपयोग करें जो इसके द्वारा अनुरोध किया गया है और .NET कोर संस्करण में जहाज करता है जो इसके साथ जहाज करता है (जैसा कि वे एक साथ जहाज करते हैं); या यह केवल .NET कोर के पिछले संस्करण में भेजे गए एप्स का उपयोग कर सकता है - जिसके कारण .NET .NET के लिए मानक संस्करण में होने का एक मौका है? (जैसा कि इसकी मानक .NET मानक संस्करण की तरह लग रही है। वर्तमान में .NET कोर के पीछे 1 संस्करण में। 1 का नमूना आकार का उपयोग करके)

यदि ASP.NET कोर एपिस का उपयोग कर सकता है; तब एपिस को परीक्षण और मूल्यांकन मिलता है कि क्या वे अच्छे एपिस हैं; यदि वे नहीं हैं तो बेहतर एपिस प्रस्तावित किया जा सकता है। यदि ASP.NET Core उनका उपयोग नहीं कर सकते हैं, तो क्या वे अच्छे एपिस हैं, जब वे .NET मानक उम्मीदवार बन जाते हैं, तब भी वे काफी अज्ञात हैं।

कोई भी .NET फ्रेमवर्क के लिए डिफ़ॉल्ट इंटरफ़ेस कार्यान्वयन लाने के लिए एक नए संस्करण के लिए CLR को संशोधित करना चाहता है।

.NET .NET पारंपरिक .NET फ्रेमवर्क वर्कलोड (WinForms और WPF सहित) का समर्थन करके अनिवार्य रूप से CLR का पुनरुद्धार कर रहा है; लेकिन एक और अधिक टिकाऊ, भविष्य के सबूत तरीके से किया जाता है?

यह नासमझ; .NET मानक 2.1 को अंतिम रूप दिया जा रहा है और इसमें .NET मानक 2.0 के ऊपर 3104 नए एपिस हैं, जिसमें बेस फ्रेमवर्क प्रकारों पर स्पैन ओवरलोड शामिल हैं; जो इसे .NET फ्रेमवर्क के साथ असंगत बना सकता है।

.NET फ्रेमवर्क 4.8 और .NET फ्रेमवर्क 4.9 शामिल हैं?

हमेशा संभावना है कि भविष्य के फ्रेमवर्क अपडेट इन नए एपीआई को प्राप्त करेंगे। फिलहाल ऐसा लगता है कि पत्थर में .NET फ्रेमवर्क को कभी DIM नहीं मिलेगा, इसलिए, DIM पद्धति वाला कोई भी इंटरफ़ेस _never_ को .NET फ्रेमवर्क में पोर्ट किया जा सकता है।

.NET .NET पारंपरिक .NET फ्रेमवर्क वर्कलोड (WinForms और WPF सहित) का समर्थन करके अनिवार्य रूप से CLR का पुनरुद्धार कर रहा है; लेकिन एक और अधिक टिकाऊ, भविष्य के सबूत तरीके से किया जाता है?

और बैकवर्ड प्रूफ नहीं। जितना Microsoft ने .NET Core पर चल रहे Paint.Net जैसी चीजों को दिखाया, मैं अपने मौजूदा सर्वर-साइड प्रोजेक्ट्स को .NET Core पर नहीं चला सकता, और न ही अधिकांश लोगों को।

यह अच्छा होगा यदि कोई नया .NET मानक .NET कोर के रूप में एक ही समय में जहाज कर सकता है और सभी रनटाइम तुरंत इसे लागू कर सकते हैं और ASP.NET कोर .NET मानक के माध्यम से सभी नए एप का उपयोग कर सकता है; लेकिन एक आदर्श के रूप में अच्छा है, लेकिन यह भी व्यावहारिक नहीं है।

यह भी व्यावहारिक नहीं हो सकता है, लेकिन मुझे लगता है कि अगर ASP.NET कोर के दो संस्करण हो सकते हैं तो लोग थोड़ा खुश होंगे।

• एक तेज़-तर्रार रक्तस्राव-धार संस्करण जो .NET _Core_ से बंधा है और किसी भी नए एपीआई का उपयोग कर सकता है, इसलिए यह इच्छा रखता है।
• एक धीमी-चलती-चलती एलटीएस संस्करण जो .NET _Standard_ से बंधा हुआ है और अधिक स्थानों पर चलता है; जो अंततः पुराने ब्लीडिंग-एज बिल्ड के साथ पकड़ता है लेकिन हमेशा पीछे रहता है।

इसे .NET कोर में बांधने से आप एक ऐसे ट्रेडऑफ को मजबूर कर रहे हैं जिससे हर कोई खुश नहीं है। मुझे गोट्टा-मूव-फास्ट दृष्टिकोण के पीछे तर्क मिलता है, लेकिन समग्र .NET पारिस्थितिकी तंत्र के लिए एक वैध चिंता भी है।

• एक तेज़-तर्रार रक्तस्राव-धार संस्करण जो .NET कोर से बंधा हुआ है और किसी भी नए एपीआई का उपयोग कर सकता है जो इसे चाहता है।
• एक धीमी-चलती-चलती एलटीएस संस्करण जो .NET मानक से बंधा हुआ है और अधिक स्थानों पर चलता है; जो अंततः पुराने ब्लीडिंग-एज बिल्ड के साथ पकड़ता है लेकिन हमेशा पीछे रहता है।

इसलिए यदि ASP.NET Core 3.0 केवल .NET Core 3.0 के रूप में सामने आया है; लेकिन कुछ बाद की तारीख में जब उनका .NET मानक था जिसमें एपिस था; ASP.NET Core 3.x के लिए पैकेज जारी किए गए थे। .NET मानक भी थे (भले ही ASP.NET Core 4.0 पर चला गया हो); क्या यह आपकी आवश्यकताओं को पूरा करेगा?

@ याकोव-ज

एक धीमी-चलती-चलती एलटीएस संस्करण जो .NET मानक से बंधा हुआ है और अधिक स्थानों पर चलता है; जो अंततः पुराने ब्लीडिंग-एज बिल्ड के साथ पकड़ता है लेकिन हमेशा पीछे रहता है।

इसका क्या मतलब है? आप हमेशा ASP.NET Core 2.1 का उपयोग उस विस्तारित समर्थन के साथ कर सकते हैं जिसका @DamianEdwards ने उल्लेख किया है। मेरा अनुमान है कि भले ही वह समर्थन 10 साल था, लेकिन यह शिकायत करने वाले लोगों को संतुष्ट नहीं करेगा। आंत मुझे बताती है कि जब तक नई सुविधाएँ विकसित हो रही हैं तब तक लोग उन तक पहुंचना चाहेंगे (यहां तक ​​कि वर्तमान में धीमी ट्रेन पर भी), लेकिन शायद मैं इन प्रतिक्रियाओं में बहुत अधिक पढ़ रहा हूं ...

आप हमेशा विस्तारित समर्थन के साथ ASP.NET Core 2.1 का उपयोग कर सकते हैं

कृपया समुदाय को विभाजित न करें !!
(वोट के आधार पर) क्या आप उम्मीद करते हैं कि asp.net core 2.1 में 1/3 डेवलपर रहें? या 2/3 डेवलपर्स की अपेक्षा करें जो नगेट पैकेज बनाते हैं जिन्हें अपने पुस्तकालय के 2 संस्करण को बनाए रखना है?

@benaadams

इसलिए यदि ASP.NET Core 3.0 केवल .NET Core 3.0 के रूप में सामने आया है; लेकिन कुछ बाद की तारीख में जब उनका .NET मानक था जिसमें एपिस था; ASP.NET Core 3.x के लिए पैकेज जारी किए गए थे। .NET मानक भी थे (भले ही ASP.NET Core 4.0 पर चला गया हो); क्या यह आपकी आवश्यकताओं को पूरा करेगा?

यकीनन।

@davidfowl

आप हमेशा ASP.NET Core 2.1 का उपयोग उस विस्तारित समर्थन के साथ कर सकते हैं जिसका @DamianEdwards ने उल्लेख किया है। मेरा अनुमान है कि भले ही वह समर्थन 10 साल था, लेकिन यह शिकायत करने वाले लोगों को संतुष्ट नहीं करेगा।

यहाँ परस्पर विरोधी संदेश प्रतीत होते हैं:

1. 2.1, पुराने एलटीएस संस्करण पर बने रहना ठीक है
2. ASP.NET Core इतनी तेज़ी से आगे बढ़ रहा है कि हम .NET कोर और उसके बाद के .NET मानक के बीच एक रिलीज़ चक्र की प्रतीक्षा नहीं कर सकते।

मुझे लगता है कि (2) बहुत भ्रम पैदा कर रहा है और पीछे छूट जाने का डर है।

@ John0King

(वोट के आधार पर) क्या आप उम्मीद करते हैं कि asp.net core 2.1 में 1/3 डेवलपर रहें? या 2/3 डेवलपर्स की अपेक्षा करें जो नगेट पैकेज बनाते हैं जिन्हें अपने पुस्तकालय के 2 संस्करण को बनाए रखना है?

मैं पुस्तकालय लेखकों से अपेक्षा करता हूं कि वे यह तय करें कि एएसपी.नेट कोर का न्यूनतम संस्करण क्या है जो वे समर्थन के बारे में परवाह करते हैं और लक्ष्य करते हैं। यह वही है जो वे आज कर रहे हैं। कुछ पुस्तकालयों ASP.NET Core 1.x और 2.x का समर्थन करते हैं तो कुछ केवल 2.x का समर्थन करते हैं। यह कोई अलग नहीं है।

@ याकोव-ज

मुझे यह समझ में नहीं आया कि परस्पर विरोधी संदेश क्या हैं। वर्तमान 2.1 एलटीएस है और .NET कोर और .NET फ्रेमवर्क पर चलता है और 3 साल के लिए समर्थित है। यह एक नया संदेश नहीं है यह वही संदेश है जो हमने शुरू से लिया है।

ASP.NET Core इतनी तेज़ी से आगे बढ़ रहा है कि हम .NET कोर और उसके बाद के .NET मानक के बीच एक रिलीज़ चक्र की प्रतीक्षा नहीं कर सकते।

यहाँ की गई टिप्पणियों के आधार पर यह अटकलें हैं। आधिकारिक तौर पर, हम .NET कोर के जहाज चक्र से बंधे हैं और हम पहले से ही हर रिलीज के साथ नए एपीआई जोड़ रहे हैं और उपभोग कर रहे हैं। .NET फ्रेमवर्क पर चलने वाले ASP.NET Core का मतलब कभी भी स्थायी चीज़ नहीं था (इसे ASP.NET Core भी कहा जाता है), इसका मतलब हमेशा स्टेपनी स्टोन के रूप में होता था। हमें बस पर्याप्त कोर एपीआई जोड़ना था ताकि ग्राहक यथोचित रूप से पूरी तरह से काम कर सकने वाले एप्लिकेशन लिख सकें।

एमएस टीम से इस पर कोई प्रतिक्रिया?

दुर्भाग्य से इसका मतलब यह है कि जो कोई भी अभी भी आधार पर तैनाती करता है, वह अपने सॉफ़्टवेयर का 3 साल से अधिक समय तक समर्थन नहीं कर सकता है। जैसे ही आप एक ऐप लक्ष्यीकरण .netcore 3.0 जारी करते हैं, उदाहरण के लिए, आपके ग्राहकों को 3 साल मिल गए हैं और फिर अपग्रेड करने के लिए मजबूर किया गया है। कुछ उद्योग जो इसमें ठीक होंगे, कुछ निश्चित रूप से नहीं होंगे।

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

वास्तव में इस पर .net टीम की प्रतिक्रिया चाहेंगे।

दुर्भाग्य से इसका मतलब यह है कि जो कोई भी अभी भी आधार पर तैनाती करता है, वह अपने सॉफ़्टवेयर का 3 साल से अधिक समय तक समर्थन नहीं कर सकता है

यह सिर्फ बकवास है, आप वास्तव में सिर्फ एक उन्नयन कर सकते हैं। एकमात्र समय जहां यह काम नहीं करता है एक एम्बेडेड वातावरण के अंदर है, लेकिन एम्बेडेड सॉफ़्टवेयर में 3 साल की समर्थन विंडो की तुलना में बहुत अधिक समस्या है।

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

@davidfowl

मेरा अनुमान है कि भले ही वह समर्थन 10 साल था, लेकिन यह शिकायत करने वाले लोगों को संतुष्ट नहीं करेगा।

यह निश्चित नहीं है कि आप लोगों से इसे लेने की उम्मीद कैसे कर रहे हैं, इस निर्णय के प्रभाव का हर किसी को उस मंच से सामना करना पड़ता है जिसे वे न केवल भविष्य के लिए स्थानांतरित करने के लिए बेचे गए थे, बल्कि नवीनतम प्रोग्रामिंग मॉडल पर बनाया गया उनका मौजूदा निवेश चालू है एक असमर्थित प्लेटफ़ॉर्म (जो इस घोषणा के अनुसार है) 3 साल से कम समय में। जिन लोगों ने .NET .NET को माइग्रेट करने के माध्यम से .NET कोर को सावधानीपूर्वक मंचित प्रवास के बारे में सोचा था, अब उन्हें इस जोखिम का सामना करना पड़ रहा है कि अब उन्हें वापस आने के लिए कोई आकस्मिकता नहीं होगी - यह एक नए .NET कोर रनटाइम या बस्ट पर चला गया है।

एक डेवलपर प्लेटफ़ॉर्म अपने आप में लक्ष्य नहीं होना चाहिए, क्योंकि प्लेटफ़ॉर्म पर घातीय रूप से अधिक मूल्य बनाया जा रहा है, फिर प्लेटफ़ॉर्म का मूल्य। इस तरह से अंधाधुंध चलने से यह प्रतीत होता है कि मंच के वेग को बढ़ाने के लिए संसाधनों की अधिकतम दक्षता उस पर बनाए जा रहे पारिस्थितिकी तंत्र के निवेश से अधिक महत्वपूर्ण है। .NET Core 2.1 बिट्स पर स्याही अभी तक सूखी नहीं है, लेकिन मौजूदा सिस्टम (FX पर) को पहले से ही परिसंपत्ति और मूल्य के बजाय पारिस्थितिक तंत्र में जोड़ने के लिए एक दायित्व (न्यूनतम समर्थन प्रदान करने की दृष्टि से) के रूप में माना जा रहा है।

जैसा कि उल्लेख किया गया है, एंटरप्राइज़ सिस्टम ग्लेशियल गति से आगे बढ़ सकते हैं, अक्सर एक साथ लगातार सुधार करने वाले देवों की टीमों को संतुलित करते हैं जो कर्मचारियों और ग्राहकों की संख्या को उनसे निरंतर आरओआई प्राप्त करने के लिए उपयोग करने की आवश्यकता होती है। कई प्रवासियों को सावधानीपूर्वक योजना और कठोर परीक्षण के साथ "इन-फ़्लाइट" होने की आवश्यकता होती है, जिसमें वर्षों का समय लग सकता है, जो वे मूल्य बनाने का उपयोग करना पसंद करेंगे, फिर प्लेटफ़ॉर्म से बाहर निकलने के लिए स्क्रैचिंग करें जो उनके नीचे से समर्थन खींच रहा है। बड़े ब्राउनफील्ड सिस्टम में आईफ़ोन जैसी वस्तुएं नहीं हैं जिन्हें आसानी से त्याग दिया जा सकता है और हर कुछ वर्षों में आसानी से अपग्रेड किया जा सकता है, पुराने और लंबे सिस्टम विकास में हैं, इसमें जितना अधिक मूल्य निवेश किया जाएगा और उतनी ही मुश्किल से इसे स्थानांतरित करना होगा, जो विशेष रूप से हो जाता है दिए गए को अवशोषित करने के लिए मुश्किल है, माइग्रेशन में कोई मूल्य नहीं बनाया गया है, इसके लिए संसाधनों की आवश्यकता होती है, अवसर की लागत को अवशोषित करता है, जोखिम को बढ़ाता है और सबसे अच्छी उम्मीद कर सकता है कि वे अपने मौजूदा सिस्टम के साथ एक निर्दोष प्रवासन कर रहे हैं जैसा कि पहले किया था।

जो भी एक्सपायरी डेट एफएक्स सपोर्ट पर डाली जाती है, उसमें मौजूदा सिस्टम चल रहे होते हैं जो अतीत में चलते हैं जो बाधाओं से टकराते हैं या फिर इसे बंद करने के लिए अलग-अलग होते हैं। फिर क्या बन जाता है मार्गदर्शन?

ASP.NET Core 2.1 पहले से ही विकसित है, ASP.NET Core को FX / .NET Core पर चलाने का प्रयास पहले से ही किया गया एक डूब लागत है। इसलिए निर्णय को एमएस संसाधनों के मामले के रूप में तैयार किया जाना चाहिए ताकि पहले से ही विकसित मंच (एलटीएस के बाद) बनाम संचयी राशि, बीमार इच्छाशक्ति और एक लोकप्रिय मंच को छोड़ने के लिए उत्पन्न जड़ता को बनाए रखा जा सके।

मुझे यकीन नहीं है कि मैं समझता हूं कि तब क्या पूछा जा रहा है। एलटीएस के लिए जीवनचक्र 2.1 के बाद से नहीं बदला है। यदि आपने LTS संस्करण पर एक ऐप लिखा है कि क्या .NET कोर या .NET फ्रेमवर्क है, तो आपको "असमर्थित" होने तक 3 साल होंगे। मुझे यह बिल्कुल समझ में नहीं आता कि समर्थन के मामले में आपके नीचे से कैसे गलीचा खींचा जा रहा है, जो नहीं बदला है। किसी भी प्लेटफ़ॉर्म अपडेट को प्राप्त करने के लिए आपको अपग्रेड करना होगा।

अब मुझे समझ में आया है कि .NET फ्रेमवर्क पर समर्थित 2.1 अंतिम LTS संस्करण है, इसका मतलब है कि इसमें अपग्रेड करने की कोई जगह नहीं है, लेकिन यहीं विस्तारित LT समर्थन समर्थन आता है। अगर इन 6 वर्षों के बाद भी एप्लिकेशन .NET कोर में नहीं जा सकता है क्योंकि API हैं लापता, कृपया मुद्दे दर्ज करें ताकि हम अंतराल को समझें।

मुझे यकीन नहीं है कि मैं समझता हूं कि तब क्या पूछा जा रहा है।

यह थ्रेड MS से कमिटमेंट के अलग-अलग स्तरों का अनुरोध कर रहा है: इसे .NET कोर के साथ मिलकर विकसित करते रहें, इसे "धीमी ट्रेन" पर विकसित करें, ASP.NET Core 2.1 को न छोड़ें और WebForms के समान समर्थन को बनाए रखें, नोटिफिकेशन का विस्तार करें । मेरी प्राथमिकता इसे ASP.NET Core के लिए एक होस्टिंग विकल्प के रूप में नहीं छोड़ना होगा (संपादित करें: ऊपर की कोई भी चीज़ जो अधिक बेहतर होगी) जो .NET .NET को केवल v3 + में वापस नहीं लेगा जबकि मौजूदा .NET के लिए बहुत अधिक उपयोगिता प्रदान करेगा। एफएक्स निवेश।

अब मुझे समझ में आ रहा है कि 2.1 .NET फ्रेमवर्क पर समर्थित अंतिम LTS संस्करण है जिसका अर्थ है कि इसमें अपग्रेड करने की कोई जगह नहीं है

इसका मतलब यह है कि यह एक असमर्थित मंच बन गया है, इस पर किसी को भी इसे लावा और हाथापाई की तरह व्यवहार करना पड़ता है, इससे पहले कि यह असमर्थित ईओएल अंत तक पहुंच जाए।

• कोई भी व्यक्ति जो .NET कोर में जाने के लिए एक मंच के रूप में इसका उपयोग करने के बारे में सोचता है, एक कम संभव विकल्प बन गया है क्योंकि वे एक असमर्थित मंच पर फंसे होने के जोखिम का सामना करते हैं यदि माइग्रेशन अपेक्षा से अधिक समय तक होता है या वे आश्रितों में से किसी पर भी बाधा डालते हैं। वे .NET कोर पर नहीं चल सकते हैं पर भरोसा करते हैं।
• किसी को भी अपने उद्यम के मौजूदा प्रबंधित बुनियादी ढांचे के .NET फ्रेमवर्क सर्वर का उपयोग करने के लिए मजबूर होना चाहिए, नए देव मॉडल और पारिस्थितिकी तंत्र का उपयोग करने में भाग नहीं ले सकता है और उन्हें अपने मौजूदा क्लासिक ASP.NET ज्ञान / कौशल को कम मूल्यवान प्रत्येक दिन देखना होगा।
• टीमें अपने मौजूदा .NET फ्रेमवर्क आवश्यक सिस्टमों को स्थानांतरित नहीं कर सकती हैं और उन्हें .NET कोर पर नए ASP.NET कोर प्रोजेक्ट के लिए संदर्भ स्विचिंग की आवश्यकता होगी।
• कोई भी संगठन एक अनियोजित माइग्रेशन में मजबूर नहीं होना चाहता है क्योंकि उनके बजट, योजना और निवेश निर्णयों को आधार बनाने के लिए उन्होंने जो मार्गदर्शन किया है वह बदल गया है।

फिर से ग्रीनफील्ड परियोजनाओं के लिए कोई समस्या नहीं है, ऐसे लोगों के लिए जो किसी भी तरह से .NET कोर में माइग्रेट करने की योजना बना रहे हैं या किसी के लिए जो विरासत प्रणालियों को बनाए रखने की आवश्यकता नहीं है, लेकिन यह मौजूदा .NET FX पारिस्थितिकी तंत्र और ASP.NET कोर को प्रभावित करता है। .NET एफएक्स पर होस्टिंग के लोकप्रिय विकल्प के उपयोग पर विचार करने में सक्षम नहीं होने के लिए अब और गरीब हो गया है।

एक आदर्श दुनिया में हर कोई .NET कोर पर होगा लेकिन .NET FX में काफी मात्रा में निवेश मौजूद है जो इस निर्णय के साथ अवमूल्यन किया जा रहा है।

अगर इन 6 वर्षों के बाद भी एप्लिकेशन .NET कोर में नहीं जा सकता है क्योंकि API गायब हैं,

ऐसे कई लोग हैं जो .NET कोर में नहीं जा सकते हैं या नहीं करना चाहते हैं, वे चाहते हैं कि यह क्लासिक ASP.NET के समान समर्थन को साझा करे (जो कि वर्तमान संदेश का सुझाव अनिश्चित काल के लिए है)।

लापता APIs एकमात्र कारण नहीं है जो माइग्रेशन को रोकता है, उदाहरण के लिए वे एक निर्भरता पर भरोसा कर सकते हैं जहां देव टीम ने इसे अब अस्तित्व में नहीं बनाया है, यह एक महत्वपूर्ण घटक है जिसे बदला नहीं जा सकता है, इसे सुरक्षित रूप से नहीं बदला जा सकता है (उदाहरण के लिए) कोई परीक्षण नहीं), इसे अन्य .NET FX- केवल सिस्टमों के साथ साझा किया गया है, इसे किसी अन्य विभाग द्वारा बनाए रखा गया है जिसका कोई बजट नहीं है, इसे बदलने की क्षमता है या बाहरी कारकों जैसे उनके उद्यमों द्वारा प्रबंधित बुनियादी ढांचा केवल .NET फ्रेमवर्क सर्वर पर चलने का समर्थन करता है।

इस तरह के निर्णयों के साथ .NET मानक को मारने के लिए धन्यवाद।

अब तक हम .NET कोर को नजरअंदाज करते रहे हैं क्योंकि बहुत सारे थर्ड पार्टी असेंबली हैं जो अभी तक कोर को लक्षित नहीं करते हैं।

कई विक्रेता जो कोर का समर्थन करने के लिए तैयार हैं, वे आधे दिल से ऐसा करते हैं, जैसे कि प्रबंधित किए गए ODP.NET देशी एपीआई के बिना जो केवल .NET फ्रेमवर्क पर उपलब्ध हैं।

फिर आप इस तरह के फैसले लेकर आते हैं।

नहीं। हम .NET कोर को केवल इसलिए तेजी से नहीं अपनाएंगे क्योंकि यह Microsoft के लिए .NET फ्रेमवर्क का समर्थन करने के लिए बहुत अधिक काम है और यह .NET मानक पर वितरित करने में सक्षम नहीं है जिसे आप लोगों ने शुरू करने के लिए धक्का दिया था।

@davidfowl मैं आपको .NET कोर - WCF (कई मौजूदा एंटरप्राइज़ एप्लिकेशन इसका उपयोग करने के लिए माइग्रेट करना कठिन बनाता है, के 2 उदाहरण दे सकता हूं, मेरा मानना ​​है कि अन्य लोगों ने उस मुद्दे को पहले ही उठाया है), और .NET कोर / NET में Adomd लाइब्रेरी की कमी है। मानक (जो SSAS के साथ संवाद करने के लिए है, एंटरप्राइज़ ऐप्स में भी उपयोग किया जाता है, जिसे SQL https://feedback.azure.com/forums/908035-sql-server/suggestions/35508349-adomd-core पर ट्रैक किया गया है)। कुछ अन्य (winforms) .net कोर 3 संगतता पैक (या!) के साथ तय किए जाने चाहिए - हमें इंतजार करना होगा और देखना होगा कि यह वास्तव में कैसे काम करता है।

@mythz

यह थ्रेड MS से कमिटमेंट के अलग-अलग स्तरों का अनुरोध कर रहा है: इसे .NET कोर के साथ मिलकर विकसित करते रहें, इसे "धीमी ट्रेन" पर विकसित करें, ASP.NET Core 2.1 को न छोड़ें और WebForms के समान समर्थन को बनाए रखें, नोटिफिकेशन का विस्तार करें । मेरी प्राथमिकता इसे ASP.NET कोर के लिए एक होस्टिंग विकल्प के रूप में नहीं छोड़ना होगा जो .NET .NET केवल v3 + को वापस नहीं रखेगा, जबकि मौजूदा .NET FX निवेशों के लिए बहुत अधिक उपयोगिता प्रदान करेगा।

खैर हम वर्तमान में मौजूदा LTS समर्थन की खोज कर रहे हैं, लेकिन हम ASP.NET कोर के लिए प्रथम श्रेणी .NET फ्रेमवर्क समर्थन पर हमेशा के लिए विचार नहीं कर रहे हैं (जो आप पूछ रहे हैं)। ASP.NET Core का यह संस्करण जिसे आप उसी स्तर के समर्थन के लिए देख रहे हैं, जैसा कि WebForms को केवल सुरक्षा फ़िक्सेस और विश्वसनीयता फ़िक्सेस प्राप्त होंगे। मैं आपको गारंटी दे सकता हूं कि जैसा कि ASP.NET Core के नए संस्करणों में सुविधाएँ दिखाई देती हैं, ASP.NET Core 2.1 का उपयोग करने वालों की संतुष्टि का स्तर नीचे जाएगा (कम से कम, यही मेरा पेट मुझे बताता है) क्योंकि वे परिवर्तन अभी भी बाहर होंगे पहुंच।

लापता APIs एकमात्र कारण नहीं है जो माइग्रेशन को रोकता है, उदाहरण के लिए वे एक निर्भरता पर भरोसा कर सकते हैं जहां देव टीम ने इसे अब अस्तित्व में नहीं बनाया है, यह एक महत्वपूर्ण घटक है जिसे बदला नहीं जा सकता है, इसे सुरक्षित रूप से नहीं बदला जा सकता है (उदाहरण के लिए) कोई परीक्षण नहीं), इसे अन्य .NET FX- केवल सिस्टमों के साथ साझा किया गया है, इसे किसी अन्य विभाग द्वारा बनाए रखा गया है जिसका कोई बजट नहीं है, इसे बदलने की क्षमता है या बाहरी कारकों जैसे उनके उद्यमों द्वारा प्रबंधित बुनियादी ढांचा केवल .NET फ्रेमवर्क सर्वर पर चलने का समर्थन करता है।

यह बहुत सामान्य है (Microsoft के भीतर भी) और इसीलिए हमने .NET कोर 2.0 में .NET फ्रेमवर्क dlls को संदर्भित करने की क्षमता को जोड़ा क्योंकि यह पता चलता है कि अधिकांश असेंबली तब भी संगत होती हैं, भले ही वे .NET कोर के लिए संकलित न हों। अब कुछ चीजें हैं जो कभी काम नहीं करेंगी (जैसे AppDomains ...) लेकिन मुझे उम्मीद है कि हम अधिक एपीआई सतह जोड़ते हैं, पुस्तकालयों का सेट जो काम नहीं करता है वह एक तुच्छ संख्या में सिकुड़ जाएगा।

@pjmlp

मैं यह नहीं देखता कि यह कैसे .NET को मारता है। .NET मानक ASP.NET कोर से बड़ा है। यह पुन: प्रयोग करने योग्य साझा पुस्तकालय (जैसे Microsoft.Extensions *) बनाने के बारे में है जो किसी भी समर्थन .NET प्लेटफॉर्म पर काम करते हैं।

अब तक हम .NET कोर को नजरअंदाज करते रहे हैं क्योंकि बहुत सारे थर्ड पार्टी असेंबली हैं जो अभी तक कोर को लक्षित नहीं करते हैं।

कौन सा? रास्ते में उन लोगों के लिए समर्थन कर रहे हैं या उन विधानसभाओं कभी .NET कोर का समर्थन करेंगे?

कई विक्रेता जो कोर का समर्थन करने के लिए तैयार हैं, वे आधे दिल से ऐसा करते हैं, जैसे कि प्रबंधित किए गए ODP.NET देशी एपीआई के बिना जो केवल .NET फ्रेमवर्क पर उपलब्ध हैं।

मैं इससे सहमत हूं और .NET कोर पर पुस्तकालयों के अपंग संस्करणों के टन देखे हैं (यहां तक ​​कि कुछ Microsoft पुस्तकालयों के साथ) लेकिन मैं कहूंगा कि ज्वार उस पर बदल रहे हैं। इसके कुछ कारण .NET कोर 1.0 पर मौजूद API के प्रारंभिक लापता सेट के कारण थे। 2.0 और 2.1 के साथ, हमने लाइब्रेरीज़ पोर्ट के एक बड़े सेट को कार्यक्षमता में बहुत नुकसान के बिना कोर / मानक पर अधिक आसानी से देखा है।

@voltcode ठोस प्रतिक्रिया के लिए धन्यवाद! हम उम्मीद करते हैं कि आज के समय (3 वर्ष या उससे अधिक समय तक) हम .NET कोर परियोजनाओं का समर्थन करने वाले इन प्रकार के संगतता मुद्दों से दूर चले जाएंगे या कम से कम होंगे।

@davidfowl

....

अब तक हम .NET कोर को नजरअंदाज करते रहे हैं क्योंकि बहुत सारे थर्ड पार्टी असेंबली हैं जो अभी तक कोर को लक्षित नहीं करते हैं।

कौन सा? रास्ते में उन लोगों के लिए समर्थन कर रहे हैं या उन विधानसभाओं कभी .NET कोर का समर्थन करेंगे?

हमारे मामले में ODP.NET स्पष्ट है, क्योंकि ओरेकल कोर में 100% ड्राइवर सुविधाओं को पोर्ट नहीं कर रहा है।

कई विक्रेता जो कोर का समर्थन करने के लिए तैयार हैं, वे आधे दिल से ऐसा करते हैं, जैसे कि प्रबंधित किए गए ODP.NET देशी एपीआई के बिना जो केवल .NET फ्रेमवर्क पर उपलब्ध हैं।

मैं इससे सहमत हूं और .NET कोर पर पुस्तकालयों के अपंग संस्करणों के टन देखे हैं (यहां तक ​​कि कुछ Microsoft पुस्तकालयों के साथ) लेकिन मैं कहूंगा कि ज्वार उस पर बदल रहे हैं। इसके कुछ कारण .NET कोर 1.0 पर मौजूद API के प्रारंभिक लापता सेट के कारण थे। 2.0 और 2.1 के साथ, हमने लाइब्रेरीज़ पोर्ट के एक बड़े सेट को कार्यक्षमता में बहुत नुकसान के बिना कोर / मानक पर अधिक आसानी से देखा है।

यह नहीं है कि हमारे कितने ग्राहक इसे देखते हैं।

बस आपको यह महसूस करने के लिए कि इस तरह के निर्णय .NET के भविष्य को कैसे प्रभावित करते हैं, हाल ही में एक परियोजना पर ग्राहक ने UNIX तैनाती के लिए .NET फ्रेमवर्क से जावा में एक एप्लिकेशन को स्थानांतरित करने के लिए विकास के प्रयास का भुगतान किया, क्योंकि वह इच्छुक नहीं था। .NET कोर और अपंग ODP.NET कार्यान्वयन पर दांव लगाते हैं, जबकि JDBC ड्राइवर .NET फ्रेमवर्क ODP.NET ड्राइवर के साथ 1: 1 फ़ीचर समता प्रदान करता है।

दूसरों को भी एक और वैकल्पिक ढेर चुन सकते हैं।

निर्भरता का एक टन है जो आपके औसत उद्यम ऐप में पोर्ट नहीं किया जा सकता है और न ही किया जा सकता है।

यह मुद्दा एचएन के शीर्ष पर उभरा। आप लोग (@MSFT) वहां भी जांच करना चाहते हैं। केवल 1hr और पहले से ही 50+ टिप्पणियां।

@davidfowl

मैं यह नहीं देखता कि यह कैसे .NET को मारता है। .NET मानक ASP.NET कोर से बड़ा है। यह पुन: प्रयोग करने योग्य साझा पुस्तकालय (जैसे Microsoft.Extensions *) बनाने के बारे में है जो किसी भी समर्थन .NET प्लेटफॉर्म पर काम करते हैं।

मुझे समझ में नहीं आ रहा है कि ASP.NET Core क्या है अगर दोबारा साझा की जाने वाली साझा लाइब्रेरी नहीं है? यदि पुस्तकालयों के लिए आधुनिक और तेज होने की प्रवृत्ति .NET मानक समर्थन को छोड़ना है तो यह एक मुश्किल संदेश है। क्या Newtonsoft.Json को .NET Core 3 पर केवल तभी स्विच करना चाहिए, अगर यह बहुत तेज गति से चल सके? ऑटोफोक चाहिए?

मुझे इसके पीछे के कारणों की समझ नहीं है, लेकिन मुझे यकीन नहीं है कि पिछली बार के बाद से तर्कों और मूल्यांकन में बहुत बदलाव आया है! मुझे लगता है कि हम इंतजार करेंगे और देखेंगे ...

मैं अपने उपयोग के मामले को बाहर फेंकने जा रहा हूं और इस बारे में कुछ परिप्रेक्ष्य दूंगा कि हमारी दुकान इस समय कैसे दिखती है:

AspNetCore स्व-होस्टिंग (http.sys) वेब एपीआई और विभिन्न सेवाओं के आसपास स्थिर वेब सामग्री के मामले में हमारे स्टैक के लिए अद्भुत रहा है। हम नैन्सी से आए थे जो ठोस था, लेकिन हमारे दृष्टिकोण से भी कई खामियां थीं, इसलिए हमने लगभग एक साल पहले AspNetCore को बंद कर दिया था। आज, हम अपने हर कोडबेस को 2.x पर चला रहे हैं। कई मामलों में, हम एक शुद्ध .NET कोर लक्ष्य के लिए पूरी तरह से ठीक हो जाएंगे। लेकिन, ऐसी कई सेवाएँ हैं जिनका निर्माण हमने AspNetCore का लाभ उठाने के लिए किया है जो System.DirectoryServices और System.Drawing जैसी चीजों पर भी निर्भर करती हैं। इन सेवाओं के परिप्रेक्ष्य से, हम .Net फ्रेमवर्क से हटने से पहले वेब होस्टिंग तकनीक को बदल देंगे। दुर्भाग्य से, एक साथ और हमारी टीम के आकार में 2 अलग-अलग वेब होस्टिंग प्रौद्योगिकियों के प्रबंधन की जटिलताओं के कारण, हम संभवतः अपनी बाकी सेवाओं से AspNetCore को पूरी तरह से दोनों लक्ष्यों के बीच कुछ अधिक संगत के पक्ष में हड़ताल करेंगे।

इसे शीघ्र ही डालने के लिए - यह निर्णय हमें भविष्य में कुछ समय पर एस्पेन्कोर को पूरी तरह से बंद कर देगा (संभावित रूप से जब एलटीएस 2.x के लिए समाप्त हो जाता है), तो जो मैं अभी नहीं जानता उसके लिए। अगर यह इसके नीचे आता है, तो हम संभवतः एस्पेनकोर को बदलने के लिए अपना स्वयं का इन-हाउस समाधान लिखेंगे, क्योंकि हमारे उपयोग के मामले- AspNetCore की वास्तविक # के संदर्भ में उपयोग की जाने वाली सुविधाएँ काफी संकीर्ण हैं (कहा जा रहा है कि, हम जो सुविधाएँ प्रदान करते हैं वे _do और लेवरेज प्रदान करते हैं) आज हमारे लिए एक बहुत बड़ा मूल्य है)।

दूसरों को भी एक और वैकल्पिक ढेर चुन सकते हैं।

यह उचित है, लेकिन वैकल्पिक स्टैक में समान समर्थन नीति है। जावा एक समान LTS मॉडल (https://www.oracle.com/technetwork/java/javase/eol-135779.html) पर चला गया है।

निर्भरता का एक टन है जो आपके औसत उद्यम ऐप में पोर्ट नहीं किया जा सकता है और न ही किया जा सकता है।

@bencyoung

यह एक ढांचा है, पुस्तकालय नहीं। यह पुस्तकालयों के एक बहुत बड़े समूह से बना है जो एक साथ जहाज करते हैं।

मुझे समझ में नहीं आ रहा है कि ASP.NET Core क्या है अगर दोबारा साझा की जाने वाली साझा लाइब्रेरी नहीं है? यदि पुस्तकालयों के लिए आधुनिक और तेज होने की प्रवृत्ति .NET मानक समर्थन को छोड़ना है तो यह एक मुश्किल संदेश है। क्या Newtonsoft.Json को .NET Core 3 पर केवल तभी स्विच करना चाहिए, अगर यह बहुत तेज गति से चल सके? ऑटोफोक चाहिए?

मैं यह कैसे मुश्किल है देख नहीं है। मुझे लगता है कि 97% उन पुस्तकालयों के ढांचे को नहीं हटाएंगे क्योंकि उनके ग्राहक शिकायत करेंगे। बार फ्रेमवर्क हटाने के लिए बहुत अधिक है और यही कारण है कि हमने Microsoft.Extensions रखा। * .NET मानक 2.0 पर। मैं मानता हूं कि अगर हम वहां सब कुछ स्थानांतरित कर देते हैं तो यह फ़र्ज़ी होगा लेकिन यहाँ ऐसा नहीं है।

एक तरह से यह सिर्फ औपचारिकता है। क्या वास्तविकता पहले से ही .NET कोर पर है। हम .NET कोर के साथ ASP.NET कोर शिप करते हैं। .NET कोर ASP.NET कोर एक साझा ढांचा है, यह सिर्फ पैकेज का एक सेट नहीं है। वे पैकेज कभी भी समग्र उत्पाद से अलग नहीं होते हैं, इसलिए इन व्यक्तिगत पैकेजों को संदर्भित करने का लाभ छोटा होता है (पैकेज सूची भी छोटी btw है)।

@robkeimig

लेकिन, ऐसी कई सेवाएं हैं जिनका निर्माण हमने AspNetCore का लाभ उठाने के लिए किया है जो System.DirectoryServices और System.Dading जैसी चीजों पर भी निर्भर करते हैं

जो .NET कोर https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack पर विंडोज़ कॉम्पैक्ट पैक में मौजूद हैं

इसे शीघ्र ही डालने के लिए - यह निर्णय हमें भविष्य में कुछ समय पर एस्पेन्कोर को पूरी तरह से बंद कर देगा (संभावित रूप से जब एलटीएस 2.x के लिए समाप्त हो जाता है), तो जो मैं अभी नहीं जानता उसके लिए। यदि यह इसके नीचे आता है, तो हम संभवतः एस्पेनेटकोर को बदलने के लिए अपना स्वयं का इन-हाउस समाधान लिखेंगे, क्योंकि हमारे द्वारा उपयोग किए जाने वाले एस्पेनेटकोर के वास्तविक # के संदर्भ में उपयोग की जाने वाली सुविधाएँ काफी संकीर्ण हैं (कहा जा रहा है कि, हम जो सुविधाएँ उपलब्ध कराते हैं आज हमारे लिए एक बहुत बड़ा मूल्य है)।

अगर समर्थन बढ़ाया जाता तो क्या यह भी होता?

इसके अतिरिक्त, अब हमें अन्य सभी असमर्थित तकनीकों (AppDomains, Remoting, आदि) को पहले ट्रिम करना होगा, बजाय इसके कि वह समानांतर या बाद के चरण में उस काम को करने में सक्षम हो।

आप पहले 2.1 में माइग्रेट क्यों नहीं कर सकते?

सबसे बड़ा कारण यह है कि 3 साल की समर्थन सीमा का मतलब यह है कि आप उनके नहीं रह सकते। यह एक अल्पकालिक प्रवासन कदम है, एक ऐसा बिंदु नहीं है जहाँ आपके पास एक स्थिर दीर्घकालिक मंच हो सकता है। जिसका अर्थ है कि आपको एक गांठ में आगे की ओर पलायन के सभी दर्द को उठाना होगा क्योंकि आप आधे रास्ते में जाने का जोखिम नहीं उठा सकते हैं, कई उच्च प्राथमिकता वाली नई सुविधाओं के निर्माण के लिए प्रवास को रोक सकते हैं और फिर एक कठिन ब्लॉक खोजने के लिए प्रवास को समाप्त करने का प्रयास करते हैं और अपने सभी नए फीचर्स को पुराने कोड बेस पर वापस भेजना होगा।

सबसे बड़ा कारण यह है कि 3 साल की समर्थन सीमा का मतलब यह है कि आप उनके नहीं रह सकते।

ज़रूर, इसीलिए हम @DamianEdwards के अनुसार विस्तारित समर्थन की पेशकश करेंगे।

बस यह दिखाने के लिए कि यह निर्णय कितना परिणाम देता है - ब्लेज़र के बारे में क्या? क्या यह नेटस्ट्रेड पर आधारित होना बंद हो जाएगा? क्या हमें भी यही उम्मीद करनी चाहिए? ब्लेज़र को अगली बड़ी चीज़ के रूप में विज्ञापित किया जा रहा है। Github.com/aspnet से और क्या है जो वर्तमान में netstandard पर निर्भर करता है, इसे खोदेगा और अगले प्रमुख रिलीज़ पर नेट कोर में ले जाएगा? MSFT नियंत्रण में, लेकिन एस्पनेट रेपो के बाहर अन्य चीजों के लिए क्या योजना है, जो कि एस्पेनेटकोर के भाग्य को साझा करेगा?

@davidfowl

दूसरों को भी एक और वैकल्पिक ढेर चुन सकते हैं।

यह उचित है, लेकिन वैकल्पिक स्टैक में समान समर्थन नीति है। जावा एक समान LTS मॉडल (https://www.oracle.com/technetwork/java/javase/eol-135779.html) पर चला गया है।

जो छोटा विवरण आप देख रहे हैं, वह यह है कि जावा, और अन्य स्टैक, अभी भी .NET फ्रेमवर्क और .NET कोर के विपरीत संस्करणों में संगत हैं, बिना किसी मानक की आवश्यकता के जो आंशिक रूप से केवल रनटाइम कार्यान्वयन पर लागू होते हैं।

इसके लायक क्या है, मैं वर्तमान में अपनी कंपनी के पहले ASP.Net कोर ऐप को तैनात करने पर काम कर रहा हूं। .NET फ्रेमवर्क में हमारा वास्तव में भारी निवेश है, इसलिए .NET कोर के विपरीत ASP.Net कोर का उपयोग .NET .NET के विपरीत स्पष्ट दृष्टिकोण था।

अब मैं सोच रहा हूं कि क्या हम बाद में बहुत दर्द के लिए हमें स्थापित कर रहे हैं।

यहाँ बहुत सारी परस्पर चिंताएँ हैं। आप कहते हैं कि ASP.Net कोर कभी भी केवल .NET फ्रेमवर्क पर चलने के लिए नहीं थी। अतीत में ASP.Net Core के बारे में Microsoft का संदेश उस सुपर को स्पष्ट करने में विफल रहा।

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

हाल ही में बहुत कुछ सुझाव आया है कि कुछ महत्वपूर्ण विशेषताएं कभी भी .NET फ्रेमवर्क के लिए नहीं बन सकती हैं। (जैसे कि स्पैन की अनुकूलता जोखिम.NET फ्रेमवर्क 4.8 में लागू करने के लिए बहुत गंभीर माना जाने वाला प्रकार बताता है कि उन्हें कभी भी लागू नहीं किया जा सकता है, क्योंकि उन जोखिमों को 4.9 में कम क्यों किया जाएगा। इसी तरह की चिंताएं जाहिर तौर पर डिफॉल्ट इंटरफेस मेथड को घेर लेती हैं।) यह एक प्रमुख प्रतिमान बदलाव है जिससे कई डेवलपर खुश नहीं होंगे!

इस बहुत सूत्र के संदेशों से पता चलता है कि Microsoft .NET फ्रेमवर्क को एक विरासत विशेषता के रूप में मानना ​​शुरू कर रहा है, कुछ ऐसा जो समय के साथ कम और कम विकास पर ध्यान देगा, जब तक कि यह वास्तव में केवल सुरक्षा सुधार नहीं मिलता है।

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

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

इसलिए नई परियोजनाएं शुरू करने वाले उद्यमों को आश्चर्य होता है कि उन्हें क्या करना है। अधिक उद्यम के अनुकूल .NET फ्रेमवर्क, पदावनत होने के बहुत स्पष्ट संकेत प्रदर्शित कर रहा है, और इस प्रकार नए विकास के लिए कुछ बेहतर बचा है। दूसरी ओर .NET कोर मौजूद है, लेकिन काफी कम उद्यम के अनुकूल है।

तो यह मूल रूप से एक शेख़ी बन गया, लेकिन मुझे उम्मीद है कि यह बेहतर चिंताओं को दिखाता है जो कई डेवलपर्स कर रहे हैं।

@davidfowl

लेकिन, ऐसी कई सेवाएं हैं जिनका निर्माण हमने AspNetCore का लाभ उठाने के लिए किया है जो System.DirectoryServices और System.Dading जैसी चीजों पर भी निर्भर करते हैं

जो .NET कोर https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack पर विंडोज़ कॉम्पैक्ट पैक में मौजूद हैं

मुझे पता नहीं था कि संगतता पैक ने इस उपयोग के मामले का समर्थन किया था। आदर्श रूप से, हम .NET कोर को सब कुछ आगे बढ़ाना चाहते हैं, और यह वास्तव में एक अच्छा जवाब है (जिसे हम शुरू में अनदेखा कर सकते हैं)। हमारी सेवाओं को लिनक्स / OSX में स्थानांतरित करने की कोई योजना नहीं है, इसलिए ये टुकड़े हमारे लिए एक साथ फिट हो सकते हैं।

अगर समर्थन बढ़ाया जाता तो क्या यह भी होता?

समर्थन के संदर्भ में - मुझे ऐसा लगता है जैसे 20x में 2.x का LTS वाजिब है, अन्य सभी बाधाओं पर विचार करना जो इस दूरगामी चीज के साथ शामिल हैं।

अब मैं जो समझ रहा हूं, उसके आधार पर, हमें एक बार .NET .NET प्रोजेक्ट्स (w / संगतता पैक उपयोग के रूप में आवश्यक) की समीक्षा करने और बदलने का मौका मिलने के बाद, AspNetCore 3.x में अपग्रेड करने में आसानी महसूस होगी।

आपकी सहायता के लिए धन्यवाद।

मैंने उच्च दबाव वाली परियोजनाओं में 15 साल तक .NET (ज्यादातर C #) में लिखा। मैंने इतने साल बर्बाद किए और ग्राहकों का पैसा इंजीनियर की रूपरेखा से अधिक समय बर्बाद कर रहा है। मैं .NET कोर की अवधारणा से प्यार करता था। मेरे लिए यह NodeJS परियोजनाओं को लिखने की गति थी, लेकिन अद्भुत .NET पारिस्थितिकी तंत्र में (सभी वसा सहित)। दुर्भाग्य से यह उस वादे पर विफल रहा, यह अभी भी (इस नई घोषणा के साथ) अभी तक खूनी उपयोग के लिए बहुत जटिल है। पिछले 3 वर्षों से मैं NodeJS में निर्माण कर रहा हूँ, क्षमा करें दोस्तों, यह सिर्फ तुलना नहीं है। इसे और अधिक सरल और उपयोग में आसान बनाएं और आप व्यापक डेवलपर समुदाय को फिर से आकर्षित करेंगे।

कठिन, संकलित बाइनरी .NET फ्रेमवर्क निर्भरता (बिना स्रोत कोड वाला विक्रेता सामान) के लिए प्रोजेक्ट्स जो ASP.NET Core 2.1 में चल सकते हैं। Windows पर तैनात .NET फ्रेमवर्क को लक्षित करते हुए, परियोजना के लिए Windows संगतता पैक को जोड़कर उन्हें काम पर रखेगा। कोर 3.0 यदि हार्ड निर्भरता संदर्भ प्रकार पैक द्वारा आपूर्ति की जाती है?

अत्यंत परिपक्व वाणिज्यिक पुस्तकालयों का एक विशाल पारिस्थितिकी तंत्र है जो दुर्भाग्य से System.Drawing, GDI और कभी-कभी रजिस्ट्री (!) पर निर्भरता रखता है। यदि ये अब केवल 2.1 के साथ काम करेंगे और केवल तीन वर्षों के लिए समर्थित होंगे, तो यह एक ऐसा मुद्दा है जो कुछ उद्यमों में कोर को अपनाने से रोक सकता है।

.NET कोर शुरुआती बिंदु तक पहुंचने के लिए एक पूर्ण चक्र बना रहा है।

मैं एक और दृष्टिकोण सुझाता हूं: .NET .NET को .NET कोर की उपयोगी विशेषताओं को शामिल करने दें, और फिर प्रयोगात्मक कोर-एंड शाखा के रूप में .NET कोर को पूरी तरह से समाप्त करें। इस प्रकार ग्राहकों के अधिक लाभ के लिए विभाजन को रोकना और प्रौद्योगिकी को बचाना है। कुछ हद तक विवादास्पद, लेकिन उत्पाद के लिहाज से बहुत ही पवित्र दृष्टिकोण।

@davidfowl

.NET फ्रेमवर्क पर चलने वाला ASP.NET Core कभी भी एक स्थायी चीज़ नहीं था, यह हमेशा एक स्टेपिंग स्टोन के रूप में था

यह बिल्कुल सच नहीं है। ASP.NET Core पर संदेश हमेशा यह रहा है कि यह .NET कोर और .NET फ्रेमवर्क दोनों पर समर्थित है। यहां तक ​​कि .NET कोर की शुरुआती घोषणाओं में ASP.NET Core (फिर ASP.NET 5) के लिए दोनों प्लेटफार्मों का उल्लेख है।

.NET मानक से पता चलता है कि बहुत अच्छी तरह से ज्ञात "ASP.NET कोर में .NET फ्रेमवर्क को लक्षित करने के लिए समर्थन को हटाने की कोई योजना नहीं है।"

तो हाँ, यह स्पष्ट है कि यह निर्णय अब तक बदल गया है , लेकिन यह कहना कि यह हमेशा की तरह था या तो सिर्फ एक झूठ है, या माइक्रोसॉफ्ट द्वारा वर्षों में किया गया एक बहुत बुरा संचार है।

इसे ASP.NET Core भी कहा जाता है

ओह अब छोड़िए भी। बाद मेरे जैसे सभी इस समय लोग नेट कोर और ASP.NET कोर अलग करने के लिए लोगों से लड़ने के लिए है क्योंकि वे एक ही बात नहीं कर रहे हैं के लिए किया था, बस यहाँ अपने लाभ के लिए इसी तरह के नाम का उपयोग नहीं करते। यह उचित नहीं है। नाम को "कोर" में बदलना निश्चित रूप से इसे .NET कोर से स्पष्ट रूप से लिंक नहीं करना था। इसके अलावा, EF Core के पास एक "Core" भी है, लेकिन यह netstandard पर चलता रहेगा ताकि तर्क काम न करे।

यह वह जगह है जहाँ विस्तारित LTS समर्थन आता है। यदि आवेदन इन 6 वर्षों के बाद भी .NET कोर में कभी नहीं जा सकता है […]

यह अब भी कहां से आया? पिछली बार, संदेश अभी भी "हम एक 'विस्तारित समर्थन' एलटीएस पेशकश की जांच कर रहे हैं" । क्या यह अब एक वास्तविक बात है और हमें 6 साल हो जाएंगे?

@pjmlp

जो छोटा विवरण आप देख रहे हैं, वह यह है कि जावा, और अन्य स्टैक, अभी भी .NET फ्रेमवर्क और .NET कोर के विपरीत संस्करणों में संगत हैं, बिना किसी मानक की आवश्यकता के जो आंशिक रूप से केवल रनटाइम कार्यान्वयन पर लागू होते हैं।

उचित बिंदु, लेकिन मुझे समझ में नहीं आता कि बेहतर समर्थन के साथ क्या करना है। दावा किया गया था कि कम अपंग पुस्तकालयों (जो कि समय के मामले में एक बिंदु है) और उद्यम समर्थन (लंबे समय तक समर्थन चक्र) के कारण जावा पर स्विच करना बेहतर होगा।

@KevinCathcart

इस बहुत सूत्र के संदेशों से पता चलता है कि Microsoft .NET फ्रेमवर्क को एक विरासत विशेषता के रूप में मानना ​​शुरू कर रहा है, कुछ ऐसा जो समय के साथ कम और कम विकास पर ध्यान देगा, जब तक कि यह वास्तव में केवल सुरक्षा सुधार नहीं मिलता है।

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

Https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/ देखें

कठिन, संकलित बाइनरी .NET फ्रेमवर्क निर्भरता (बिना स्रोत कोड वाला विक्रेता सामान) के लिए प्रोजेक्ट्स जो ASP.NET Core 2.1 में चल सकते हैं। Windows पर तैनात .NET फ्रेमवर्क को लक्षित करते हुए, परियोजना के लिए Windows संगतता पैक को जोड़कर उन्हें काम पर रखेगा। कोर 3.0 यदि हार्ड निर्भरता संदर्भ प्रकार पैक द्वारा आपूर्ति की जाती है?

हाँ, यह द्विआधारी संगत है।

अत्यंत परिपक्व वाणिज्यिक पुस्तकालयों का एक विशाल पारिस्थितिकी तंत्र है जो दुर्भाग्य से System.Drawing, GDI और कभी-कभी रजिस्ट्री (!) पर निर्भरता रखता है। यदि ये अब केवल 2.1 के साथ काम करेंगे और केवल तीन वर्षों के लिए समर्थित हैं, तो यह एक ऐसा मुद्दा है जो कुछ उद्यमों में कोर को अपनाने से रोक सकता है

जैसा कि मैंने इस धागे पर कई बार उल्लेख किया है। हमने .NET कोर परियोजनाओं पर .NET फ्रेमवर्क के खिलाफ संकलित सीधे निर्भरता निर्भरता की क्षमता को जोड़ा।

@ पोक आप मैसेजिंग के बारे में सही हैं, यह मेरी गलती नहीं थी।

यह अब भी कहां से आया? पिछली बार, संदेश अभी भी था "हम एक 'विस्तारित समर्थन' एलटीएस पेशकश की जांच कर रहे हैं"। क्या यह अब एक वास्तविक बात है और हमें 6 साल हो जाएंगे?

मैंने 6 को बनाया, मुझे नहीं पता कि जब हम इसे पेश करेंगे तो विस्तारित समर्थन कैसे होगा।

.NET कोर हमेशा .NET फ्रेमवर्क को बदलने जा रहा था (मूल रूप से यह .NET फ्रेमवर्क 5 होने जा रहा था), लेकिन फिर से लिखना इतना महत्वाकांक्षी था कि डेस्कटॉप ऐप को सपोर्ट करने के लिए अब इसका उपयोग किया जाने लगा।

वाह, क्या कभी यहाँ बहुत सारी उल्लसित टिप्पणियाँ हैं। ऐसा लगता है कि बहुत सारे गलत तरीके से निकले हुए क्रोध हैं, जो लोगों के लेख को पढ़ने में असफल हैं।

समर्थन करना

@edandersen क्या आपने इन बाहरी dll पर
विंडोज़ कम्पैटिबिलिटी पैक सिस्टम के लिए पहले से ही कार्यक्षमता प्रदान करता है। रजिस्ट्री और रजिस्ट्री। क्या आपने इन चीजों को .NET कोर पर चलाने की कोशिश की थी? System.Drawing भी मोनो के libgdiplus का उपयोग करके * nix पर काम करता है। यह हमें एक्सेल फाइलों के साथ काम करने के लिए गैर-विंडोज सिस्टम पर क्लोज्डएक्सएमएल का उपयोग करने की अनुमति देता है।

हमारी कंपनी में "हाल ही में" अनुप्रयोगों के लिए सबसे बड़ी .NET फ्रेमवर्क निर्भरता WCF कार्यक्षमता है।
.NET कोर WCF क्लाइंट लाइब्रेरी में सुधार हो रहा है। मैंने वर्तमान स्थिति के लिए जाँच नहीं की है कि वे हमारे द्वारा उपभोग की जाने वाली कुछ सेवाओं के साथ कितने अच्छे काम करते हैं लेकिन अतीत में, हम कुछ सेवाओं से बात करने में असमर्थ थे। लेकिन लापता कार्यक्षमता पहले से ही उनकी जारी सूची में थी। सरल सेवाएं दूसरी ओर अच्छी तरह से काम करती हैं!
दूसरी ओर, .NET कोर में SOAP सेवाओं की मेजबानी के लिए "ड्रॉप" प्रतिस्थापन नहीं है। यह कुछ अनुप्रयोगों को .NET कोर में माइग्रेट करने से रोक देगा (लेकिन जैसा कि उल्लेख किया गया है - इसकी कोई आवश्यकता नहीं है)।
हाल ही में ASP.NET Core एप्लिकेशन के लिए हमने एक अतिरिक्त ASP.NET प्रॉक्सी वेब ऐप बनाया है जो सिर्फ WCF सेवा को होस्ट करता है और फिर HTTP / JSON के माध्यम से ASP.NET कोर एप्लिकेशन को फॉरवर्ड करता है। बहुत सुंदर नहीं है और तैनाती जटिलता जोड़ता है लेकिन यह कुछ एकीकरण बिंदुओं के लिए अनुमति देता है।

मैं यह नहीं कह रहा हूं कि मैं वास्तव में .NET कोर में डब्ल्यूसीएफ की मेजबानी की क्षमता चाहता हूं, यह देखते हुए कि मुझे इसे कॉन्फ़िगर करने में सिरदर्द होता है। SOAP सेवाओं की मेजबानी और WSDL उत्पन्न करने का कुछ विकल्प हालांकि ठंडा होगा। मैंने कुछ ओएसएस पुस्तकालयों को पहले से ही ऐसा करने की कोशिश करते देखा है। शायद यह काफी होगा।

@ davidfowl

उचित बिंदु, लेकिन मुझे समझ में नहीं आता कि बेहतर समर्थन के साथ क्या करना है। दावा किया गया था कि कम अपंग पुस्तकालयों (जो कि समय के मामले में एक बिंदु है) और उद्यम समर्थन (लंबे समय तक समर्थन चक्र) के कारण जावा पर स्विच करना बेहतर होगा।

मुद्दा यह है कि जबकि जावा एलटीएस संस्करण भी तीन साल के हैं, सभी प्रमुख कार्यान्वयनों के बीच संगतता सोने की है, जो कि आप कुछ लोग यहां खिड़की से बाहर फेंकने के लिए तैयार हैं।

यह पूरी .NET फ्रेमवर्क, .NET कोर, Xamarin, .NET मानक गलतियाँ एक बदलाव के लिए .NET टीमों के अंदर WinDev बनाम DevTools के अच्छे पुराने दिनों की तरह दिखना शुरू कर रही है।

इसलिए स्वाभाविक रूप से ग्राहक उन प्लेटफार्मों पर जाने के लिए तैयार हैं जो आंतरिक टीमों की तरह नहीं दिखते हैं जो रोडमैप सुविधाओं के लिए लड़ रहे हैं।

ये निर्णय आत्मविश्वास को प्रेरित नहीं करते हैं।

यह वास्तव में .NET टीम की ओर से गलती की तरह महसूस करता है, विशेष रूप से वर्तमान जलवायु के संदर्भ में!

जावा का उल्लेख करने वालों के लिए, क्या आपने वास्तव में देखा है कि हाल ही में वहाँ क्या चल रहा है? एंड्रॉइड में इसका उपयोग करने और उनके नवीनतम लाइसेंसिंग शनीगन्स पर Google के खिलाफ उनके बिल्कुल पागलपन के मुकदमों के बीच, ओरेकल का व्यवहार लगातार एक ऐसी कंपनी के रूप में प्रतीत होता है जो एक अवांछित उत्पाद को मारना चाहता है, बजाय इसके कि वह इसे फेंकना चाहता है!

Microsoft के लिए यह सही समय है कि वह शक्तिशाली विपणन के साथ इस बात को भुनाने के लिए सुझाव दे कि वे इसके ठीक विपरीत काम कर रहे हैं, और यह .NET, सुरक्षित, स्थिर, सुरक्षित विकास विकल्पों के लिए जगह है। इसके बजाय, हम ... यह। : निराश:

@masonwheeler

हम दोनों वातावरण में काम करते हैं वास्तव में ओरेकल के काम की सराहना करते हैं
जावा के साथ कर रहा है।

यह वह है जो शायद ही कभी उत्पादन में जावा का उपयोग करता है, ओरेकल को घृणा करता है, जो मिलता है
उनके खिलाफ नफरत भरे तर्कों में खो गए।

Android के संबंध में, मैं Google के रूप में मुकदमे का पूर्ण समर्थन करता हूं
जावा प्लेटफ़ॉर्म को कांटा करने में कामयाब रहा, इस प्रकार जहां Microsoft विफल रहा, वह सफल रहा
J ++ के साथ। फिर भी मावेन सेंट्रल में किसी भी यादृच्छिक जार को वास्तव में एंड्रॉइड पर काम करने की गारंटी दी जाती है।

.NET के लिए, मैं लगातार रिबूट से तंग आ रहा हूं
हमें Microsoft प्लेटफ़ॉर्म को कैसे लक्षित करना चाहिए।

पूरे WinRT, UAP, UWP, .NET नेटिव ड्रॉपिंग F #, XNA, Core 1.0 को छोड़ दिया है
बहुत सारे खट्टे अंगूर और यह हालिया निर्णय चीजों को बेहतर नहीं बनाता है
समग्र।

.NET मेरा पसंदीदा मंच है इसलिए कृपया इसे और भी खराब न करें।

@mythz

अब मुझे समझ में आ रहा है कि 2.1 .NET फ्रेमवर्क पर समर्थित अंतिम LTS संस्करण है जिसका अर्थ है कि इसमें अपग्रेड करने की कोई जगह नहीं है

इसका मतलब यह है कि यह एक असमर्थित मंच बन गया है, इस पर किसी को भी इसे लावा और हाथापाई की तरह व्यवहार करना पड़ता है, इससे पहले कि यह असमर्थित ईओएल अंत तक पहुंच जाए।

यह उन बिंदुओं में से एक है जिन्हें मैं पूरी चर्चा में नहीं समझता। आप वास्तव में सुरक्षा सुधारों के अलावा एलटीएस समर्थन से क्या प्राप्त करते हैं (जो विस्तारित एलटीएस समर्थन के साथ कवर किया जा सकता है)?

मुख्यधारा के एलटीएस समर्थन में उम्मीद करने के लिए सिर्फ दो चीजें हैं:

• सुरक्षा ठीक करता है
• क्रिटिकल बगफिक्स

अधिकांश पूर्व वाले (सुरक्षा सुधार) विंडोज अपडेट (जब आप .NET फ्रेमवर्क को लक्षित करते हैं) के माध्यम से पैच किए जाएंगे। तो केवल सुरक्षा और महत्वपूर्ण बग फिक्स शेष ASP.NET कोर में ही हैं।

मान लीजिए कि यह पहले से ही जानता है कि समर्थन 2018 समाप्त हो रहा है, मैं 2020 में किसी को भी नई परियोजनाएं शुरू करने की उम्मीद नहीं करूंगा, इसलिए इसकी (imho) संभावना नहीं है कि आपको 2021 (या 2026) या विस्तारित समर्थन के बाद एक महत्वपूर्ण शो-स्टॉपर बग मिल जाएगा। होने के लिए)।

यह सिर्फ सुरक्षा कीड़े खुला छोड़ देता है, जो एलटीएस के साथ कवर करने के लिए उचित है।

पिछले उत्तरों में मैंने टीएलएस 1.4 का उल्लेख करते हुए देखा था कि ये एलटीएस में वैसे भी शामिल नहीं होंगे क्योंकि यह एक नई सुविधा है, जो कि जावा के लिए भी समान है (जावा 6 केवल टीएलएस 1.0 सपोर्ट वाला है - टीएलएस 1.1 यदि आप में गिना जाए तो) गैर-सार्वजनिक अद्यतन केवल ओरेकल के विस्तार समर्थन ग्राहकों के लिए उपलब्ध हैं)।

• कोई भी व्यक्ति जो .NET कोर में जाने के लिए एक मंच के रूप में इसका उपयोग करने के बारे में सोचता है, एक कम संभव विकल्प बन गया है क्योंकि वे एक असमर्थित मंच पर फंसे होने के जोखिम का सामना करते हैं यदि माइग्रेशन अपेक्षा से अधिक समय तक होता है या वे आश्रितों में से किसी पर भी बाधा डालते हैं। वे .NET कोर पर नहीं चल सकते हैं पर भरोसा करते हैं।
  लेकिन कौन से एपीआई ऐसे हैं जो गायब हैं जो अब आप .NET फ्रेमवर्क पर ASP.NET कोर के साथ उपयोग कर सकते हैं, लेकिन .NET फ्रेमवर्क + संगतता पैकेज पर ASP.NET कोर पर नहीं कर सकते हैं?

मुझे लगता है कि यह अधिक महत्वपूर्ण बिंदु है, इसको पहचानने के लिए और या तो भविष्य के संगतता पैकेज के साथ लापता एपीआई को जहाज करें या उन्हें .NET कोर में जोड़ें, जिससे .NET कोर को लक्षित करते समय भी .NET फ्रेमवर्क पुस्तकालयों का संदर्भ संभव हो सके।

.NET कोर के बाद से आप .NET कोर प्रोजेक्ट में किसी भी .NET फ्रेमवर्क लाइब्रेरी का संदर्भ (और उपयोग) कर सकते हैं क्योंकि यह केवल .NET मानक या .NET कोर में उपलब्ध एपीआई का उपयोग करता है ।

यह पुस्तकालय लेखक को अपने पुस्तकालयों को netstandard / netcoreapp को लक्षित करने के लिए अद्यतन करने की आवश्यकता नहीं है।

शायद यह मदद करेगा अगर Microsoft nuget.org पर प्रत्येक नगेट पैकेज के बगल में एक सुविधा / लिंक द्वारा NuGet वेबपेज / लाइब्रेरी का विस्तार करेगा जो एक रिपोर्ट दिखाता है कि क्या यह लाइब्रेरी .NET कोर के विशिष्ट संस्करणों में उपलब्ध किसी भी असंगत API का उपयोग नहीं करती है?

उदाहरण के लिए

'Company.Example.MyLib' दिखाएगा

• .NET कोर 2.1: आंशिक समर्थन (विस्तृत रिपोर्ट) - जहां विस्तृत रिपोर्ट एपिस को वह काम दिखाएगी और जो ऐसा नहीं करती है
• .NET कोर 3.0:; पूरी तरह से समर्थित

यह .NET पोर्टेबिलिटी एनालाइज़र चलाकर संभव होना चाहिए? एक बोनस होगा, अगर यह सार्वजनिक एपीआई की सूची जोड़ता है जो कॉल करने के लिए सुरक्षित हैं (आईएल कोड का विश्लेषण करके और देखें कि अन्य एपीआई इसकी कॉलिंग को सुनिश्चित करने के लिए सुरक्षित हैं या नहीं)?

यह कम से कम डेवलपर्स के लिए यह निर्धारित करना आसान बनाता है कि क्या उनके प्रोजेक्ट के लिए आवश्यक एक विशिष्ट पुस्तकालय .NET कोर पर चल सकता है या नहीं, भले ही यह स्पष्ट रूप से कॉल न करता हो?

अभी इसके थोड़े दर्द का यह पता लगाने के लिए कि एपीआई का समर्थन किया जाता है या नहीं, आपको पुस्तकालय की आवश्यकता है, उस पर स्थानीय रूप से विश्लेषक को चलाएं। कई डेवलपर्स को पता नहीं हो सकता है कि वे कुछ पुस्तकालयों का उपयोग कर सकते हैं जो आधिकारिक रूप से नेटस्टैंडर्ड का समर्थन नहीं कर रहे हैं।

@davidfowl @terrajobst क्या यह

• किसी को भी अपने उद्यम के मौजूदा प्रबंधित बुनियादी ढांचे के .NET फ्रेमवर्क सर्वर का उपयोग करने के लिए मजबूर होना चाहिए, नए देव मॉडल और पारिस्थितिकी तंत्र का उपयोग करने में भाग नहीं ले सकता है और उन्हें अपने मौजूदा क्लासिक ASP.NET ज्ञान / कौशल को कम मूल्यवान प्रत्येक दिन देखना होगा।

.NET फ्रेमवर्क के समर्थन के लिए या उसके खिलाफ शायद ही कोई तर्क है। जो लोग विरासत निर्भरता पर अटके हुए हैं और .NET कोर में नहीं जा सकते हैं (संगतता पैक के साथ या .NET फ्रेमवर्क लाइब्रेरी के साथ) इसके बाद न तो कर पाएंगे। यह कैसे कुछ भी बदल जाएगा?

फिर भी, अखंड अनुप्रयोगों के कुछ हिस्सों को विभाजित किया जा सकता है और धीरे-धीरे विरासत आवेदन के कुछ हिस्सों को नए एक में स्थानांतरित कर सकता है, लेकिन एक अलग कहानी है।

• कोई भी संगठन एक अनियोजित माइग्रेशन में मजबूर नहीं होना चाहता है क्योंकि उनके बजट, योजना और निवेश निर्णयों को आधार बनाने के लिए उन्होंने जो मार्गदर्शन किया है वह बदल गया है।

यदि लाभ निवेश को कम करते हैं तो क्यों नहीं? यानी अगर कोई अनूठी विशेषताएं हैं जो आपको बदले में बड़ा मूल्य देती हैं या भारी प्रदर्शन को बढ़ावा देती हैं।

यदि नहीं, तो पुरानी प्रणाली पर बने रहें। सॉफ्टवेयर विकास हमेशा के लिए इस तरह से था। अभी भी फॉर्च्यून और कोबोल में विकसित सॉफ्टवेयर चलाने वाली कंपनियां हैं।

ऐसे कई लोग हैं जो .NET कोर में नहीं जा सकते हैं या नहीं करना चाहते हैं, वे चाहते हैं कि यह क्लासिक ASP.NET के समान समर्थन को साझा करे (जो कि वर्तमान संदेश का सुझाव अनिश्चित काल के लिए है)।

लापता APIs एकमात्र कारण नहीं है जो माइग्रेशन को रोकता है, उदाहरण के लिए वे एक निर्भरता पर भरोसा कर सकते हैं जहां देव टीम ने इसे अब अस्तित्व में नहीं बनाया है, यह एक महत्वपूर्ण घटक है जिसे बदला नहीं जा सकता है, इसे सुरक्षित रूप से नहीं बदला जा सकता है (उदाहरण के लिए) कोई परीक्षण नहीं), इसे अन्य .NET FX- केवल सिस्टमों के साथ साझा किया गया है, इसे किसी अन्य विभाग द्वारा बनाए रखा गया है जिसका कोई बजट नहीं है, इसे बदलने की क्षमता है या बाहरी कारकों जैसे उनके उद्यमों द्वारा प्रबंधित बुनियादी ढांचा केवल .NET फ्रेमवर्क सर्वर पर चलने का समर्थन करता है।

हाँ, लेकिन जो निर्भरताएँ? इन बाहरी निर्भरता का उपयोग करने वाले कौन से एपीआई की पहचान करने के लिए ठोस उदाहरण आवश्यक होंगे। यह एपीआई .NET कोर 3.0 या .NET कोर के भविष्य के संस्करण में जोड़ा जा सकता है।

यह .NET .NET प्रोजेक्ट्स में इस .NET फ्रेमवर्क लाइब्रेरी का उपयोग करना संभव बनाता है। एकमात्र समस्या यह है जब .NET फ्रेमवर्क लाइब्रेरी API का उपयोग करती है जो .NET मानक या .NET कोर में उपलब्ध नहीं हैं। लेकिन पुस्तकालयों की पहचान करने के लिए उस फीडबैक को ठीक करना आवश्यक है।

@pjmlp

@davidfowl

दूसरों को भी एक और वैकल्पिक ढेर चुन सकते हैं।

यह उचित है, लेकिन वैकल्पिक स्टैक में समान समर्थन नीति है। जावा एक समान LTS मॉडल (https://www.oracle.com/technetwork/java/javase/eol-135779.html) पर चला गया है।

जो छोटा विवरण आप देख रहे हैं, वह यह है कि जावा, और अन्य स्टैक, अभी भी .NET फ्रेमवर्क और .NET कोर के विपरीत संस्करणों में संगत हैं, बिना किसी मानक की आवश्यकता के जो आंशिक रूप से केवल रनटाइम कार्यान्वयन पर लागू होते हैं।

यह न तो बाद के जावा संस्करणों के लिए बिल्कुल सच है। जावा 9 ने रनटाइम को संशोधित करने के लिए पहला कदम जोड़ा, जो एक ब्रेकिंग परिवर्तन है । संस्करण 9 में, इसे डिफ़ॉल्ट रूप से अक्षम कर दिया गया है लेकिन भविष्य के संस्करणों में ध्वज को डिफ़ॉल्ट रूप से सक्षम किया जाएगा (या इसे बंद करने में सक्षम नहीं हो सकता है) और यह विरासत अनुप्रयोगों के लिए ब्रेकिंग परिवर्तन पैदा करता है।

उदाहरण के लिए कई पुस्तकालयों के लिए जो कुछ प्रतिबिंब जादू कैन के माध्यम से आंतरिक एपीआई का उपयोग करते हैं और उस परिवर्तन जाएंगे । और इनमें से कई पुस्तकालय, जैसे .NET दुनिया में हैं, अब बनाए नहीं रखे जाते हैं, इसलिए अपडेट की उम्मीद नहीं की जाती है।

@ TsengSR

जावा 9 में पेश किए गए ब्रेकिंग परिवर्तनों के बावजूद, सभी प्रासंगिक जावा फ्रेमवर्क के 100% जावा 9, 10 और 11 में काम करते हैं, जो निश्चित रूप से .NET फ्रेमवर्क, यूडब्ल्यूपी और कोर के मामले में नहीं है।

कल्पना करें कि यहां तक ​​कि दो आधिकारिक क्रॉस प्लेटफॉर्म जीयूआई फ्रेमवर्क भी हैं, जबकि हमें अभी भी कोर के लिए आधिकारिक रोडमैप नहीं मिला है!

@pjmlp

@ TsengSR

जावा 9 में पेश किए गए ब्रेकिंग परिवर्तनों के बावजूद, सभी प्रासंगिक जावा फ्रेमवर्क के 100% जावा 9, 10 और 11 में काम करते हैं, जो निश्चित रूप से .NET फ्रेमवर्क, यूडब्ल्यूपी और कोर के मामले में नहीं है।

कल्पना करें कि यहां तक ​​कि दो आधिकारिक क्रॉस प्लेटफॉर्म जीयूआई फ्रेमवर्क भी हैं, जबकि हमें अभी भी कोर के लिए आधिकारिक रोडमैप नहीं मिला है!

क्षमा करें, यह पूर्ण गैर-समझ है।

जावा 9 के आंतरिक मॉड्यूल, जो इन मॉड्यूल को प्रतिबिंबित करने से रोकते हैं जब तक कि --add-opens कहा जाता है (और iirc यह हमेशा एक अस्थायी समाधान माना जाता था ताकि लोग अपने विरासत अनुप्रयोग को चलाना जारी रख सकें और कुछ संस्करणों को बाद में हटा दें)।

यदि आप ड्रामा और श्टस्ट्रॉम से चूक गए थे, जब जावा 9 को रिलीज़ नहीं किया गया था, तो यह इस पर प्रतिक्रिया थी:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

संपूर्ण पारिस्थितिकी तंत्र को मॉड्यूलर जावा प्लेटफॉर्म पर माइग्रेट करने में मदद करने के लिए ए
अधिक आराम की गति जिसके कारण मैं अवैध चिंतनशील पहुंच की अनुमति देता हूं
JDK 9 में डिफ़ॉल्ट रूप से वर्ग पथ पर कोड से, और इसे इसमें अस्वीकृत करने के लिएभविष्य का विमोचन।

दूसरी बात, जावा EE 9 को JAX-WS को हटा दिया गया और जावा EE 11 में हटा दिया गया है। इसे लगभग WCF के समकक्ष के रूप में देखा जा सकता है। इसे लागू करने वाले किसी भी नए संस्करण में पोर्ट नहीं किया जा सकता है और न ही इसे किसी अन्य चीज़ से प्रतिस्थापित किए बिना, जो एक माइग्रेशन प्रक्रिया है। .NET फ्रेमवर्क पर ASP.NET कोर से ASP.NET कोर में माइग्रेट करने से अधिक या कम भिन्न नहीं है। .NET कोर पर ASP.NET कोर (या ASP.NET से ASP.NET Core @ .NET कोर)

https://www.oracle.com/corporate/features/understanding-java-9-modules.html

ग्रेटर प्लेटफ़ॉर्म अखंडता - जावा 9 से पहले, प्लेटफ़ॉर्म में कई कक्षाओं का उपयोग करना संभव था जो कि ऐप की कक्षाओं द्वारा उपयोग के लिए नहीं थे। मजबूत इनकैप्सुलेशन के साथ, ये आंतरिक API वास्तव में प्लेटफ़ॉर्म का उपयोग करके ऐप्स से इनकैप्सुलेटेड और हिडन होते हैं। यदि आपका कोड आंतरिक API पर निर्भर करता है तो यह जावा 9 समस्याग्रस्त को संशोधित करने के लिए माइग्रेटिंग विरासत कोड बना सकता है।

कोई भी एप्लिकेशन जो इन आंतरिक एपीआई का उपयोग करता है (सभी में sun.* नेमस्पेस शामिल है जो कुछ पुराने पुस्तकालयों ने उपयोग किया था - या जावा 9 जारी होने पर वापस उपयोग करने के लिए उपयोग किया गया था) या एक 3 पार्टी लाइब्रेरी का उपयोग करता है जो निर्भर करता है इस एपीआई या किसी अन्य पुस्तकालय में इस परिवर्तन के अधीन हो सकता है। इस पर समस्या है। जैसे .NET फ्रेमवर्क और .NET कोर यह है कि आप केवल उस लाइब्रेरी से नहीं देखते हैं जिसे API कहा जाता है या नहीं।

@TsengSR

जावा 9 के आंतरिक मॉड्यूल, जो इन मॉड्यूल को प्रतिबिंबित करने से रोकते हैं जब तक कि --add- खुलता नहीं है (और iirc यह हमेशा एक अस्थायी समाधान माना जाता था ताकि लोग अपने विरासत आवेदन को चलाना जारी रख सकें और कुछ संस्करणों को बाद में हटा दें)।

या आप क्लासपैथ मोड का उपयोग कर सकते हैं और उस गंदगी को छोड़ सकते हैं जो मॉड्यूल है। वह विधा भविष्य के लिए बनी रहेगी। और यदि आप मॉड्यूल में आते हैं, तो आप स्पष्ट रूप से अन्य मॉड्यूल के पैकेज में निर्भरता की घोषणा कर सकते हैं।

दूसरी बात, जावा EE 9 को JAX-WS को हटा दिया गया और जावा EE 11 में हटा दिया गया है। इसे लगभग WCF के समकक्ष के रूप में देखा जा सकता है।

J2EE के सभी को जावा 11 में हटा दिया गया है और हटा दिया गया है, जो पहले से ही बाहर है। लेकिन जे 2 ईई केवल इंटरफेस को परिभाषित करता है, कार्यान्वयन नहीं। J2EE का उपयोग जारी रखने के लिए, जो मैं करता हूं, आपको बस निर्भरता स्विच करने की आवश्यकता है। वैसे भी सभी कार्यान्वयन अलग थे, और वे जावा 11 में ठीक काम करते हैं।

कोई भी एप्लिकेशन जो इन आंतरिक APIs का उपयोग करता था (सूरज में सभी सहित। * नामस्थान जो कुछ पुराने पुस्तकालयों ने उपयोग किया था - या जावा 9 जारी होने के समय वापस उपयोग किया गया था) या इस API पर निर्भर एक 3rd पार्टी लाइब्रेरी का उपयोग करता है या कोई अन्य पुस्तकालय इस ब्रेकिंग परिवर्तन के अधीन हो सकता है।

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

कुछ APIs को हटा दिया गया है, लेकिन हम विशिष्ट API की बात कर रहे हैं और JRE या Java इकोसिस्टम की संपूर्णता की नहीं। उन API से नए, आधिकारिक और प्रलेखित API में जाने के लिए आवश्यक कार्य आम तौर पर न्यूनतम होते हैं।

और जावा हमेशा .NET की तुलना में पिछड़े संगतता को तोड़ने के लिए अधिक इच्छुक रहा है। उदाहरण के लिए, जावा में अब var नामक एक प्रकार की घोषणा करना गैरकानूनी है क्योंकि यह स्थानीय अनुमान के लिए आरक्षित है। जावा में एक चर _ का नाम देना गैरकानूनी है क्योंकि यह एक त्याग / वाइल्डकार्ड के रूप में उपयोग के लिए आरक्षित है। C # ने पिछड़े अनुकूलता के संरक्षण के नाम पर दोनों मामलों में सटीक विपरीत निर्णय लिया।

मुझे गलत मत समझो, जावा स्वयं गड़बड़ है। मॉड्यूल के बीच, जावा 8 के लिए एक छोर के पास समर्थन और ओरेकल जेआरई लाइसेंस के साथ लालची हो रहा है, माइक्रोसॉफ्ट के लिए लोगों को बदलने के लिए बड़े पैमाने पर अवसर है। लेकिन अगर माइक्रोसॉफ्ट अपने प्लेटफॉर्म के भविष्य के समर्थन और विकास के बारे में मिश्रित संदेश देने जा रहा है तो ऐसा होने की संभावना नहीं है।

@TsengSR

यह उन बिंदुओं में से एक है जिन्हें मैं पूरी चर्चा में नहीं समझता। आप वास्तव में सुरक्षा सुधारों के अलावा एलटीएस समर्थन से क्या प्राप्त करते हैं (जो विस्तारित एलटीएस समर्थन के साथ कवर किया जा सकता है)?

उस LTS पर एक टिक करने वाली घड़ी है जो कि अपग्रेड करने के लिए कहीं से समाप्त होने जा रही है, जो कि जावा LTS की तुलना में इधर-उधर फेंके जाने पर मुख्य बिंदु पर चमक रही है। जावा और .NET फ्रेमवर्क के साथ आपके पास हमेशा उच्च स्तर का विश्वास होता है कि आप मौजूदा सिस्टम को कम से कम प्रयास के साथ उन्नत कर सकते हैं, जो पीछे की संगतता पर अपना मजबूत ध्यान केंद्रित करता है। वर्तमान में अपग्रेड पथ नहीं होने के कारण, मौजूदा सिस्टम को एक नए रनटाइम पर माइग्रेट करने के लिए मजबूर किया जा रहा है या असमर्थित प्लेटफ़ॉर्म पर चलते रहना है। विभिन्न कारणों के लिए ऐसी प्रणालियाँ होंगी जहाँ यह असमर्थित प्लेटफ़ॉर्म पर अपने महत्वपूर्ण व्यावसायिक कार्यों को चलाने के लिए अपने भविष्य (इस निर्णय के साथ) को छोड़कर .NET कोर में स्थानांतरित करने के लिए संभव होगा।

यह निश्चित नहीं है कि इस फैसले का निकटतम रूपक जावा भूमि में क्या होगा, हो सकता है कि मौजूदा सिस्टम को GraalVM पर चलने के लिए मजबूर करने के लिए, बहुत सारी चीजें काम करेंगी, कुछ अभ्यस्त नहीं होंगे, सिस्टम जितना बड़ा होगा उतना कम आत्मविश्वास का अनुमान लगाने में सक्षम होगा जब तक एक प्रवास शारीरिक रूप से प्रयास नहीं किया जाता है।

मैं सहमत हूँ कि .NET कोर के लिए माइग्रेशन संभव बनाने के लिए बहुत कुछ किया गया है, लेकिन अभी भी कई बाहरी कारक (एमएस नियंत्रण से बाहर) होने जा रहे हैं जो माइग्रेशन को रोकने के लिए जा रहे हैं और यह निर्णय केवल करने जा रहा है इस घोषणा से पहले माइग्रेशन कम होने की संभावना है। ASP /Core / FX एक लोकप्रिय माइग्रेशन पथ था, लेकिन भविष्य में असमर्थित प्लेटफ़ॉर्म पर माइग्रेट करने के लिए समग्र माइग्रेशन रणनीति के लिए अनुशंसा करने के लिए विवेकपूर्ण नहीं होना चाहिए, जो कई माइग्रेशन को रोकने के लिए जा रहा है होने से अधिक मौजूदा सिस्टम / devs को स्थिर क्लासिक ASP.NET पर छोड़ा जा रहा है।

अधिकांश पूर्व वाले (सुरक्षा सुधार) विंडोज अपडेट (जब आप .NET फ्रेमवर्क को लक्षित करते हैं) के माध्यम से पैच किए जाएंगे। तो केवल सुरक्षा और महत्वपूर्ण बग फिक्स शेष ASP.NET कोर में ही हैं।

संगठन अपने उद्यम को आंशिक रूप से समर्थित मंच पर इस उम्मीद में नहीं रखना चाहते हैं कि भविष्य में बग या सुरक्षा के मुद्दे केवल उन पुस्तकालयों में होने वाले हैं जो समर्थन के लिए रखे गए हैं। यह एक लंबा रास्ता तय करेगा अगर ASP.Core / FX को शेष .NET फ्रेमवर्क के समान समर्थन द्वारा कवर किया जाएगा जहां किसी भी भविष्य की सुरक्षा कमजोरियों का समाधान होने वाला है।

वर्तमान में केवल MS ही अपडेटेड ASP.Core NuGet पैकेजों को पैच और रिलीज़ करने में सक्षम होगा, निर्भरता के पेड़ को OSS होने के कारण यहाँ बहुत मदद नहीं मिल रही है जब तक कि 2.1 PR के वे प्राप्त नहीं होते (पोस्ट LTS) की समीक्षा की जाएगी, स्वीकार की जाएगी का विमोचन किया।

अंत में सभी विवरणों के बाद अंतिम प्रश्न पर चर्चा की गई है जो अभी भी मायने रखता है:

क्या हम ASP.Core / FX पर अपने मौजूदा सिस्टम को जारी रख सकते हैं?

तकनीकी रूप से यह संभव होने जा रहा है, लेकिन इस आश्वासन के बिना कि भविष्य के महत्वपूर्ण कीड़े / सुरक्षा कमजोरियां हल होने जा रही हैं, सिफारिश नहीं हो गई है, जिससे बाहरी पारिस्थितिकी तंत्र प्रभावित होता है जो इस निर्णय के दर्द को अवशोषित करता है।

यदि ASP.NET Core केवल .NET Core होने जा रहा है, तो हमें पूरे .NET मानक चीज़ के बारे में कैसा महसूस करना चाहिए?

यदि Microsoft स्वयं (निस्संदेह मान्य) कारणों से इस पर दांव नहीं लगा रहा है, तो हमें क्यों करना चाहिए?

क्या प्रथम श्रेणी, ब्लीडिंग-एज .NET कोर केवल लिबास और "सरल" होगा, कम उन्नत .NET स्टैंडर्ड लिबास?

यह किसी भी गैर-नेट-कोर प्लेटफार्मों को बेहतर बनाने के लिए ड्राइव को मारने के लिए लगता है।

उम्मीद है कि कोई मुझे दिखा सकता है कि मैं गलत हूं और अपनी चिंताओं को कम कर सकता हूं।

नमस्ते,
मैं आगे बढ़ने में मूल्य देखता हूं और मैं इसे प्यार करता हूं, लेकिन मैं इस निर्णय के बारे में 3 मुख्य मुद्दों को देखता हूं:
1) netstandard एक दूसरी श्रेणी का नागरिक होगा यदि Microsoft के अंदर कोई भी इसके साथ कुछ मुश्किल नहीं बनाता है, अगर आप लोग dogfood नहीं करते हैं तो आप अन्य देव से इसे करने के लिए कैसे कह सकते हैं? आज पुस्तकालय लेखकों को वास्तव में कड़ी मेहनत करनी पड़ती है, अगर आंतरिक पीपीएल मानक का उपयोग नहीं करते हैं तो समर्थन में सुधार नहीं होगा।
2) अन्य रनटाइम्स में एस्पनेट कोर को चलाने में मूल्य है।
3) पुराने रनटाइम्स में सॉफ्टवेयर में वैल्यू है (निर्भरता जिसे कभी छुआ नहीं जाएगा) जिसे हल्के में नहीं छोड़ना चाहिए।

फिर वहाँ संचार है: मुझे लगता है कि हर कोई सिर्फ एक .net रनटाइम को पसंद करेगा जो हर जगह चलता है, लेकिन वह भविष्य के भविष्य के लिए स्वप्नलोक है और netstandard को सरोगेट के रूप में बनाया गया था। मेरे दृष्टिकोण से हर परियोजना जो कि नेटस्टैंडर्ड को लक्षित नहीं करती है, लेकिन एक ऐसा मंच है जो उस दृष्टि की दिशा में नहीं जाता है।
यह स्पष्ट है कि .net फ्रेमवर्क यह रखरखाव मोड में है, .netcore यह जगह लेगा (कुछ मृत शरीर को पीछे छोड़कर) और मोनो उपकरणों पर चलेगा, aot कहानी और CoreRT अग्रिम करने के लिए नहीं दिखते हैं।

नेटकोर 3.0 के साथ आप एक ही बार में दो काम कर रहे हैं: डेस्कटॉप वर्कलोड का समर्थन करना और "पीपीएल को प्रासंगिक रहने के लिए तुरंत कूदने के लिए कहना"। मुझे लगता है कि इसके लिए डेवलपर्स से विश्वास की एक छलांग की आवश्यकता होगी और यह बहुत ही आशावादी है क्योंकि हर कोई जानता है कि कई परियोजनाएं कुछ लापता निर्भरता के कारण माइग्रेट नहीं होंगी, जो शायद भविष्य में 1-2 साल में 3.1 / 3.2 रिलीज में जोड़ी जाएंगी ( 2.1 के 3 एलटीएस वर्षों के बहुत करीब)। इस बीच, जो देवता प्रासंगिक होना चाहते हैं, वे निर्भरता के कारण 3.0 बिट्स का उपयोग करने के लिए अवरुद्ध हैं, क्योंकि उनका कोई नियंत्रण नहीं है।

क्या पीपीएल के परीक्षण और वास्तविक निहितार्थ देखने के बाद इस निर्णय को स्थगित करना संभव होगा?
क्या यह संभव है कि एस्पेनेट कोर को आप नेटस्टैड और नेटकोरैप दोनों से संकलित कर सकें जैसे आप लाइब्रेरी लेखकों को करने के लिए लिख रहे हैं? .Net फ्रेमवर्क on पर चल रहे प्रदर्शन को समाप्त करना ठीक है

रोजलिन अब .NETStandard 2.0 -> https://github.com/dotnet/roslyn/pull/30914 पर चलता है

यह निश्चित रूप से कुछ मुश्किल के रूप में गिना जाता है!

@davidfowl

मेरा मानना ​​है कि यह .Net फ्रेमवर्क सिस्टम के भविष्य के विकास के लिए गंभीर रूप से सीमित विकल्प शुरू करने जा रहा है, जो विभिन्न कारणों से माइग्रेट नहीं कर सकता, क्योंकि समुदाय ASP.Net कोर के प्रयासों को स्थानांतरित कर रहा है।

उदाहरण के लिए आइडेंटिटी सर्वर पहले ही ASP.Net कोर में चला गया है और सिग्नलआर के

मुझे पता है कि ASP.NET Core के लिए LTS सपोर्ट पहले से ही 3 साल में सेट किया गया था, लेकिन ऑन-प्रिमाइसेस परिनियोजन के लिए एक लंबा जीवनचक्र आवश्यक है क्योंकि हमें अपने ग्राहकों को इन लाइनों (4 साल) के साथ सपोर्ट देना होगा।
इस अवधि के दौरान हमें ऐसे पैच जारी करने में सक्षम होने की आवश्यकता है जिसमें बिना किसी बड़े एप्लिकेशन परिवर्तन के सुरक्षा सुधार शामिल हैं। यह हमारे ग्राहकों को नियंत्रण नियंत्रण प्रक्रियाओं के साथ इनलाइन रखने के लिए है, जिसके लिए अधिक बड़े बदलावों के लिए उनके द्वारा व्यापक उपयोगकर्ता स्वीकृति परीक्षण की आवश्यकता होगी और इसलिए हमें बड़े बदलाव करने की आवश्यकता नहीं है जैसे कि रखरखाव मोड में जारी होने वाले नए संस्करण में माइग्रेट करना ।

क्या एलटीएस पॉलिसी को बदलने का कोई मौका है? 5 साल के समर्थन के साथ हर 2 साल में एलटीएस रिलीज की उबंटू की रणनीति जैसी कुछ - हालांकि मैं 6 के लिए पूछूंगा ताकि वर्तमान रिलीज को 3+ साल का समर्थन करने की अनुमति मिल सके, जबकि नए संस्करण में स्थानांतरित करने का काम किया जाए।

मैं समझता हूं कि विस्तारित समर्थन का उल्लेख किया गया है, लेकिन मुझे लगता है कि यह कुछ ऐसा है जिसे हमारे प्रत्येक ग्राहक को खरीदना होगा, जो मुझे विश्वास नहीं है कि उनका प्रारंभिक स्थापना (देव, बिक्री प्रक्रिया, यूएटी आदि) के बाद सबसे अच्छा होगा। 2 साल का समर्थन।

इसके अलावा, .netstandard पुस्तकालय में .netcore 3.0 बार इलाज करने के लिए उत्सुक।
.Netstandard का नारा है "उन सभी पर शासन करने के लिए एक पुस्तकालय"।
इससे पहले, यह लग रहा है कि यह सभी का मतलब है।
इसके बाद, ऐसा लगता है कि इसका मतलब थोड़ा है।

बस यह दिखाने के लिए कि यह निर्णय कितना परिणाम देता है - ब्लेज़र के बारे में क्या? क्या यह नेटस्ट्रेड पर आधारित होना बंद हो जाएगा? क्या हमें भी यही उम्मीद करनी चाहिए?

क्या कोई इसे स्पष्ट कर सकता है?

तो क्या .NET मानक के बजाय .NET कोर पर स्विच करने के लिए Newtonsoft.Json (जो उच्च प्रदर्शन से लाभ उठा सकते हैं) जैसे पुस्तकालयों के लिए सिफारिश है? मैं उस तरह के पुस्तकालय और ASP.NET Core के बीच बहुत अंतर नहीं देख रहा हूं। हम REST सेवाओं को बड़े अनुप्रयोगों में एम्बेड करते हैं - जिनमें से कुछ .NET कोर में आसानी से जा सकते हैं और कुछ नहीं।

मेरी समझ में पुस्तकालयों के लिए अनुशंसा .NET कोर 3 और .NET मानक 2.x दोनों को लक्षित करना है यदि आप नए एपीआई के लाभ प्राप्त करना चाहते हैं, लेकिन ऑडियंस को खोना नहीं चाहते हैं।

मेरी समझ में पुस्तकालयों के लिए अनुशंसा .NET कोर 3 और .NET मानक 2.x दोनों को लक्षित करना है यदि आप नए एपीआई के लाभ प्राप्त करना चाहते हैं, लेकिन ऑडियंस को खोना नहीं चाहते हैं।

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

.NET फ्रेमवर्क और .NET कोर एक ही भूमिका को भरते हैं, इसलिए मेरा मानना ​​है कि यह बहुत अपेक्षित है। ASP.NET कोर किसी दिन .NET फ्रेमवर्क पर नहीं चलेगा, यह अभी या बाद में होगा।

हालाँकि, मैं .NET Standard X पर नहीं चलने पर बड़ा मुद्दा देखता हूं। ईमानदार होने के लिए मुझे xamarin या एकता पर चलने के लिए asp.net कोर की आवश्यकता नहीं है, लेकिन यह कहने में सक्षम होने के लिए अच्छा है कि यह पुस्तकालयों का एक और सेट है जो .NET प्लेटफॉर्म पर चलता है। तोड़कर हम .NET कोर और ASP.NET कोर के बीच सख्त एकीकरण प्राप्त कर रहे हैं और मैं .NET Core 4.5 से डरता हूँ हम Microsoft.AspNetCore निंदा कर रहे हैं और @ DNav 2.0 शुरू कर रहे हैं।

दूसरी ओर .NET .NET निश्चित रूप से प्रयोग करने का स्थान नहीं है और चीजों को ठीक से प्राप्त करना मुश्किल है, तो क्या हम शायद समझौता कर सकते हैं? क्या ASP.NET Core करंट टारगेट केवल .NET कोर के लिए संभव होगा, लेकिन LTS संस्करण .NET मानक को लक्षित कर रहे हैं? यदि कोई एपीआई .NET मानक के लिए अपना रास्ता नहीं खोजता है तो क्या यह वास्तव में इसका उपयोग करने लायक है?

हम इस तरह से भी देख सकते हैं जिस तरह से आप शायद इसका इरादा करते हैं:

• .NET कोर कंसोल / वेब / 3rdparty डेस्कटॉप (मानक + वेब विशिष्ट एपीआई) के लिए है
• एकता खेलों के लिए है (मानक + गेम विशिष्ट एपीआई)
• Xamarin उपकरणों / डेस्कटॉप (मानक + डिवाइस / डेस्कटॉप विशिष्ट एपीआई) के लिए है

लेकिन कौन .NET मानक को आगे बढ़ाता है? जैसा कि आप पहले कह चुके हैं कि संसाधन सीमित हैं, इसलिए बिना चीजों को आगे बढ़ाने के लिए वास्तविक आवश्यकता के बिना (जिसमें मेरा प्रस्ताव एलटीएस जारी करने के लिए बदलाव की आवश्यकता के द्वारा .net कोर / asp.net कोर टीम में गिर जाएगा) मुझे डर है। NET Standard जल्दी बासी हो जाएगा।

ध्यान न देने वालों के लिए यह .NET मानक 2.1 दिखाई देता है। बस .NET फ्रेमवर्क के लिए समर्थन छोड़ दिया।

.NET मानक 2.1 में कई एपीआई परिवर्धन को देखते हुए सार्थक होने के लिए रनटाइम परिवर्तनों की आवश्यकता होती है। .NET फ्रेमवर्क 4.8 .NET .NET 2.1 को लागू करने के बजाय .NET मानक 2.0 पर रहेगा। .NET Core 3.0 के साथ-साथ Xamarin, मोनो और यूनिटी के आगामी संस्करणों को .NET मानक 2.1 को लागू करने के लिए अपडेट किया जाएगा।

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

जितना मुझे यह देखना है कि .Net फ्रेमवर्क सिल्वरलाइट-एड हो रहा है, एएसपी.नेट कोर के संबंध में मेरे लिए क्या मायने रखता है, यह देखने के लिए बहुत दुखद है कि यह .NET मानक को लक्षित करना चाहिए।

जैसा कि संभावना है कि कोर / मानक पारिस्थितिकी तंत्र में सबसे बड़े संदर्भ अनुप्रयोगों में से एक है, मेरा मानना ​​है कि ASP.NET Core के पास .Net मानक के चैंपियन और सभी अच्छी चीजों के लिए एक जिम्मेदारी है।

मेरा मानना ​​है कि ASP.NET Core के लिए यह उचित है कि .NET .NET में लागू होने वाले मानक में बदलाव का अनुरोध किया जाए।

उसी तरह से जैसे कि स्पैंग आदि _is_ एक नेटगेट पैकेज के माध्यम से .Net फ्रेमवर्क में उपलब्ध है, मेरा मानना ​​है कि यह उचित है कि अगर ASP.NET कोर को कुछ ऐसी चीज़ों पर निर्भर रहना चाहिए / जो अभी तक .NET नेट में नहीं हैं, तो उस निर्भरता को शामिल किया जाना चाहिए। एक नगेट पैकेज के माध्यम से।

अंत में, मुझे आशा है कि (इसके विपरीत सभी सबूतों के खिलाफ), कि एक .Net फ्रेमवर्क 5.0 होगा जो लक्ष्य .Net मानक 3.0+ को लक्षित करेगा और 4.x के साथ एक साइड-बाय-साइड इंस्टालेशन होगा।

अंत में, मुझे आशा है कि (इसके विपरीत सभी सबूतों के खिलाफ), कि एक .Net फ्रेमवर्क 5.0 होगा जो लक्ष्य .Net मानक 3.0+ को लक्षित करेगा और 4.x के साथ एक साइड-बाय-साइड इंस्टालेशन होगा।

हाँ बिल्कुल। यह वही है जो मैं अब वर्षों से कह रहा हूं: सीएलआर 2.0 आर्किटेक्चर ने हमें लंबे समय तक अच्छी तरह से सेवा दी है, लेकिन यह दांत में लंबे समय से शुरू हो रहा है, और यह उसी तरह के मौलिक उन्नयन का समय है जैसा कि जेनरिक था। यह कुछ हद तक आवश्यक परिवर्तन करने के दर्द हो सकता है, लेकिन वे आवश्यक हैं; नए के साथ अद्यतन करना, उसी तरह से अधिक शक्तिशाली कार्यक्षमता की आवश्यकता होती है जेनेरिक की आवश्यकता थी, और इसे बंद करने से केवल उस दर्द को बदतर बना दिया जाएगा, इसे कम नहीं, जब यह अंततः होता है।

ठीक वही है जो .NET कोर है, और यह धागा अस्थायी दर्द का अनुभव किया जा रहा है।

@terrajobst ने कहा कि ऐसा नहीं होगा: थ्रेड देखें: https://twitter.com/terrajobst/status/1059525279431815168?s=19

@gulbanana
हां, दो चीजों को छोड़कर।

1. कोर फ्रेमवर्क से अपग्रेड नहीं है ; यह एक समानांतर अवधारणा है। ऐसी बहुत सारी मौलिक चीजें हैं जो यह नहीं कर सकती हैं, जिनमें से कई, जैसे कि AppDomains, हमें बताया जा रहा है कि ऐसा कभी होने की संभावना नहीं है। स्वर्ग की खातिर, हमारे पास अभी भी Reflection.Emit ! संकलक और कोड जेनरेशन टूल में कितना सामान्य है, यह देखते हुए, आपको लगता है कि यह सचमुच पहली प्राथमिकताओं में से एक होगा, और फिर भी यहां हम 4 साल बाद हैं और यह काम नहीं करता है! इससे "कोर के प्रतिस्थापन / .Net फ्रेमवर्क के उन्नयन के रूप में" की धारणा को गंभीरता से लेना बहुत मुश्किल हो जाता है।
2. कोर मौलिक रूप से रनटाइम, सीएलआर 2.0 शैली को अपग्रेड नहीं कर रहा है। "क्या भाषा के प्रस्तावों से सीएलआर परिवर्तन से लाभ होगा?" हमारे पास लापता विशेषताओं के समुदाय से एक महान सूची है जिसे लोग महत्वपूर्ण मानते हैं, जो CLR का समर्थन नहीं कर सकता है, (या कम से कम बड़े पैमाने पर समर्थन नहीं कर सकता, सीएलआर की सीमाओं के आसपास काम करने के लिए बदसूरत कीचड़), आमतौर पर लापता विशेषताओं के कारण प्रकार प्रणाली में। कोर टीम द्वारा उस विषय के कितने प्रस्तावों को गंभीरता से लिया जा रहा है? और उनमें से कितने को हाथ से निकाल दिया गया है क्योंकि परियोजना चलाने वाले लोग रनटाइम को अपग्रेड नहीं करना चाहते हैं? हम DIM हो रहे हैं और ... कुछ और? कुछ भी?

तो नहीं, .NET कोर एक अपग्रेडेड .NET फ्रेमवर्क नहीं है, जो बहुत जरूरी सीएलआर अपडेट करता है, क्योंकि यह एक अपग्रेडेड .NET फ्रेमवर्क नहीं है और प्रोजेक्ट टीम वे सभी कर रही है, जहां भी संभव हो, सीएलआर को अपडेट करने से बचना चाहिए। यह सचमुच इसके विपरीत है।

स्वर्ग की खातिर, हमारे पास अभी भी एक काम नहीं है प्रतिबिंब! संकलक और कोड जेनरेशन टूल में कितना सामान्य है, यह देखते हुए, आपको लगता है कि यह सचमुच पहली प्राथमिकताओं में से एक होगा, और फिर भी यहां हम 4 साल बाद हैं और यह काम नहीं करता है! इससे "कोर के प्रतिस्थापन / .Net फ्रेमवर्क के उन्नयन के रूप में" की धारणा को गंभीरता से लेना बहुत मुश्किल हो जाता है।

यह समझने के लिए बहुत अच्छा होगा कि क्या काम नहीं करता है। ASP.NET Core और EF एक दो स्थानों पर परावर्तन उत्सर्जन का उपयोग करते हैं इसलिए मुझे बड़े अंतराल के बारे में जानकारी नहीं है। क्या आप यहाँ विस्तृत कर सकते हैं?

यह कम से कम 2.0 के बाद से वहाँ है .. iirc भी 1.0 DefineDynamicAssembly था, हालांकि शायद सामान का पूरा सूट नहीं।

मुझे यह विचार करना भी मुश्किल है कि वे सीएलआर को अपडेट करने से बच रहे हैं। क्या आपने देखा है कि काम की मात्रा बढ़ रही है? https://github.com/dotnet/coreclr/commits/master
C # 8 के लिए स्लेटेड भाषा सुविधाएँ हैं जो केवल CLR परिवर्तनों के कारण .NET कोर पर काम करेंगी। इनमें से बहुत सी आपत्तियां सिर्फ पुरानी जानकारी लगती हैं (जो कि काफी हद तक सही है, क्योंकि माइक्रोसॉफ्ट की योजनाएं कई बार तेजी से बदली हैं ...)

@davidfowl

यह समझने के लिए बहुत अच्छा होगा कि क्या काम नहीं करता है। ASP.NET Core और EF एक दो स्थानों पर परावर्तन उत्सर्जन का उपयोग करते हैं इसलिए मुझे बड़े अंतराल के बारे में जानकारी नहीं है। क्या आप यहाँ विस्तृत कर सकते हैं?

माना जाता है कि मेरी जाँच के कुछ महीने हो गए हैं, इसलिए यह हाल ही में बदल गया हो सकता है, लेकिन जहाँ तक मुझे पता है कि यह स्मृति में एक नई असेंबली बनाना संभव है, लेकिन आर्क की वजह से इसे डिस्क पर सहेजना नहीं है क्योंकि इसमें पीढ़ी शामिल है पीडीबी फाइलें, जो कोर को अपने जैसे कंपाइलर मेंटेनर के लिए बेकार बना देती हैं।

क्या यह तय किया गया है? मुझे यह सुनकर खुशी होगी कि यह ...

@gulbanna

मुझे यह विचार करना भी मुश्किल है कि वे सीएलआर को अपडेट करने से बच रहे हैं

मैंने जो कहा है कि वे 2.0 अपडेट (जेनरिक) के रूप में सीएलआर को उसी शैली में अपग्रेड करने से बच रहे हैं।

विशेष रूप से, वे सक्रिय रूप से किसी भी परिवर्तन से बचने के लिए प्रतीत होते हैं जो नए बुनियादी प्रकार के प्रकारों को टाइप सिस्टम में जोड़ देगा, (आकार, मेटाक्लासेस, डीयू, आदि) या निर्देश सेट में नए IL निर्देश।

@masonwheeler

बेशक, मुझे जाँच किए कुछ महीने हो गए हैं, इसलिए यह हाल ही में बदल सकता है, लेकिन जहाँ तक मुझे पता है कि स्मृति में एक नई असेंबली बनाना संभव है, लेकिन इसे डिस्क पर सहेजने के लिए नहीं

Https://github.com/dotnet/corefx/issues/4491 (जहां आपने पूर्व में टिप्पणी की है) को देखते हुए, मुझे लगता है कि स्थिति अभी भी वही है। हालांकि मुझे लगता है कि एक विशिष्ट सुविधा (भले ही यह एक महत्वपूर्ण है) को याद करना "हम अभी भी एक कार्य Reflection.Emit " से बिल्कुल अलग नहीं है।

जो अपने आप को बनाए रखने के लिए कोर को बेकार बनाता है

कैसे परावर्तन है। एक संकलक लेखक के लिए कभी भी उपयोगी है? मुझे लगा कि यह वर्तमान ढांचे के लिए असेंबलियों के उत्पादन तक सीमित है, इसलिए इसका उपयोग उदाहरण के लिए .Net मानक असेंबली बनाने के लिए नहीं किया जा सकता है, जो मुझे लगता है कि किसी भी संकलक के लिए एक महत्वपूर्ण सीमा होगी।

मैंने जो कहा है कि वे 2.0 अपडेट (जेनरिक) के रूप में सीएलआर को उसी शैली में अपग्रेड करने से बच रहे हैं।

मुझे लगता है कि सीएलआर को नहीं बदलने के लिए कुछ जड़ताएं रही हैं, हालांकि इसके लिए कुछ बहुत अच्छे कारण भी हैं, खासकर यदि आप मानते हैं कि जब एक मंच युवा होता है तो ऐसे परिवर्तन सबसे उपयोगी और कम से कम दर्दनाक होते हैं।

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

@svick

हालांकि मुझे लगता है कि एक विशिष्ट सुविधा (भले ही यह एक महत्वपूर्ण है) को याद करना "हम अभी भी एक कार्यशील प्रतिबिंब नहीं है" से काफी अलग है।

यदि आपके पास एक पाठ संपादक है जो आपको पाठ फ़ाइलों को टाइप करने दे सकता है, लेकिन उन्हें सहेज नहीं सकता है, तो क्या आप यह नहीं कहेंगे कि यह काम नहीं करता है?

कैसे परावर्तन है। एक संकलक लेखक के लिए कभी भी उपयोगी है?

यह अभी तक ठीक काम किया है। और जहां तक ​​मुझे पता है कि यह एकमात्र संकलक बैकएंड उपलब्ध है जो आपको दोनों नई असेंबली बनाने और उन्हें सहेजने या इन-मेमोरी में नई असेंबली उत्पन्न करने और उन्हें निष्पादित करने की अनुमति देता है।

अभी भी नए आईएल निर्देशों की उम्मीद नहीं होगी जब जेआईटी इंट्रिनिक्स अक्सर काम कर सकते हैं

ज़रूर, लेकिन उन मामलों के बारे में जो वे नहीं करेंगे?

या नए प्रकार के प्रकार जब वे मौजूदा प्रकार की प्रणाली में यथोचित एन्कोडेड हो सकते हैं।

क्या आपने मौजूदा प्रकार की प्रणाली के भीतर आकृतियाँ लागू करने का प्रस्ताव देखा है? इसके बारे में कुछ भी उचित नहीं है; यह शुरू से अंत तक एक बड़ा, बदसूरत कीचड़ है। (इसके साथ आने वाले लोगों के खिलाफ कुछ भी नहीं; यह इस तरह का होना चाहिए, इसके साथ काम कर रही सीमाओं को देखते हुए।) और सीएलआर-स्तरीय समर्थन के बिना सभी पर मेटाक्लासिस लागू करने के लिए शुभकामनाएं!

हमें किसी भी तरह के कुशल तरीके से उच्च-स्तरीय सुविधाओं को विकसित करने के लिए एक अद्यतन सीएलआर की आवश्यकता है, और कोई भी वास्तव में कोर के बारे में लाने के लिए काम नहीं कर रहा है।

क्या .net टीम का कोई व्यक्ति यह स्पष्ट कर सकता है कि ऑन-प्रिमाइसेस के लिए उनकी सिफारिश क्या है? क्या यह सिर्फ "नियमित रूप से asp.net का उपयोग करें" है? मैं विशेष रूप से @ Edward84 की टिप्पणियों के लिए बोल रहा हूं

क्या यह Microsoft.Extensions.* समर्थन पुस्तकालयों को प्रभावित करता है? विशेष रूप से Microsoft.Extensions.Logging और Microsoft.Extensions.Configuration ।

हमारे पास एक बड़ा कोड आधार है जो एक सामान्य कोर एपीआई साझा करता है। इसमें से कुछ WinForms हैं, कुछ क्लासिक ASP.NET, कुछ WCF आदि हैं। और नवीनतम अनुप्रयोग .NET कोर हैं (वर्तमान में नहीं, लेकिन अंततः जब हमने अपने मूल पुस्तकालयों को .NET मानक पर पोर्ट किया है)

हमने ऊपर उल्लिखित पुस्तकालयों में अमूर्तता पर हमारे कोर लॉगिंग और कॉन्फ़िगरेशन एपीआई को आधार बनाने के लिए चुना है।

इसलिए मैं सोच रहा हूँ कि क्या ये .NET .NET और .NET फ्रेमवर्क (4.7.2+) द्वारा संदर्भित .NET मानक एपीआई में उपयोग करने के लिए सुरक्षित हैं या क्या वे केवल .NET कोर सुविधाओं का उपयोग करना शुरू कर सकते हैं?

@mvestergaard जैसा कि घोषणा में ही उल्लेख किया

Microsoft.Extension पैकेज (जैसे लॉगिंग, निर्भरता इंजेक्शन और कॉन्फ़िगरेशन) .NET मानक का समर्थन करना जारी रखेंगे

और इस सूत्र में @badadams की टिप्पणी:

सभी पुस्तकालय केवल .NET कोर पर नहीं जा रहे हैं (जैसे Microsoft.Extensions.* .NET मानक के रूप में रह रहे हैं)

@mvestergaard जैसा कि पहले ही उल्लेख किया गया है कि हम अपनी LTS नीति को यह निर्धारित करने के लिए देख रहे हैं कि क्या विस्तारित समर्थन, लंबी अवधि, एक "रखरखाव मोड" अवधि, आदि जैसी चीजें उपयोगी हैं और वे कैसी दिखेंगी। हम यह देखने के लिए भी काम कर रहे हैं कि क्या हम नई एलटीएस ट्रेनों के समय को और अधिक पूर्वानुमानित कर सकते हैं (एक मॉडल जिसे हम देखते हैं और वास्तव में अन्य स्टैक से एलटीएस मॉडल है) की प्रशंसा करते हैं।

मेरे पास इसके साथ सबसे बड़ी समस्या परिपक्व पैकेजों का उपयोग करने में सक्षम नहीं है जो केवल .NET फ्रेमवर्क को लक्षित करते समय उपयोग किए जा सकते हैं या वे जो .NET Framework के बाहर उपलब्ध नहीं थे जैसे कि जरूरत थी। System.Drawing और GDI +।

ऐसा लगता है कि बाद का परिदृश्य .NET कोर 3.0 में समर्थित होने जा रहा है, हालांकि AFAICT, हम अभी भी स्थिर, परिपक्व पुस्तकालयों का उपयोग करने से चूक जाएंगे जिन्हें केवल .NET फ्रेमवर्क पर उपयोग किया जा सकता है।

इसका एक उदाहरण एंटिटी फ्रेमवर्क है । हमें अपरिपक्व EF Core पर स्विच करना होगा जो कि उन सभी जटिल परिदृश्यों से निपटने के लिए एक लंबा रास्ता तय करता है जो कि पूर्ण EF हो सकता है और जो उस समस्या को छिपाने के लिए आपकी पीठ के पीछे इन-मेमोरी क्लाइंट मूल्यांकन पर वापस आता है जो प्रदर्शन का कारण बनता है समस्याएं ।

इसका एक उदाहरण एंटिटी फ्रेमवर्क है। हमें अपरिपक्व EF Core पर स्विच करना होगा जो कि उन सभी जटिल परिदृश्यों से निपटने के लिए एक लंबा रास्ता तय करता है जो पूर्ण EF के पास हैं ...

EF6 .NET कोर 3.0 में समर्थित होने जा रहा है जैसा कि इस सप्ताह ASP.NET सामुदायिक स्टैंडअप पर - 6 नवंबर, 2018 - ASP.NET Core 3.0 19:06 पर

@ बबनादाम बड़ी खबर है! बहुत बड़ी बात है! :) अच्छी नौकरी मिल रही है। इसका एक और उल्लेख यहां मिला।

@ SaebAmini : आप सिस्टम का उपयोग कर सकते हैं। .NET कोर पर आकर्षित। System.Drawing.Common और Scott Hanselmans Blogpost देखें: https://www.hanselman.com/blog/HowDoYouUseSystemDrawingInNETCore.aspx ,

और इससे पहले CoreCompat.System.Drawing मौजूद था, मोनो के System.Drawing पोर्ट के रूप में।

क्या कोई विशेषता है जो .NET कोर पर चलने पर आपके उपयोग के मामले के लिए गायब है?

@TsengSR मेरा विशिष्ट परिदृश्य जिसने हमें .NET फ्रेमवर्क को लक्षित किया था:

1. Microsoft सॉल्वर फाउंडेशन पैकेज का उपयोग करने की आवश्यकता, केवल .NET फ्रेमवर्क में उपलब्ध है।
2. एक बारकोड इमेज जेनरेशन पैकेज जो System.Drawing का उपयोग करता है।
3. EF6 का उपयोग करने की आवश्यकता है।

यह करीब एक साल पहले की बात है।

@SaebAmini : जैसा कि पहले उल्लेख किया गया था, EF6 का समर्थन .NET Core 3.0 में आता है, System.Drawing पहले से ही है (और इससे पहले CoreCompat पैकेज मौजूद था और आपके मामले में काम कर सकता था) और Microsoft Solent Foundation पैकेज के लिए, के बाद पोर्टेबिलिटी एपीआई एना एनालाइजर चलाना:

पोर्टेबिलिटी एनालाइजर का उपयोग कैसे करें देखें

https://gist.github.com/TsengSR/f61c03c5f2d63dbe78d6d8b8c1eed08831 (इसे डाउनलोड

यह .NET कोर 2.0 + प्लेटफ़ॉर्म एक्सटेंशन (जो एक साल पहले जारी किया गया था) के साथ 97.93% संगतता दिखाता है और यह असंगत APIs को सूचीबद्ध करता है, जो ज्यादातर System.Web जो कि System.ServiceModel / System.Data.Linq ।

अब, मैंने पहले इस पैकेज का उपयोग नहीं किया, और मुझे यकीन नहीं है कि एक सॉल्वर को System.Web और HttpContext या System.ServiceModel , लेकिन यदि आप डॉन किसी भी शोध की आवश्यकता नहीं है (और आप जानते हैं कि आपका उपयोग मामला इस एपीआई को कॉल नहीं कर रहा है), संभावना बहुत अधिक है, कि आप इसे .NET कोर 2.0 / 2.1 + प्लेटफ़ॉर्म एक्सटेंशन या .NET कोर 3.0 पर भी उपयोग कर सकते हैं, यहां तक ​​कि यदि यह विशेष रूप से netstandard या netcoreapp20 लक्ष्य मुनिकर को लक्षित नहीं करता है।

तो तकनीकी रूप से संभावनाएं अच्छी थीं कि आप अपने आवेदन को एक साल पहले .NET कोर 2.0 + प्लेटफॉर्म एक्सटेंशन्स पर माइग्रेट कर सकते थे, अगर ईएफ कोर 2.0 आपके एप्लिकेशन की जरूरतों को पूरा कर सकता था (निश्चित रूप से कुछ माइग्रेशन काम और अपडेट के लिए काम करने की आवश्यकता है ईएफ कोर 2.0 के साथ)।

हां, प्रश्न में पुस्तकालयों या प्रतिस्थापन ढांचे (ईएफ 6 -> ईएफ कोर 2.0 / 2.1) के लिए विश्लेषण करने में थोड़ा अधिक काम लगता है, लेकिन यह असंभव से बहुत दूर है। मुझे नहीं लगता है कि लोगों को अपने सभी कोड 1: 1 को ASP.NET Core w / o में पोर्ट करने की उम्मीद करनी चाहिए (बिल्कुल ASP.NET Core के बाहर)।

बस इच्छा थी कि एपीआई संगतता प्रदर्शित होना अधिक स्पष्ट होगा, जैसे "बैज" (.NET कोर 3.0 संगत) और / या विस्तृत एपीआई संगतता रिपोर्ट कहीं नगेट पृष्ठ पर पैकेज को डाउनलोड करने की तुलना में अधिक स्पष्ट करने के लिए। और फिर पैकेज विश्लेषक के माध्यम से इसे चलाएं।

मुझे लगता है कि यह घोषणा बेहतर ढंग से प्राप्त होती अगर यह जोर देता कि कितना अधिक संगत .NET कोर बन गया। ASP.NET कोर से .NET फ्रेमवर्क को स्थानांतरित करने के लिए दो सक्षम कारक हैं:
1) .NET फ्रेमवर्क की आवश्यकता को कम करना, विरासत डिपों को उपलब्ध कराना और इंटरोप को सुधारना इत्यादि
2) .NET कोर, सुविधाओं और प्रदर्शन के लाभों को बढ़ाना और रखरखाव के बोझ को कम करना

फैक्टर 2 उन लोगों के दिमाग में बहुत बड़ा है जो वास्तव में ASP.NET का निर्माण करते हैं! हालांकि, उपयोगकर्ता के दृष्टिकोण से थोड़ा उल्टा है। लोगों को एक बात यह है कि काम करता है और उनके सर्वोच्च प्राथमिकता है कि यह काम कर रखना चाहिए है। अच्छी खबर यह है कि ज्यादातर मामलों में, यह होगा।

मैं @gulbanana से सहमत हूं। .NET कोर अब .NET फ्रेमवर्क के साथ बहुत अधिक संगत है। वास्तव में, मैं बहुत बड़ा .NET फ्रेमवर्क ऐप लॉन्च करने में सक्षम था। केवल। Dll का नाम बदलकर। कुछ गुम हो गए। .DLL को प्रोबिंग पथ पर जोड़ें।

dotnet कमांड लाइन टूल पर प्रगति प्रभावशाली है। विशेष रूप से .NET कोर वैश्विक उपकरणों के अलावा। वे विकास को एक हवा देते हैं।

crossgen साथ एओटी संकलन महान है। हम लगातार चलते रह सकते हैं।

tl / dr .NET कोर आजकल गंभीर रूप से प्रभावशाली है।

क्या चीज़ छूट रही है:

• वर्तमान ग्राहक संचार रणनीति में कमी है। ग्राहकों को बड़ी निराशा होती है जब वे सुनते हैं कि उनका पसंदीदा .NET प्लेटफ़ॉर्म Microsoft द्वारा खंडित किया जा रहा है। आपको यहां अधिक स्पष्ट होना चाहिए। उदाहरण के लिए, यह लोगों के लिए एकवचन, अत्यधिक-संगत, तेज और भविष्य-प्रूफ .NET कार्यान्वयन को सीधे विज्ञापित करने के लिए एक बेहतर दृष्टिकोण होगा। .NET कोर की तरह, .NET का भविष्य, आपकी अधिकांश समस्याओं को हल करने के लिए, स्काई-रॉकेट उत्पादकता, रचनात्मकता, नए बाज़ार के खुलने के अवसर आदि।
• बॉक्स के बाहर भी अधिक संगतता रणनीतियों
• ग्राफिकल यूज़र इंटरफ़ेस। मेरा मतलब है कि dotnet कमांड लाइन टूल महान हैं, लेकिन वर्तमान में हमें .NET एसडीके प्रारूप में लगभग हर प्रोजेक्ट पर काम करने के लिए अतिरिक्त टेक्स्ट एडिटर्स और कंसोल का उपयोग करना होगा। विज़ुअल स्टूडियो यूआई में इस संबंध में कमी है। यह कई लोगों के लिए बड़ी बाधाएं डालता है, जिन्हें सिर्फ पॉइंट-एंड-क्लिक करने की आदत है। इसमें भी सुधार किया जाना चाहिए
• एलटीएस समर्थन करते हैं

@TsengSR अपने विस्तृत प्रतिक्रिया दोस्त, महान जानकारी के लिए धन्यवाद! बारकोड पैकेज का उपयोग करते समय काम नहीं करेगा क्योंकि परियोजना विभिन्न लक्ष्यों के बारे में शिकायत करने के लिए संकलित नहीं करेगी। हो सकता है कि मैं एक और कोशिश करूं। (जब तक आप अपने आप को फिर से समझना और इसे विरासत में देना चाहते हैं)

प्रयास के बारे में चिंतित नहीं है अगर यह उचित है। मेरी मुख्य चिंता ईएफ और मुख्य अवरोधक होने के साथ कोई विकल्प नहीं होने के कारण उच्च और शुष्क हो रही थी और ऐसा प्रतीत होता है कि ऐसा नहीं होने जा रहा है। यह देखने के लिए अच्छा है कि यह अच्छी तरह से सोचा गया था। हालांकि मैं @gulbanana से सहमत

यहां बहुत सारे विवादित मुद्दे हैं। मेरा व्यक्तिगत 2 सेंट है कि .NET फ्रेमवर्क को पीछे छोड़ना इतना बड़ा सौदा नहीं है। हालाँकि, किस चीज़ से संबंधित है, मानकीकरण प्रयासों (.NET मानक) के लिए किसी भी स्पष्ट समर्थन की कुल कमी है। यकीन है, आप शायद ASP.NET Core को चलाना नहीं चाहते, एकता को आज कहते हैं, लेकिन यह आज के बारे में नहीं है। यह सड़क से लगभग एक या दो साल नीचे है, जब एक और .NET रनटाइम इधर-उधर हो सकता है, तो मैं कहना चाहूंगा कि "हाँ, जैसे ही SuperNetRuntime .NET मानक 2.2 का समर्थन करता है हम उस पर ASP.NET Core 3 चला सकते हैं" ...

क्या ASP.NET Core 3 के लिए .NET Core 3 में आवश्यक सभी परिवर्तनों को कम से कम "इकट्ठा" करने का कोई मौका है और उन्हें .NET मानक कार्य समूह को सुझाव के रूप में अग्रेषित करें?

नमस्ते, .netStandard 2.0 या .netCore 2.0 के लिए प्रकाशित पैकेज .NetCore 3.0 के साथ काम करना जारी रखेंगे। उदाहरण के लिए: Oracle.ManagedDataAccess.Core लक्ष्य .NetCore 2.0

यदि पिछड़ी संगतता है, तो .NetCore 3.0 पर जाना उपयुक्त है, लेकिन यदि पुराने संस्करणों के लिए कोई समर्थन नहीं है, तो यह वास्तव में बेकार है जब तक कि सभी प्ले पकड़ न जाएं।

। नेटफ़्रेमवर्क में संगतता का इतिहास है, यहां तक ​​कि आप नवीनतम संस्करणों में। नेटफ़्रेमवर्क 2.0 का भी उपयोग कर सकते हैं, इसलिए कुछ के लिए बनाए रखने की आवश्यकता है। नेटफोर 2.0 से 3.0 तक भी कम से कम।

धन्यवाद

नमस्ते, .netStandard 2.0 या .netCore 2.0 के लिए प्रकाशित पैकेज .NetCore 3.0 के साथ काम करना जारी रखेंगे। उदाहरण के लिए: Oracle.ManagedDataAccess.Core लक्ष्य .NetCore 2.0

हाँ, .NET Core 3.0 बैकवर्ड कंप्रेशर्स को बनाए रखता है ताकि .NetStandard 1.0 -> .NetStandard 2.1 और .NetCore 1.0 -> .NetCore 2.2 लाइब्रेरी का उपयोग कर सकें।

@benaadams तो अच्छा है। इसके अलावा .net फ्रेमवर्क dll काम करेगा अगर वे किसी भी लापता एपीआई का उपयोग नहीं करते हैं?

धन्यवाद

इसके अलावा .net फ्रेमवर्क dll काम करेगा अगर वे किसी भी लापता एपीआई का उपयोग नहीं करते हैं?

हाँ, हालाँकि इसका एक .NET मानक पुस्तकालय का उपयोग करने के लिए सुरक्षित है जैसा कि आप जानते हैं कि .NET कोर (और मोनो, ज़मरीन, एकता, UWP) पर काम करेगा

इसके अतिरिक्त, Windows संगतता पैक का उपयोग .NET .NET 2.0 के शीर्ष पर .NET फ्रेमवर्क के करीब लाने के लिए (जो आप .NET कोर 2.1 के साथ कर सकते हैं) के लिए एक और 20,000 एपीआई जोड़ता है; और .NET कोर 3.0 EF6 (क्रॉस-प्लेट) के साथ सबसे अधिक संगत है, और विंडोज पर: WinForms, WPF, COM इंटरॉप आदि।

हैलो यारो,
.NET .NET पर ASP.NET Core को एप्लिकेशन माइग्रेट करने के लिए ग्राहकों को उनके पथ पर एक उचित कदम पत्थर देने के लिए, हम वर्तमान समर्थन से मेल खाने के लिए .NET Framework पर ASP.NET Core 2.1.x के लिए समर्थन और सर्विसिंग का विस्तार करने जा रहे हैं। अन्य पैकेज-आधारित ASP.NET फ्रेमवर्क के लिए नीति, जैसे MVC 5.x, वेब API 2.x, सिग्नलआर 2.x। इसका प्रभावी रूप से मतलब है कि ASP.NET Core 2.1.x संबंधित पैकेज (अंतिम विस्तृत सूची TBD) को .NET .NET 2.1 ट्रेन के लिए 3 साल की LTS अवधि से परे अनिश्चित काल के लिए समर्थित किया जाएगा।

उत्कृष्ट खबर। अपने ग्राहकों को सुनने के लिए धन्यवाद।

अपने पुराने MVC ऐप को पोर्ट करने के लिए हमें बहुत लंबा समय लगने वाला है क्योंकि CTP3 के बाद से हम MVC पर हैं और अभी इस्तेमाल किए गए हर एक्सटेंशन पॉइंट के बारे में जानते हैं। यह हमारी चिंताओं को शामिल करता है।

@DamianEdwards यह बहुत अच्छी खबर है! हालाँकि, सोच रहा था कि क्या यह 2.1.x पर नियत है या क्या यह 2.2.x में अपडेट किया जाएगा, अगर यह एलटीएस रिलीज़ बन जाता है? 2.2 में जाने का बहुत प्रयास किया गया है और यह अभी तक जारी नहीं किया गया है। और जब से यह netstandard अनुकूलता के साथ जारी है और पूर्ण ढांचे पर ठीक चलता है, तो विस्तारित समर्थन के लिए इसे पूरी तरह से छोड़ना बेकार की तरह होगा।

@ जब तक मैं आपकी चिंता को समझता हूं, हमें कहीं न कहीं एक रेखा खींचनी होगी, और इस मामले में हमें लगता है कि संस्करण को एलटीएस के साथ संरेखित करना बेहतर है जो इसे आगे बढ़ाता है। एलटीएस या करंट ट्रेन के बीच चयन करने पर ग्राहकों को यह तय करना चाहिए कि वे खुद ही व्यापार करें। नए फीचर्स LTS में नहीं आते क्योंकि वे स्थिरता के बारे में हैं। प्रतिक्रिया लंबे समय तक समर्थन के लिए थी और हमारे पास इसके लिए एक ट्रेन है, इसलिए यह ट्रेन का एक विस्तार है। 2.2 एलटीएस नहीं बनेगा।

@DamianEdwards हाँ, मैं समझता हूँ कि, आपके उत्तर के लिए धन्यवाद। मैं सिर्फ इसलिए पूछ रहा था क्योंकि इस पर अंतिम टिप्पणी यह तय नहीं की गई थी , इसलिए मैं सिर्फ यह जानना चाहता था कि क्या यह विस्तारित समर्थन आगे ले जाएगा यदि 2.2 एलटीएस बन गया।

और मुझे लगता है कि इसे उजागर करना काफी महत्वपूर्ण है ताकि लोग अपने फ्रेमवर्क ऐप को 2.2 में अपग्रेड न करें यदि उन्हें इस विस्तारित समर्थन पर भरोसा करना पड़े। अन्यथा उन्हें फिर से नीचे गिरना होगा।

नए फीचर्स LTS में नहीं आते क्योंकि वे स्थिरता के बारे में हैं।

हालांकि यह वास्तव में पिछले एलटीएस निर्णयों से मेल नहीं खाता है।

@poke

हालांकि यह वास्तव में पिछले एलटीएस निर्णयों से मेल नहीं खाता है।

इसने मुझे भ्रमित कर दिया। किस तरह से? क्या आप इस तथ्य का उल्लेख कर रहे हैं कि 1.1 को 1.x एलटीएस ट्रेन में जोड़ा गया था? यदि हां, तो यह हमारी पहली रिलीज ट्रेन का एक विसंगति है जिसे दोहराया नहीं जाएगा। आगे बढ़ते हुए, हमारा इरादा अधिक सुसंगत होना है, जिसके साथ रिलीज़ एलटीएस बनाम करंट बन जाते हैं (यानी मुझे स्थिरता बनाम सुविधाएँ कहाँ मिलती हैं)।

@DamianEdwards मैं ज्यादातर इस तथ्य का उल्लेख कर रहा था कि अब तक हर रिलीज़ एक बड़ी सुविधा रिलीज़ हुई है, और प्रत्येक एलटीएस निर्णय आमतौर पर पूर्वव्यापी (कम से कम सार्वजनिक रूप से) में किया गया था।

@ ठीक है। खैर, अब तक हम 4 रिलीज (1.0, 1.1, 2.0, 2.1) के साथ 5 वें शीघ्र ही (2.2) आ रहे हैं। उनमें से, केवल 1.0 और 2.0 को शुरू में एलटीएस होने का इरादा था, लेकिन कई कारकों के कारण (ज्यादातर हमें इस तरह से इंजीनियरिंग करने में वास्तव में नया होने से संबंधित था), हम 1.0, 1.1 और 2.1 एलटीएस ट्रेनों के साथ समाप्त हो गए। 2.0 और 2.2 वर्तमान रिलीज़ हैं (थे, हैं)। इस स्तर पर, 3.0 लगभग 3. निश्चित रूप से वर्तमान भी होगा (3.1 के कारण वर्तमान "अनुग्रह" 3 महीने की अवधि में प्रवेश करने के लिए) 3.1 से पहले 3.x ट्रेन एलटीएस हो जाता है। हमारी आशा है कि उसके बाद, पैटर्न और ताल अधिक सुसंगत होंगे (हम इसे पसंद करेंगे) लेकिन अभी तक हमारी क्रिस्टल बॉल हमें विफल रही है।

@DamianEdwards अंतर्दृष्टि के लिए धन्यवाद! । (Btw। मैं इस बारे में बहस करने की कोशिश नहीं कर रहा था, मैं बस उत्सुक था;))

हमारे लिए एक बड़ा मुद्दा नए REST API की विरासत प्रक्रिया द्वारा होस्ट की जाने वाली प्रक्रिया है जो जल्द ही .NET फ्रेमवर्क से हटने की संभावना नहीं है। कम से कम हम .NET मानक 2 के समर्थन पुस्तकालयों और ASP.NET कोर 2.1 से आगे बढ़ने के लिए नहीं जानते हैं! यह अच्छा है कि एलटीएस की अवधि बढ़ाई जाएगी

हे सब, एक त्वरित सवाल: हममें से उन लोगों के बारे में जो C ++ / CLI के रूप में देशी पैकेज का उपभोग करते हैं? क्या यह जल्द ही। नेट कोर में समर्थित होने जा रहा है, या जब तक हम पी / इनवोक का उपयोग करने के लिए बड़े पैमाने पर काम नहीं करते हैं, हम अनाथ हो जाते हैं?

@lokitoth - यह https://github.com/dotnet/core लोगों के लिए एक अच्छा सवाल होगा क्योंकि यह सिर्फ ASP.NET Core से ज्यादा सामान्य है।

@lokitoth हाँ, जिसका समर्थन किया जाएगा, https://github.com/dotnet/coreclr/issues/18013 देखें

o मुझे यह कैसे याद आया?

ठीक है, फिर मुझे इससे कोई समस्या नहीं है।

@ danroth27 क्या आप हमें क्लाइंट-साइड-ब्लेज़र के लिए इस मुद्दे का प्रभाव बता सकते हैं?

@Slkebe मुझे किसी भी प्रभाव की उम्मीद नहीं है। क्लाइंट-साइड ब्लेज़र एप्लिकेशन सर्वर पर चलाने के लिए आपके द्वारा तय किए गए रनटाइम या प्लेटफ़ॉर्म से स्वतंत्र हैं।

@ danroth27 मेरी समझ में, क्लाइंट-साइड ब्लेज़र मोनो पर चल सकता है क्योंकि निर्भर Microsoft.AspNetCore.* पैकेज netstandard को लक्षित करते हैं।
क्या मैं कुछ भूल रहा हूँ? ब्लेज़र को Microsoft.AspNetCore.* 2.1.X का लक्ष्य रखना है?

@Slkebe क्लाइंट-साइड ब्लेज़र लाइब्रेरी केवल उन घटकों पर निर्भर करती है जो .NET मानक (जैसे Microsoft.Extensions। * और दोस्तों) को लक्षित करना जारी रखेंगे। Blazor का सर्वर-साइड भाग जो ASP.NET कोर पर निर्भर करता है, इस मुद्दे में वर्णित .NET कोर को लक्षित करेगा।

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

अब फैसला क्या है? लक्ष्य .net मानक 2.1 पर?

@ John0King कोई नया निर्णय नहीं है।

यह है केला! केले

मुझे आपकी बात पर सहानुभूति है।

माफी अगर यह पहले ही लाया जा चुका है, लेकिन उन मामलों के बारे में क्या है, जहां मैं सिर्फ एक ASP.NET अनुप्रयोग के हिस्से के रूप में Kestrel + कुछ मिडलवेयर का उपयोग करना चाहता हूं? क्या मुझे पूरे 3.0 पेड़ में खींचना होगा (जो आदर्श नहीं है, क्योंकि मेरे उपयोग के मामले में उपभोक्ताओं के लिए एक कस्टम एसडीके को परिभाषित करना शामिल है), या क्या यह उपयोग मामला 3.x पर समर्थित नहीं है?

वर्तमान में मैं एक ASP.NET कोर अनुप्रयोग विकसित कर रहा हूँ। .NET फ्रेमवर्क पर चल रहा है, क्योंकि इसमें शामिल पुस्तकालय हैं। मैं ASP.NET कोर का उपयोग कर रहा हूँ क्योंकि यह बहु-क्षमता है - क्षमताएं। मैं मुर्ख और मुर्दा बंद महसूस कर रहा हूँ।

मैं ASP.NET कोर का उपयोग कर रहा हूँ क्योंकि यह बहु-क्षमता है - क्षमताएं।

@FlorianGrimm क्या विशेष रूप से? Microsoft.Owin ASP.NET 4 के लिए इसी तरह की कार्यक्षमता प्रदान करता है।

यह ऑन-प्रिमाइसेस और azure पर चलने वाला हाइब्रिड ऐप वन सोर्स कोड (.exe) है, जो वर्तमान में विंडोज़ ऑर्ट, एड, बेसिक नॉर्म्स और अनाम का उपयोग कर रहा है।

@FlorianGrimm कौन सी लाइब्रेरी निर्भरताएँ आपको .NET कोर का उपयोग करने से रोकती हैं?

Microsoft.Office.Project.Schema, Microsoft.SqlServer.TransactSql.ScriptDom और Microsoft.SharePointOnline.CSOM।

मुझे उम्मीद है कि SharePoint टीम समाप्त हो जाएगी
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
और मुझे ilspy के अलावा अन्य विकल्प मिलेंगे।

किसी भी तरह से मुझे ASP.NET कोर पसंद है और मुझे आशा है कि अन्य Microsoft टीम अधिक .NET कोर असेंबलियाँ प्रदान करेंगे।

हम समय-समय पर 'चर्चा' मुद्दों को बंद करते हैं जो लंबे समय में अपडेट नहीं किए गए हैं।

अगर इससे कोई असुविधा होती है तो हम क्षमा चाहते हैं। हम पूछते हैं कि यदि आप अभी भी किसी समस्या का सामना कर रहे हैं, तो कृपया अद्यतन जानकारी के साथ एक नया मुद्दा दर्ज करें और हम जांच करेंगे।