Runtime: इनहेरिटेंस सुरक्षा नियमों का उल्लंघन किया गया प्रकार: 'System.Net.Http.WebRequestHandler'। व्युत्पन्न प्रकारों को या तो आधार प्रकार की सुरक्षा पहुंच से मेल खाना चाहिए या कम सुलभ होना चाहिए।

मैं इसे आज एक अन्य रिपोर्ट से देखने के लिए हुआ। / cc @ChadNedzlek

ऐसा लगता है कि यह आउटबॉक्स के System.Net.Http.dll पर इनबॉक्स System.Net.Http.dll की तुलना में अनुपलब्ध सुरक्षा विशेषताओं के कारण हो सकता है। इनबॉक्स संस्करण में AllowPartiallyTrustedCallers है। तो इनबॉक्स System.Net.Http.WebRequest.dll करता है। इसका मतलब है कि सब कुछ SecurityTransparent के रूप में व्यवहार किया जाता है जब तक कि अन्यथा एनोटेट नहीं किया जाता है।

OOB System.Net.Http.dll में AllowPartiallyTrustedCallers गायब है, जो सब कुछ सुरक्षा-महत्वपूर्ण बनाता है। अब जब इनबॉक्स WebRequest.dll OOB System.Net.Http.dll को लोड करता है, तो यह सुरक्षा नियम का उल्लंघन करता है, क्योंकि WebReqeuestHandler पारदर्शी है, लेकिन HttpClientHandler जो इसे प्राप्त करता है, महत्वपूर्ण है।

मेरा तिरस्कार:

1. फ़ाइल> नया डेस्कटॉप अनुप्रयोग
2. प्रोजेक्ट गुण> हस्ताक्षर> strongname हस्ताक्षर सक्षम करें
3. System.Net.Http.WebRequest का संदर्भ जोड़ें
4. System.Net.Http 4.1.0 स्थापित करें।
5. मुख्य में, बस नए WebRequestHandler () को कॉल करें;

ericstj सही है, मुझे यहाँ भी यही समस्या है। यह System.Net.Http 4.1.0 पर एक महत्वपूर्ण मुद्दा है जिसे मरम्मत किया जाना चाहिए। मैं .net4.6.1 के साथ इस लाइब्रेरी का उपयोग नहीं कर सकता क्योंकि इसमें स्थिरता का अभाव है।

इस समस्या से निपटने के लिए एक महत्वपूर्ण दर्द है, और विशेष रूप से मेरी टीम के लिए एज़्योर कीवॉल्ट क्लाइंट का उपयोग करना मुश्किल है। केवल दर्द रहित विकल्प .NET 4.5.2 को डाउनग्रेड करना है, जो स्वीकार्य नहीं है।

इसके अलावा, पहले सूचीबद्ध वर्कअराउंड अपर्याप्त है। यदि आप NET 4.6.x का उपयोग करना चाहते हैं, तो हमने जो पाया है, उसके लिए आपको निम्न कार्य करना होगा: मज़बूती से काम करने के लिए, निर्भरता जाँच को अक्षम करें, System.Net पर जाएँ। CSPROJ को संपादित करें और स्वत: बाइंडिंग पुनर्निर्देशन को अक्षम करें, संशोधित करें app.config, और आम तौर पर स्वच्छ / बाहर निकलें वी.एस. / और फिर से बनाएँ जैसा कि मैंने अक्सर देखा है। System.Net.Http उपयोग में है, यहाँ तक कि तुच्छ परियोजनाओं के लिए भी। यहां वह प्रक्रिया है जो मज़बूती से इसे ठीक करती है।

1. Visual Studio में प्रोजेक्ट पर राइट क्लिक करें और मैनेज करें NuGet Package।
2. स्थापित टैब को गोटो करें।
3. नीचे स्क्रॉल करें। System.Net.Http - Microsoft.Net.Http नहीं।
4. राइट हैंड पेन में, यदि Installed 4.0.0.0 नहीं है, तो Version को 4.0.0.0 पर सेट करें।
5. दाएँ हाथ के फलक में, निर्भरता को अनदेखा करने के लिए निर्भरता व्यवहार सेट करें। यदि आप ऐसा नहीं करते हैं, तो Microsoft.IdentityModel.Clients.ActiveDirectory पैकेज काफी हद तक डाउनग्रेड हो जाएगा, जो सही नहीं है।
6. अद्यतन पर क्लिक करें - इस बटन को वास्तव में "संस्करण में बदलें" लेबल होना चाहिए।
7. पूर्वावलोकन विंडो में, सत्यापित करें कि केवल सूचीबद्ध परिवर्तन "Installing System.Net.Http" है। यदि आप निर्भरता व्यवहार को सही तरीके से सेट करना भूल गए हैं, तो अतिरिक्त परिवर्तन यहां सूचीबद्ध किया जाएगा।
8. पुष्टि संवादों पर ओके / यस / आई सहमत पर क्लिक करें और प्रोसेसिंग पूरी होने तक प्रतीक्षा करें। जब पूरा हो जाता है, तो पैकेज लिस्टिंग में दो संस्करण संख्याएँ दिखाई देंगी - चेक मार्क एक के बगल में है जो उपयोग में है।
9. NuGet इंस्टॉल किए गए टैब पर, Microsoft.IdentityModel.Clients.ActiveDirectory के लिए लिस्टिंग का चयन करें।
10. दाएँ हाथ के विवरण फलक में, "उपेक्षा" करने के लिए निर्भरता व्यवहार सेट करें। यदि आप ऐसा नहीं करते हैं, तो इस पैकेज के चलने के लिए NuGet की मान्यता के बाद कोई भी NuGet जोड़ विफल हो जाएगा।
11. Visual Studio में, फ़ाइल का चयन करें। सभी को सहेजें।
12. पाठ संपादक में इस प्रोजेक्ट के लिए CSPROJ फ़ाइल खोलें।
13. इन / प्रोजेक्ट / प्रॉपर्टीग्रुप * 1 (प्रोजेक्ट का पहला प्रॉपर्टीग्रुप तत्व), निम्नलिखित लाइन जोड़ें, या इस तत्व का मान बदलें यदि यह पहले से मौजूद है:
    <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
14. फ़ाइल को सहेजें, फिर प्रोजेक्ट को Visual Studio में पुनः लोड करें।
15. इस परियोजना के लिए app.config फ़ाइल खोलें।
16. System.Net.Http के लिए लाइन ढूंढें और इसे 4.1.0.0 के बजाय 4.0.0.0 पर पुनर्निर्देशित करें। तो यह खोजें:

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

और इसे इसमें बदलें:

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

1. परियोजना का पुनर्निर्माण करें। यदि आपको Azure Key Vault कोड चलाते समय अपवाद मिलता है, तो बिन / डिबग या इसी तरह की निर्देशिका में एक या अधिक * .config फाइलें अपडेट नहीं की गई हैं। आपको उन्हें साफ़ करने और पुनर्निर्माण के लिए Visual Studio से बाहर निकलना पड़ सकता है।

dluxfordhpf, आपके समय की व्याख्या करने के लिए धन्यवाद कि आपने इसे कैसे काम किया है। System.Net.Http 4.0 पर पुनर्निर्देशित करना मेरे लिए .net4.6.1 में काम करता है, लेकिन अभी भी इसे बनाए रखने के लिए बहुत कठिन है (नगेट निर्भरता)। आगे उस संस्करण को देखें जो इसे ठीक करेगा।

यदि लोग System.Net.Http 4.1.0 में जोड़े गए किसी भी नए API का उपयोग कर रहे हैं, तो पुनर्निर्देशन समस्या पैदा कर सकता है।

विशेष रूप से मेरी टीम के लिए एज़्योर की-वॉल्ट क्लाइंट का उपयोग करना दर्दनाक बनाता है

@ChadNedzlek के पास एक ही समस्या थी और एक HttpClient में पास करके वह इसे हल करने में सक्षम था, उसने खुद को KeyVaultClient कंस्ट्रक्टर के लिए बनाया। यदि आप WebRequestHandler का उपयोग नहीं करते हैं तो आप समस्या से बचेंगे।

ईजी:

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

@davidsh मुझे लगता है कि आपको System.Net.Http.dll पर AllowPartiallyTrustedCallers वापस डालना होगा। / cc @ मॉर्गनब्रिज

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

@terrajobst यह एक ब्लॉकिंग उत्पादन समस्या है। किसी भी विचार जब हम NuGet पर एक तय कर सकते हैं? धन्यवाद!

बस खुद इस में भाग गया। अगर हम .Net में निर्भरता नरक में नहीं उतरते तो बहुत बढ़िया होगा। यह इस तरह बढ़ रहा है।

संपादित करें: सिस्टम httpclient का उपयोग करने के लिए एक पूर्व टिप्पणी सुझाव के साथ फिक्स्ड ??
new KeyVaultClient(GetAccessToken, new HttpClient(new HttpClientHandler()))
ऐसा लग रहा था कि इसे पाने के लिए ...

समस्या केवल बदतर होती जा रही है क्योंकि Microsoft के अधिक से अधिक नगेट पैकेज System.Net.Http के नवीनतम संस्करण पर निर्भरता लेते हैं। मैं शायद अकेला नहीं हूं जो अपने Microsoft नगेट पैकेजों को नवीनतम पूर्व-रिलीज़ संस्करण में लगातार अपग्रेड करता रहता हूं। उदाहरण के लिए पैकेज जो अब मेरे नवीनतम संस्करण में मेरे लिए काम नहीं करते हैं:

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

मुझे अभी भी समझ नहीं आया कि यह पैकेज अभी भी क्यों उपलब्ध है। @terrajobst @coolcsh क्या हम इस पैकेज को नीचे ले / तय कर सकते हैं? यह वास्तव में जटिल अनुप्रयोग वातावरण के साथ समस्या पैदा कर रहा है। कई घंटे बर्बाद करने की कोशिश कर रहा है निर्माण में रेंगने से अपमानजनक पैकेज। धन्यवाद!

हम NuGet की इस टूटी हुई चीज के बजाय NET फ्रेमवर्क में System.Net.Http से बाइंडिंग को देख रहे हैं। मैं मानता हूं, यह समस्या हास्यास्पद है, और इससे निपटने के लिए बहुत महंगा है क्योंकि आपको प्रोजेक्ट्स के बीच NuGet संस्करणों को सिंक्रनाइज़ करना होगा, ऑटो बाइंडिंग अपडेट्स को रोकना होगा और अपने ऐप को ठीक करना होगा / चेक करना होगा। मुझे आश्चर्य है कि यह इस तरह के एक व्यापक रूप से इस्तेमाल विधानसभा में है। शायद MS वास्तव में KeyVault के बारे में ज्यादा परवाह नहीं करता है?

इसका उपयोग ActiveDirectory Nugget द्वारा भी किया जाता है

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

दाखिल करने के लिए धन्यवाद। हम सक्रिय रूप से इस पर गौर कर रहे हैं। बने रहें।

यह मेरे लिए एक महत्वपूर्ण मुद्दा बन गया है; हम आंतरिक रूप से अपने स्वयं के नगेट पैकेजों का बहुत उपयोग करते हैं। और यह सिर्फ _will not_ को लगता है कि उन bindingRedirect s को अकेले छोड़ दें। हर बार जब हम अपने किसी आंतरिक पैकेज को अपडेट करते हैं, तो यह पुनर्निर्देशन को वापस newVersion="4.1.0.0" । क्या ऐसा करने से रोकने का कोई तरीका है, या क्षितिज पर एक तय है?

एचटीटीपीएस पर एप्लिकेशन चलाने पर एनकाउंटर किया गया, जो HTTP पर ठीक काम करता था। यकीन नहीं होता अगर कोई अन्य महत्वपूर्ण अंतर।
newversion="4.0.0.0" सेट करने का समाधान मेरे लिए काम किया।

अभी भी NETStandard 1.6.1 में एक मुद्दा। क्यों?!

System.Net.Http 4.3.0 बाहर है। किसी ने कोशिश की?

@ लोल जी हां, अभी भी एक समस्या है मुझे डर लग रहा है।

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

@ यहाँ

System.TypeLoadException: Inheritance सुरक्षा नियमों का उल्लंघन इस प्रकार से किया जाता है: 'System.Net.Http.WebRequestHandler'। व्युत्पन्न प्रकारों को या तो आधार प्रकार की सुरक्षा पहुंच से मेल खाना चाहिए या कम सुलभ होना चाहिए।

सबसे पहले, मुझे लगता है कि यह IdentityServer / IdentityServer3.AccessTokenValidation के कारण था, लेकिन इस मुद्दे को पढ़ने के साथ मुझे मेरी स्थिति t_t समझ में आई, मैंने इसे हल करने के लिए कई घंटे बिताए

संपादित करें:
हे भगवान,
Newversion सेट करने का समाधान = "4.0.0.0" ने मेरे लिए भी काम किया

मैं 4.3 के लिए अद्यतन करने की कोशिश, लेकिन, एक ही मुद्दा: ((

उन्नयन के बाद यहाँ एक ही मुद्दा

मुद्दा अभी भी 4.3.0 के साथ मौजूद है।

@terrajobst क्या आप इस समस्या पर कोई अपडेट प्रदान कर सकते हैं या आगे की समस्या के बारे में अधिक जानकारी @robertmclaws द्वारा संदर्भित है?

किसी भी कारण से यह फिक्स स्थानीय रूप से काम करता है, लेकिन जब एज़ुर क्लाउड सर्विस में तैनात किया जाता है, तो त्रुटि बनी रहती है?

कभी-कभी पैकेजिंग Azure आपके बाध्यकारी पुनर्निर्देशन को खराब कर सकता है, cspkg को अनज़िप करने की कोशिश करें और देखें कि वास्तव में क्या तैनात किया जा रहा है।

यहाँ System.Net.Http.dll का संस्करण है

मैं इस पर कुछ दिनों से काम कर रहा हूं। इस सुधार को पाने के लिए और अज़ूर को तैनात करते समय आँसू में सुपर खुश था।

परियोजना के लिए बाध्यकारी पुनर्निर्देशन वाली .config फ़ाइल के बारे में क्या? मैं वास्तव में यह उम्मीद करता हूं कि अभी भी असेंबली के टूटे हुए संस्करण को डुप्लिकेट पैकेज से सही होने के कारण असेंबली के टूटे हुए संस्करण को परिनियोजित किया जा सकता है, लेकिन बाइंडिंग रीडायरेक्ट को यह सुनिश्चित करना चाहिए कि असेंबली के फ्रेमवर्क संस्करण को क्लाउड सेवा VM के अंदर लोड किया गया है।

यह है!!! WTH?

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

मेरी परियोजना में वापस देखते हुए, web.config भी वापस आ गया है। मुझे इसे सुबह फिर से उठाना होगा। कुछ लीड के लिए धन्यवाद!

मुझे लगता है कि यदि आप AutoGenerateBindingRedirects का उपयोग करते हैं और फिर परियोजना के लिए किसी भी नगेट पैकेज को संशोधित करते हैं, तो यह आपके पूर्व-संशोधित किए गए पुनर्निर्देश को वापस टूटे हुए संस्करण में "ठीक" कर देगा। अधिक निराश।

लेकिन समस्या का एक हिस्सा है, अगर आप नए पैकेज जोड़ते समय AutoGenerateBindingRedirects का उपयोग नहीं करते हैं, तो आप अन्य मुद्दों में भी भाग सकते हैं।

मैं अपने ऐप के नए संस्करण को तैनात करने के दौरान एक सप्ताह से अधिक समय से इस बकवास से निपट रहा हूं। सबसे अच्छा मैं सुझाव दे सकता हूं कि आप अपने वेब.कॉन्फ़िग की जाँच करने की आदत को हर बार तैनात करें।

हाँ, आपको CSPROJ में हैंड एडिट के माध्यम से बाइंडिंग अपडेट को अक्षम करना होगा, और उसके बाद .config बाइंडिंग रीडायरेक्ट को ठीक करना होगा, और GUI में NuGet को पुन: कॉन्फ़िगर करना होगा न कि निर्भरता को अपडेट करने के लिए, और जब आप ठीक हों। हां, यह एक प्रमुख PITA है, मुझे आश्चर्य है कि यह इतने लंबे समय से उत्पादन में है। मेरी टीम अब नियमित रूप से महीनों से इसे कोस रही है।

दुर्भाग्य से उपरोक्त अभी भी केवल मेरे देव वातावरण को ठीक करता है और नीला रंग नहीं। मैंने नवीनतम पब फ़ाइल की जाँच की और web.config को मेरे dll के साथ ठीक से सेट किया गया था जो कि ऊपर चित्रित संस्करण के रूप में प्रकाशित किया गया है। दुर्भाग्य से, मेरे मुद्दे एज़्योर सर्च लाइब्रेरी से संबंधित हैं, इसलिए यह फिक्स होनहार साबित हो रहा था। कोई अन्य विचार? थोड़ा नुकसान होने पर। सहायता के लिए धन्यवाद।

यह 2 महीने से अधिक पुराना क्यों है? यह बहुत बड़ा मुद्दा है। कृपया ठीक करें।

यह पूरी तरह से एक स्टॉप-शिप मुद्दा है, इसे पूरी तरह से संबोधित करने की आवश्यकता है।

F # $ @ के लोगों के लिए, इसे पहले ही ठीक कर लें। यह मूढ़ता है।

@suprduprmn मैंने सभी पैकेजों को अद्यतन और समेकित किया और फिर इसे सभी app.config और web.config फ़ाइलों में बदल दिया:

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

तभी मेरा वेब ऐप Azure पर लॉन्च होगा और Azure सेवाओं पर https कॉल करने में सक्षम होगा जो System.Net.Http पर निर्भर करता है। YMMV लेकिन शुभकामनाएँ।

और @terrajobst ... क्या एक उचित जगह है जहां मैं औपचारिक रूप से इस तरह के प्रमुख मुद्दों की उपेक्षा के बारे में शिकायत कर सकता हूं? खुले स्रोत के खुशहाल-भाग्यशाली नियम यहां लागू नहीं होते हैं। यह Microsoft Showstopper 101 सामान लगभग 1995 है। कोई तरीका नहीं है "समुदाय" मदद कर सकता है। आप इसे ठीक कर देंगे और आप वास्तु उपकरण और प्रक्रिया को सुनिश्चित करेंगे कि ऐसा होना बंद हो जाए। मैं इस तरह की कई Microsoft परियोजनाओं में सामान देख रहा हूँ और यह पूरी तरह से अस्वीकार्य है। यह स्पष्ट है कि परीक्षण में भारी अंतराल हैं। मूल परिदृश्य केवल रनटाइम पर ठीक से काम नहीं करने देते या स्थापित नहीं करते हैं।

मैं इस मुद्दे पर प्रतिक्रिया देने में लगने वाले XXXL के लिए क्षमा चाहता हूं। अंतिम प्रतिक्रिया के बाद से यह 1 महीने का है और इस मुद्दे को 3+ महीनों के लिए खोला गया है। मैं मानता हूं कि यह इस तरह के उच्च प्रभाव वाले मुद्दे के लिए स्वीकार्य नहीं है।

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

अफसोस की बात है, यह इस बिंदु पर सबसे अच्छा मैं कर सकता हूं (यानी ईमानदारी से माफी और आश्वासन हम हैं और इसे गंभीरता से व्यवहार करेंगे और एएसएपी को ठीक करने के लिए हमारी पूरी कोशिश करेंगे)। यदि किसी के पास वैकल्पिक सुझाव हैं, तो मैं सभी कानों के पास हूं।

@ कर्लेज़ मैं वास्तव में समस्या को ठीक करने से टीम को विचलित नहीं करना चाहता, लेकिन व्यक्तिगत रूप से मैं इस मुद्दे के मूल कारण पर एक पोस्टमार्टम विश्लेषण सुनना पसंद करूंगा और यह क्यूए के माध्यम से कैसे बना। इसने प्रमुख सिरदर्द पैदा कर दिए हैं और मुझे लगता है कि पारदर्शिता कुछ विश्वास अर्जित करेगी।

@ जहमाई अंडरस्टूड , मुझे भी इसमें दिलचस्पी है, लेकिन मैं पहले समाधान पर ध्यान केंद्रित करना चाहता हूं। फिर हम विश्लेषण कर सकते हैं कि भविष्य में इस तरह के हादसों को रोकने के लिए क्या और क्यों हुआ।

जवाब देने के लिए धन्यवाद। मुझे लगता है कि इस समय सबसे अच्छा समाधान किसी भी पैकेज को निष्क्रिय करना है जो System.Net.Http 4.0.0 पर वापस नहीं आता है। पैकेज के कम से कम 2 संस्करण हैं जो खराब हैं। यह पहली जगह में NuGet के माध्यम से इस सामान को वितरित करने की बात नहीं है?

hugs @ एमएस-टीम

इसके अलावा, बस इतना पता है, इस मुद्दे के बीच, HttpClient के आसपास के मुद्दों को इतनी खराब तरीके से डिज़ाइन किया गया है, Microsoft.Security.Owin.Jw के आसपास के मुद्दे वर्तमान निर्भरता के खिलाफ टूट रहे हैं, और .NET कोर की स्थिति ...

यह अभी एक .NET डेवलपर होने के लिए एक अविश्वसनीय रूप से निराशाजनक समय है। अब प्रत्येक एंप्लॉयी को असेंबली बाइंडिंग रेफरेंस को चेक करने के लिए 30 मिनट की आवश्यकता होती है ताकि मेरे ऐप्स प्रोडक्शन में टूट न जाएं। यह वह Microsoft नहीं है जिसे मैंने इतने लंबे समय के लिए तैयार किया है। मुझे आप लोगों से प्यार है, और मैं बिल्कुल भी कठोर नहीं होना चाहता ... लेकिन ऐसा लगता है कि गुणवत्ता की स्थिति को बहाल करने के लिए कुछ कठिन प्रेम की आवश्यकता है।

जो भी करना है। भले ही इसका मतलब है कि एक 4.3.1 शिपिंग है जो पुराने 4.0 पैकेज का संदर्भ देता है। प्लीज, बस जल्दी करो।

धन्यवाद दोस्तों। FWIW, यदि आपको एक ब्रेकिंग परिवर्तन करने की आवश्यकता है, तो कृपया ऐसा करें। हम इसे नापसंद करते हैं, लेकिन हम कई महीनों से दर्द के साथ जी रहे हैं, और अब जब हम जानते हैं कि आप व्यस्त हैं, तो हम कुछ और इंतजार कर सकते हैं, भले ही हमें कुछ एपीआई बदलाव करने पड़े।

कुछ यहाँ रेल से दूर है। मैं 15 साल से C # ऐप्स की शिपिंग कर रहा हूं। विडंबना यह है कि Microsoft द्वारा उच्च स्तर के अमूर्त को भेज दिया जा रहा है, मैं अधिक से अधिक समय ऐसे इंटर्नल में खोद रहा हूं जिसके बारे में मुझे पहले कभी चिंता नहीं हुई थी। आप यह गलत कर रहे है।

मैं यह समझने के लिए पर्याप्त स्मार्ट नहीं हूं कि इस लाइब्रेरी पर विश्वास के झंडे को फिर से दिखाना एक बहुत बड़ी बात क्यों है और न ही मुझे समझ में आता है कि मेरे ऐप पर वैसे भी मेरा अधिक नियंत्रण क्यों नहीं है।

अगर मैं यादृच्छिक पुस्तकालय और पैकेज-प्रबंधन प्रेरित त्रुटियों से आश्चर्यचकित होना चाहता था, जो संकलक ने नहीं पकड़ा, तो मैं रूबी में अपने ऐप लिखूंगा।

शीघ्र नवीनीकरण:
हम इस सप्ताह कई बार मिले हैं। हमने विकल्पों पर विचार किया और धन का पता लगाया।
@CIPop इस मुद्दे पर सर्वोच्च प्राथमिकता के रूप में काम कर रहा है ( @davidsh से संचरित कार्य जो बाकी वर्ष के लिए अगले सप्ताह से शुरू होगा)।

स्थिति:

• हम मूल repro और शिल्प छोटे repro @onovotny को पुन: पेश करने में सक्षम थे।
• हम नीचे दिए गए समाधान [3] का अनुसरण कर रहे हैं - इसके शेष खुले प्रश्न को ध्यान में रखते हुए, अर्थात विकल्प की तकनीकी व्यवहार्यता को मान्य करना।
• हम नीचे दिए गए समानांतर समाधान [2] में स्काउट कर रहे हैं - अपने खुले प्रश्न को स्काउट कर रहे हैं, अर्थात पारिस्थितिकी तंत्र पर समाधान के प्रभाव का आकलन कर रहे हैं।

समस्या का विवरण

• हमने जून में System.Net.Http 4.3.0.0 "OOB" भेज दिया
  
  
  
  • उल्लेखनीय सामग्री (इस संदर्भ के लिए): HttpCient, HttpClientHandler
  
  
  • ग्राहक मूल्य: प्रमाणपत्र का समर्थन, http2 समर्थन, डेस्कटॉप पर WinHttp स्टैक
  
  
  • डेस्कटॉप को छोड़कर सभी प्लेटफ़ॉर्म ठीक काम करते हैं - डेस्कटॉप के लिए API सतह में PartialTrust कोड के लिए SecurityAttributes (APTCA = AllowPartialTrustCodeAttribute) नहीं है
  
  
  • डेस्कटॉप पर, OOB लाइब्रेरी System.Net.Http 4.0.0.0 के उपयोग को ओवरराइड करती है जो प्लेटफ़ॉर्म का हिस्सा है (और APCCA है)
  
  
• System.Net.WebRequestHandler 4.0.0.0 डेस्कटॉप का हिस्सा है
  
  
  
  • यह System.Net.Http पर निर्भर करता है और APTCA है, इसलिए APTCA के लिए System.Net.Http की आवश्यकता है
  
  
  • यह System.Net.Http से आंतरिक प्रकारों का उपयोग करता है (जिसमें InternalsVoubleTo है)
  
  
  • यह "बोरिंग" विरासत प्रकार है जो हम .NET कोर में नहीं चाहते हैं
  
  
• लाइब्रेरी (डेस्कटॉप पर 3+ नुगेट पैकेज और एएसपी.नेट कोर ऐप) हैं जो (अप्रत्यक्ष रूप से) दोनों OOB System.Net.Http 4.3.0.0 और System.Net.WebRequestHandler 4.0.0.0 के संदर्भ में लाएंगे। कॉम्बो एप्लिकेशन को चलाने से रोकता है।

समाधान

1. [योग्य नहीं है] मैन्युअल बाइंडिंग रीडायरेक्ट - मैन्युअल रूप से प्रति एप्लिकेशन डाउनग्रेड (बाइंडिंग रीडायरेक्ट के माध्यम से)
   
   
   
   • नोट: आज "वर्कअराउंड" के रूप में उपयोग किया जाता है
   
   
2. [संपादित करें] ओओबी के
   
   
   
   • डाउनसाइड: हम उन ग्राहकों को तोड़ देंगे जो नई कार्यक्षमता पर निर्भर हैं
   
   
   • खुला प्रश्न: क्या डेस्कटॉप पर WCF या अन्य NuGet पुस्तकालय प्रभावित होंगे?
   
   
3. [CANDIDATE] System.Net.Http में सुरक्षा विशेषताओं का छिड़काव करें
   
   
   
   • इसे केवल डेस्कटॉप के लिए करें (#if का उपयोग करें), इसे अन्य पैकेजों में प्रचारित न करें (डेस्कटॉप संदर्भ के खिलाफ संकलन), भविष्य के लिए इसे लागू करने वाले परीक्षण जोड़ें।
   
   
   • नकारात्मक पक्ष: कुछ WebRequestHandler गुण जो कि System.Net के डेस्कटॉप कार्यान्वयन के लिए विशिष्ट हैं। http काम नहीं करेगा (डिजाइन के अनुसार हम कार्यान्वयन को स्विच करते हैं)
   
   
   • तकनीकी नोट: Async विधियों में SecurityTransparent (Roslyn compiler limitation) होना चाहिए, इसलिए वे (SecurityCritical) PInvokes को कॉल नहीं कर सकते हैं - ऐसे प्रत्येक PInvoke कॉल के लिए एक SecuritySafeCrict आवरण विधि (थोड़े बदसूरत, लेकिन सीधी) होनी चाहिए
   
   
   • खुला प्रश्न: क्या हम नए WinHttp- आधारित System.Net.Hpp के साथ WebRequestHandler के आंतरिक निर्भरता को काम कर सकते हैं?
   
   
4. [प्रकाशित] OOB WebRequestHandler सिर्फ डेस्कटॉप पर
   
   
   
   • नकारात्मक पक्ष: समस्या को ऊपर की ओर धकेलना (कुछ APTCA विधानसभा इस पर निर्भर करती है)
   
   
   • डाउनसाइड: कुछ WebRequestHandler गुण जो System.Net के डेस्कटॉप कार्यान्वयन के लिए विशिष्ट हैं। यह काम नहीं करेगा (डिज़ाइन द्वारा) - देखें [3] ऊपर
   
   
   • नकारात्मक पक्ष: सभी को निर्भरता को जोड़ना होगा, या नवीनतम स्थापित करने के लिए NuGet को बताना होगा
   
   
5. [संक्षिप्त] बंडल System.Net.WebRequestHandler.dll में System.Net.Http NuGet पैकेज
   
   
   
   • 2 डाउनसाइड के समान ही ऊपर [4] में:
     
     
     
     
     
     1. नकारात्मक पक्ष: समस्या को ऊपर की ओर धकेलना (कुछ APTCA विधानसभा इस पर निर्भर करती है)
     
     
     
     2. नकारात्मक पक्ष: कुछ WebRequestHandler गुण जो System.Net के डेस्कटॉप कार्यान्वयन के लिए विशिष्ट हैं। http (काम नहीं करेगा) (डिज़ाइन द्वारा) - देखें [3] ऊपर
     
     
     
   
   

विस्तृत जानकारी के लिए धन्यवाद, हम इसकी सराहना करते हैं।

विकल्प 2 के संयोजन और 5.0 के रूप में 4.3 फिर से शिपिंग के बारे में क्या? चूँकि यह तकनीकी रूप से एक परिवर्तनशील परिवर्तन था, आप तब डेस्कटॉप के लिए V5.0 के रूप में एक OOB WebRequestHandler.dll जहाज कर सकते थे। यह आपको WinHttp में कार्यक्षमता को फिर से लागू करने देगा, ऐसे गुणों को चित्रित करें जो मानचित्र नहीं करते हैं, और हर किसी को उस तरीके से आगे बढ़ाते हैं जिस तरह से SemVer आपको बताने वाला है। अपस्ट्रीम को अभी भी अपने कोड को ठीक करने की आवश्यकता होगी, लेकिन एक बड़ी रिलीज में अप्रत्याशित नहीं है, और वे 5.0 को शामिल नहीं करने के लिए अपने पैकेजों को केवल ऊपरी-बाध्य कर सकते हैं।

मेरा मतलब है, मुझे एक ही संस्करण संख्याओं के साथ पूरे ढांचे के पैकेज समूहों को शिप करने की इच्छा है, लेकिन क) पहले से ही पेंच था जब आप लोगों ने मौजूदा डेस्कटॉप संस्करण का पालन करने के बजाय 4.0 के रूप में सब कुछ भेज दिया, और ख) वास्तविक असेंबली वर्जनिंग पहले से ही सभी जगह पर है (System.Security.Claims 4.3 पैकेज शिप 4.0.2 dll, जो बाइंडिंग रीडायरेक्ट्स बनाने के लिए सुपर-कष्टप्रद है)। तो नुकसान पहले ही हो चुका है।

dotnet / corefx # 3 मेरे लिए एकमात्र वास्तविक मूल-कारण समाधान की तरह दिखता है।

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

मुझे नहीं लगता कि किसी को भी पूरे ढांचे समूहों के संस्करणों के बारे में बहुत परवाह है। ईमानदारी से, अगर मुझे विश्वास था कि यह अधिकांश ग्राहकों की मदद करेगा, तो मैं सिर्फ संख्याओं को बदलने के लिए वोट करूंगा - मुझे विश्वास नहीं है कि यह लगभग सभी में मदद करेगा। यह बस हमारे संदेश को "हाँ, आप टूट गया है - को बदल देगा - यही संस्करण कहता है, आपको बस यह महसूस नहीं हुआ कि संस्करण लेते समय आप किस तरह की चीजों से सहमत हैं", जो IMO लंगड़ा बहाना है।

राय में अंतर को देखते हुए, मेरी दिलचस्पी है कि अन्य क्या सोचते हैं: कृपया इस पोस्ट पर upvotes / downvotes का उपयोग करें:

• With यदि आप मुझसे सहमत हैं, तो आप सोचते हैं कि ब्रेकिंग परिवर्तन को शिपिंग करना होगा क्योंकि 5.0 से कोई फर्क नहीं पड़ेगा और अधिकांश लोग अभी भी टूट जाएंगे, भ्रमित और प्रभावित होंगे।
• 👎 अगर आप

ब्रेकिंग परिवर्तनों के संस्करण के लिए, मुझे लगता है कि 5.0 एक अच्छा विचार है, लेकिन मुझे नहीं लगता कि इसके बारे में दृढ़ता से।

मैं अभी भी इस बात को लेकर बहुत असमंजस में हूँ कि पहले इस समस्या का क्या कारण है
जगह। तुम लोग वास्तव में मेरे सिर पर बात कर रहे हो।

मैं संस्करण संख्याओं के मिलान के बारे में बहुत परवाह करता हूं, लेकिन अगर ऐसा है
इस समस्या को रोकने के लिए जाने के लिए, मैं इसके साथ सौदा करूँगा।

क्या मैंने कुछ महीने पहले एक लेख नहीं पढ़ा था कि अधिकांश कैसे
System.Net.ttp लाइब्रेरी को एक पुनर्निर्माण के पक्ष में सूर्यास्त किया जा रहा था?

15 दिसंबर, 2016 को 3:18 बजे, "कारेल ज़िकमुंड" सूचनाएं @github.com ने लिखा:

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

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

राय में अंतर को देखते हुए, मेरी दिलचस्पी है कि दूसरे क्या सोचते हैं:
कृपया इस पोस्ट पर upvotes / downvotes का उपयोग करें:

• With यदि आप मुझसे सहमत हैं, तो आप सोचते हैं कि ब्रेकिंग परिवर्तन को शिपिंग करना चाहिए
  5.0 से कोई फर्क नहीं पड़ेगा और अधिकांश लोग अभी भी टूट जाएंगे,
  भ्रमित और प्रभावित।
• 👎 अगर आप https://github.com/robertmclaws से सहमत हैं
  प्रस्ताव, यानी आपको लगता है कि ब्रेकिंग परिवर्तन को शिपिंग करने में 5.0 मदद करेगा
  लोग समझते हैं कि उन्हें पैकेज से दूर रहना चाहिए,
  क्योंकि यह एक अन्य पुस्तकालय के साथ कॉम्बो को तोड़ देगा और रोक देगा
  डेवलपर्स के लिए अनावश्यक दर्द।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/11100#issuecomment-267446604 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAavtBRE24SlHsZHCYm5OhPbOGs6MfRzks5rIa68gaJpZM4JsdDX
।

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

@ कर्लज़ मैं सराहना

"अधिकांश लोग (ऐप और लाइब्रेरी के मालिक) जैसे कथन आमतौर पर नवीनतम में अपग्रेड हिट करते हैं" उपयोगी नहीं हैं। यही कारण है कि पर्ल 6, पायथन 3, रेल 3 और 4, और Node.js 1,2,3,4,5 और 6 स्प्लिन्टर चीजों में कामयाब रहे। चलिए उस लीड को फॉलो नहीं करते हैं।

@dluxfordhpf @ciel दुर्भाग्य से, यह समझाने के लिए एक कठिन क्षेत्र है। यह सब "विरासत" कोड एक्सेस सुरक्षा से आ रहा है जो अब सक्रिय रूप से उपयोग के लिए अनुशंसित नहीं है।

यहां इसका एक सारांश है कि इसका उद्देश्य क्या है / था:
https://msdn.microsoft.com/en-us/library/ee191569 (v = vs.110) .aspx
https://msdn.microsoft.com/en-us/library/dd233102 (v = vs.110) .aspx

वास्तविक मुद्दे के रूप में करना है @karelz ने कहा कि एक प्रकार की सुरक्षा पारदर्शिता (डेस्कटॉप ढांचे में होने के एक प्रकार) के साथ एक प्रकार से प्राप्त करने की कोशिश कर रहा है जिसमें कम प्रतिबंधात्मक सुरक्षा रुख है (क्योंकि विशेषताएँ गायब हैं। OOB संस्करण)। ऐसा इसलिए है क्योंकि CAS एक अवधारणा के रूप में डेस्कटॉप .net के अलावा किसी भी चीज़ के भीतर मौजूद नहीं है।

ऊपर दिए गए डॉक्स के संदर्भ में, इनहेरिटेंस रूल्स पर इस अनुभाग को देखें

यह विभिन्न सुरक्षा स्तरों के पार प्रकारों के उत्तराधिकार के लिए आवश्यक नियमों का वर्णन करता है।

धन्यवाद! मैं CAS से परिचित हूँ; तकनीकी अद्भुत हैं।

.NET कोर, .NET मानक, एट के बीच संस्करण संख्या परिवर्तन को देखते हुए। अल। पिछले वर्ष में (और नौगेट पर ४.२.२ पर चलने वाले नए कोड को शिपिंग करते हुए, मैं समझता हूं कि Microsoft उस संस्करण संख्या को नहीं सोच सकता है। लेकिन किसी ऐसे व्यक्ति के रूप में जो अखंडता से एक बहुत ही जटिल एप्लिकेशन आर्किटेक्चर का प्रबंधन करता है, और २० से अधिक OGI NuGet पर शिप करता है। संकुल, मैं तहे दिल से असहमत हूँ।

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

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

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

क्योंकि 'पुराने' QA जो हमें Windows ME और Vista लाए थे, श्रेष्ठ थे।

इसके अलावा, मुझे यकीन है कि उनका अपमान करने से काम जल्दी हो जाएगा।

16 दिसंबर, 2016 7:46 पूर्वाह्न पर, "chadwackerman" सूचनाएं @github.com ने लिखा:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/11100#issuecomment-267597137 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAavtAUL3pmMiSRnFBe7DEa0y5AaZoVXks5rIpZIgaJpZM4JsdDX
।

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

16 दिसंबर, 2016 8:26 पूर्वाह्न, "chadwackerman" सूचनाएं @github.com ने लिखा:

बुलबुल को बुलाने पर विश्वास होता है कि काम तेजी से हुआ या नहीं।
अन्यथा आपको करोड़पति देव प्रबंधक मिल गए हैं जिन्होंने एक पंक्ति नहीं लिखी है
कोड में 10 साल कह रही है "वाह यह गितुब बात यकीन है कि साफ है। चलो हैक
upoote / downvote इमोजी और एक पोल पकड़ें ताकि मुझे कोई फैसला न करना पड़े। "
मानो वह काम के महीनों और छह के बाद कुछ भी हल करने जा रहा हो
आंतरिक रूप से ट्राइएज मीटिंग के घंटे। यह गलत सामाजिक संकेत है और
स्पष्ट रूप से bs इंजीनियरों की तरह बाहर कॉल करने के लिए इस्तेमाल किया कि हमें गुणवत्ता लाया
जैसे शनि V राकेट। और .NET जो सबसे अच्छी भाषा पैकेजिंग थी
और इस सब से पहले इस अंतरिक्ष में कुछ भी के मानक पुस्तकालय ऑनलाइन
मूढ़ता शुरू हो गई।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/11100#issuecomment-267604666 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAavtEigDK5EqlA4LQVlxB_lfamMgHanks5rIp9-gaJpZM4JsdDX
।

या हो सकता है कि आपको वह व्यक्ति मिल गया जिसने Microsoft को अपनी पूरी टीम को अनब्लॉक करने का तरीका सीखा और अंत में एक मुद्दे पर काम किया जिसे महीनों तक अनदेखा किया गया।

Microsoft ने बग सूचियों और प्राथमिकताओं को आंतरिक रूप से पूरी तरह से डुप्लिकेट कर दिया है। गितुब सामाजिक बकवास का एक गुच्छा है। वे वैसे भी इस मुद्दे के लिए एक पुल अनुरोध नहीं लेंगे ताकि यह ग्राहक सहायता थ्रेड में बदल जाए। देवताओं ने यहाँ बुरा काम किया और उनके लिए यह सुनना ठीक है।

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

16 दिसंबर, 2016 8:34 पूर्वाह्न, "chadwackerman" सूचनाएं @github.com ने लिखा:

या हो सकता है कि आपको वह आदमी मिल गया हो जिसने अपनी पूरी टीम को अनब्लॉक करना सीख लिया हो
Microsoft को एक ऐसे मुद्दे पर अंतत: कार्य करना था जिसे महीनों तक अनदेखा किया गया।

Microsoft ने बग सूचियों और प्राथमिकताओं को आंतरिक रूप से पूरी तरह से डुप्लिकेट कर दिया है।
गितुब सामाजिक बकवास का एक गुच्छा है। वे इसके लिए पुल अनुरोध नहीं करेंगे
यह समस्या वैसे भी इसलिए यह ग्राहक सहायता थ्रेड में बदल जाती है। देवता
यहाँ एक बुरा काम किया और उनके लिए यह सुनना ठीक है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/11100#issuecomment-267606461 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAavtHTdxym7pvR9KRomyIT14FVaILLFks5rIqF8gaJpZM4JsdDX
।

मैं केवल इसका जवाब दूंगा क्योंकि Microsoft "GitHub number_of_comments द्वारा" का उपयोग करता है ताकि @karelz में इतनी विनम्रता से "फिगर

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

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

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

मेरी टीम के पास एक निरंतर पकड़ है "हमें इन सभी पैकेजों को क्यों डाउनलोड करना है?" हम एक कंसोल या ASP.NET प्रोजेक्ट बनाते हैं और इसकी ज़रूरत की हर चीज़ बॉक्स पर होती है। आप कुछ और आधुनिक और 5 बिलियन डाउनलोड बनाते हैं।

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

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

सबसे पहले मैंने बाइंडिंग रीडायरेक्ट वर्कअराउंड किया, जो एक समय के लिए काम करने लगता था, लेकिन हमारे देवता लगातार गलती से किसी ऐप को बदलकर कुछ बदल रहे थे ।config, एक नगेट पैकेज को अपडेट करना और AutoGenerateBindingRedirect (जो कि यह खुद बुरा सपना था) से लड़ रहा था।

अंत में, मैंने हर जगह HttpClientHandler के उपयोग को मजबूर करके इसे हल किया। इसमें हमारे अपने कोड को बदलना, तीसरे पक्ष के पुस्तकालयों में मुद्दों को उठाना और यहां तक ​​कि प्रतिबिंब जैसे हैक्स का उपयोग करना और मुद्दे के चारों ओर काम करने के लिए 3 पार्टी कोड की नकल करना शामिल है।

तो जो भी समाधान है, अगर नया पैकेज नए HttpClient / HttpClientHandler का समर्थन नहीं करता है, तो हम इसे नहीं करेंगे। यह बहुत बड़ा मुद्दा नहीं है क्योंकि अभी चीजें काम कर रही हैं। हालाँकि, "रियल फ़िक्स" को जल्द ही आने की आवश्यकता है, क्योंकि मैं 3 जी के अधिक पैकेज को अपडेट करने पर अवरुद्ध नहीं होना चाहता, जो कि उनके कोड को नेटस्ट्रीम में ले जा सकता है और इस समस्या को शुरू कर सकता है।

@dluxfordhpf ... आंतरिक समस्या का अच्छा विवरण देखना अच्छा होगा इसलिए हम प्रस्तावित समाधानों को समझते हैं ...

मैंने यहाँ समस्या का वर्णन करने की कोशिश की: https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198।
संक्षेप में:

• Http NuGet पैकेज 4.1 / 4.3 ".NET फ्रेमवर्क में" Http 4.0 को ओवरराइड करता है, लेकिन इसमें सुरक्षा गुण नहीं हैं। इसके अलावा यह हुड के तहत विभिन्न ओएस घटक का उपयोग करता है (यानी "बड़ा बदलाव" + संभावित रूप से टूटने वाले कोने के मामले (जबकि सीधे इस समस्या के लिए प्रासंगिक नहीं है, यह एक संकेत है कि यह मुसीबतों के लिए बैग है)।
• WebRequestHandler .NET फ्रेमवर्क का केवल एक हिस्सा है, लेकिन Http 4.0 पर निर्भर करता है और Http में सुरक्षा विशेषताओं की आवश्यकता होती है।
• एक बार जब आप NuGet से Http 4.1 / 4.3 पर निर्भरता लेते हैं और इनबॉक्स 4.0 .NET फ्रेमवर्क संस्करण को पुनर्निर्देशित करते हैं, तो आप WebRequestHandler का उपयोग नहीं कर सकते।
• चीजों को बदतर बनाने के लिए, Http में कुछ नए API हैं जो .NET मानक 1.6 का हिस्सा हैं और कुछ घटक उन पर निर्भर हैं। इसलिए हम केवल पुराने संस्करण में वापस रोल नहीं कर सकते।
• और निश्चित रूप से विवरण इसे और भी जटिल बनाते हैं।
• स्पष्ट बताते हुए: कोई "सही समाधान" नहीं है। यह एक को चुनने की बात है जिसका प्रभाव कम है।

@chadwackerman ... क्या "संस्करण 5.0" का मतलब के रूप में एक सर्वेक्षण लेना हर किसी के समय की कुल बर्बादी है। यह GitHub इंजीनियरिंग नहीं सामाजिककरण है।

यह समाजीकरण नहीं है। यदि आप वोटों को देखते हैं, तो यह दिखाता है कि मामले पर एकमत नहीं है। इसलिए भले ही आपको CoreFX टीम (.NET के ग्राहकों के साथ 10+ वर्षों के अनुभव के साथ) पर भरोसा नहीं है, जो कहती है कि " लोग हमारी इच्छा के अनुसार प्रमुख संस्करण पर ध्यान नहीं देते हैं ", मुझे आशा है कि यह देखने में मदद करता है कि यहां तक ​​कि कुछ MVP ( @onovotny) उस राय को साझा करते हैं। जबकि अन्य MVP असहमत हैं (@robertmclaws)।

@chadwackerman ... मैं एक 5.0 संस्करण टुडे

यह विकल्प है [2] मैंने ऊपर (विभिन्न संस्करण संख्याओं के साथ) रखा है। यह कुछ ऐसा है जिसे हम समानांतर में खोज रहे हैं। समाधान के प्रभाव को देखते हुए, यह स्पष्ट नहीं है " हाँ - यह स्पष्ट रूप से सही काम है, चलो इसके लिए चलते हैं "।

@robertmclaws ... Microsoft यह नहीं सोच सकता है कि संस्करण संख्याएं मायने जो भी करना चाहते हैं उसे ठीक करने की स्वतंत्रता प्राप्त करते

मैंने यह कहने की कोशिश नहीं की कि हम सही संस्करण में विश्वास नहीं करते हैं। हम बस मानते हैं कि डेवलपर्स का महत्वपूर्ण हिस्सा परवाह नहीं करता है और चाहता है कि सब कुछ हमेशा पूरी तरह से संगत हो - यानी हम जो कुछ भी चाहते हैं वह भी प्रमुख संस्करण धक्कों में नहीं कर सकते। यह हमारी टीम के वर्षों के अनुभव पर आधारित है। .NET सर्विसिंग और नौगेट पैकेज शिपिंग के साथ है।

@ गलबाना ... इस कॉम्बो को वास्तव में परीक्षण के तहत लाया जाना चाहिए, भले ही यह सच हो कि हर संभावना का परीक्षण नहीं किया जाना चाहिए ...

सहमत, अब जब हम जानते हैं कि यह महत्वपूर्ण कॉम्बो है तो हमें इसके लिए कवरेज जोड़ना चाहिए। और हमें यह देखने के लिए कि हमें Http NuGett पैकेज के आसपास अन्य समान कॉम्बो याद आ रहे हैं या नहीं, हमें इस क्षेत्र में थोड़ा और प्रहार करना चाहिए।

@chadwackerman ... अपनी इकाई परीक्षण परियोजना में शीर्ष 100 पैकेज जोड़ें ...

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

@chadwackerman ... और "समुदाय" को इस सामग्री को छाँटने की बजाय ...

हम (मैं CoreFX और CLR टीमों के लिए बोल सकते हैं) GitHub के माध्यम से समुदाय के लिए उत्पादों के परीक्षण की आउटसोर्सिंग नहीं कर रहे हैं। हम जो जहाज चलाते हैं उसकी गुणवत्ता पर उच्च पट्टी रखते हैं।

(आकस्मिक हॉटकी ने जवाब भेजा इससे पहले कि मैंने इसे समाप्त कर दिया ... जारी रखा जाए ...)

@chadwackerman ... Microsoft ने आंतरिक रूप से बग सूचियों और प्राथमिकताओं की पूरी तरह से नकल कर ली है ...

कम से कम CoreFX & CoreCLR टीमों पर सच नहीं है - GitHub सभी .NET कोर के लिए प्राथमिक बग डेटाबेस है। अन्य गैर-खुले स्रोत उत्पाद ("पूर्ण" .NET फ्रेमवर्क और .NET नेटिव) मुख्य रूप से आंतरिक बग डेटाबेस का उपयोग करते हैं।

@chadwackerman ... वे इस मुद्दे के लिए वैसे भी एक अनुरोध नहीं लेंगे ...

हम एक पुल अनुरोध नहीं करेंगे जो उपरोक्त सभी चिंताओं को संबोधित / व्याख्या करने में सक्षम नहीं है (incl। उन लोगों को प्रस्तुत करना जो इसे व्यक्तिगत रूप से सहमत नहीं हैं)। क्या ऐसे ओपन सोर्स प्रोजेक्ट हैं, जो इसके सभी प्रभावों के बारे में सोचे बिना एक त्वरित हैक करेंगे? हो सकता है कि अगर उसका 20% + ग्राहक फर्श पर है ... तो यहाँ ऐसा नहीं है (अभी तक)।

@chadwackerman ... Microsoft " @karelz में इतनी विनम्रता से "फिगर

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

@dluxfordhpf ... कृपया मुझे बताएं कि क्या हम आपको टाइपो के लिए डॉक्स का परीक्षण / मूल्यांकन / जांच करने में मदद कर सकते हैं / आपको जो भी चाहिए, हम मदद करने को तैयार हैं ...

धन्यवाद, हम आपके प्रस्ताव की सराहना करते हैं। जब हम बिट्स तैयार करते हैं (और हमारे पास मौजूद रिप्रोस पर मान्य हैं), तो हम निश्चित रूप से सहायता का स्वागत करेंगे, ताकि अधिक अंत-टू-एंड परिदृश्यों को मान्य किया जा सके। हम एक स्थिति से बचना चाहते हैं जब हम कुछ अंत-टू-एंड परिदृश्यों को ठीक करते हैं, जबकि दूसरों को उसी या किसी अन्य तरीके से टूट जाते हैं।

@ जहमाई ... लेकिन हमारे

धन्यवाद! देव दैनिक कार्य पर इस मुद्दे के प्रभाव को स्पष्ट करने के लिए यह एक अच्छा उदाहरण है जिसे हमें सुनने और समझने की आवश्यकता है। यह हमें यह समझने में मदद करता है कि वीएस टूलींग वाला कॉम्बो इसके साथ काम करने के लिए एक वास्तविक दुःस्वप्न बनाता है। रिलीज की योजना और तारीखों को अंतिम रूप देते समय हम इसे ध्यान में रखेंगे (जो मैं समाधान पर बसते ही शुरू कर दूंगा)।

@ जहमाई ... अगर नया पैकेज नए HttpClient / HttpClientHandler का समर्थन नहीं करता है, तो हम यह नहीं करेंगे ...

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

कृपया चर्चा को अभी से तकनीकी बनाए रखें।

शीघ्र नवीनीकरण:
समाधान [3] " System.Net.Http में सुरक्षा विशेषताओं को छिड़कें " जैसा कि ऊपर वर्णित महंगा (6w +) लगता है, इसलिए हमने इसके आंतरिक कार्यान्वयन विवरणों को फिर से अंकित किया: हम पैकेज के 4.0 संस्करण से मूल Http कार्यान्वयन का उपयोग करने पर विचार कर रहे हैं। + इसके ऊपर 8 नए एपीआई लागू करें जितना हम कर सकते हैं (कुछ तकनीकी रूप से वर्कअराउंड के साथ तोड़ सकते हैं)। http2 समर्थन और अन्य "नए WinHttp स्टैक" उपहार डिफ़ॉल्ट रूप से उपलब्ध नहीं होंगे, जो कोई भी उन्हें विशेष निर्माता (तकनीकी रूप से तोड़ने वाले परिवर्तन) को कॉल करने की आवश्यकता है, लेकिन उम्मीद है कि बहुत से लोग नए 4.1 / 4.3 अंडर-द-हूड उपहारों पर निर्भर नहीं होंगे ।
लागत अब तक काफी कम लगती है, लेकिन हम अभी भी पीछा कर रहे हैं और अंतिम योजना पर समझौता करने से पहले 2 हार के छोर (एपीआई) की लागत है। हमें कम से कम 2 एपीआई के लिए कुछ "दिलचस्प" संगतता निर्णय लेने होंगे, लेकिन उन्हें फिक्स की रिहाई के समय को धीमा नहीं करना चाहिए।

BTW: समाधान [2] " पूर्ववत करें निर्णय " से अधिक प्रभाव पड़ता है, जैसा कि हमने मूल रूप से अनुमान लगाया था (उदाहरण के लिए यह .NET मानक 1.6 को तोड़ देगा, और अधिक दीर्घकालिक गड़बड़ और स्पष्टीकरण पैदा करेगा)। हम इसे इस समय अंतिम विकल्प के रूप में रख रहे हैं, यदि उपरोक्त बहुत महंगा है या अन्यथा अनुचित है।

यदि आप वर्तमान में इस मुद्दे के किनारे के मामलों को देख रहे हैं, तो यह जाँच के लायक हो सकता है:
https://github.com/gulbanana/repro-netstandard-httpclient

यह समाधान प्रदर्शित करता है कि वर्तमान में vs2017rc में net.netx और netstandard परिणामों का उपयोग करके system.net.http के क्लैशिंग संस्करणों का उपयोग किया जा रहा है। मुझे यकीन नहीं है कि कैसे ओओबी चीज से संबंधित है।

मैं सराहना करता हूं (और स्पष्ट रूप से प्रशंसा करता हूं) @karelz कैंडर यहां है लेकिन मैं अंतिम बार एक संस्करण हॉर्न

अगर आपको CoreFX टीम (.NET के ग्राहकों के साथ 10+ वर्षों के अनुभव के साथ) पर भरोसा नहीं है, जो कहती है कि "लोग प्रमुख संस्करण पर ध्यान नहीं देते हैं" ... .NET सर्विसिंग और शिपिंग के साथ हमारी टीम के वर्षों के अनुभव के आधार पर NuGet पैकेज ...

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

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

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

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

आपकी उम्मीदवारी और आपके स्पष्टीकरण के लिए बहुत बहुत धन्यवाद।

@chadwackerman ... आप इस तरह के एक बड़े पैमाने पर संस्करण समस्या के बीच में संस्करण की गहरी समझ अनुभवी टीम का दावा नहीं कर सकते। ... उम्मीद है कि हम कम से कम सहमत हो सकते हैं कि प्रमुख संस्करण संख्या को टक्कर नहीं दे रहे हैं और एक टूटने वाला परिवर्तन सभी दुनिया में सबसे खराब है। फिर भी यहाँ हम हैं। ...

आप 2 बड़ी धारणाएँ बना रहे हैं:

1. मान्यता: शिपिंग से पहले ब्रेकिंग परिवर्तन ज्ञात होता है (उर्फ ब्रेकिंग समझा जाता है)।
   
   
   
   • इस मुद्दे के लिए ऐसा नहीं है - जैसा कि "अनपेक्षित ब्रेकिंग परिवर्तन" के वर्ग के लिए आम है। हाँ, चीजें कभी-कभी फिसल जाती हैं :(। महत्वपूर्ण मेट्रिक्स आईएमओ हैं: तेजी से प्रतिक्रिया (मैं मानता हूं कि हमने इस मुद्दे पर अब तक ऐसा नहीं किया था) और ऐसी गलतियों की कम / कम आवृत्ति।
   
   
2. धारणा: संस्करण विशेषज्ञ हर एक परिवर्तन (जो वे नहीं कर रहे हैं) की समीक्षा करने में सक्षम हैं और सामान्य रूप से लोग कभी भी गलती नहीं करते हैं (विज्ञान-फाई)।
   
   
   
   • इस विशेष मामले में, System.Net.Http API योजना (डेस्कटॉप के लिए नया 8 APIs) का संस्करण विशेषज्ञों द्वारा शिपिंग से पहले उच्च-स्तरीय समीक्षा की गई थी। उन्होंने विकल्पों पर सुझाव और मार्गदर्शन प्रदान किया। दुर्भाग्य से, तोड़ने के स्तर को किसी के द्वारा (न तो क्षेत्र के विशेषज्ञों और न ही विशेषज्ञों के संस्करण) द्वारा मान्यता प्राप्त थी, इसलिए चुना गया समाधान इन परेशानियों को जन्म देता है।
   
   

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

@chadwackerman ... "बजट" और "6+ सप्ताह के देव समय" ... कुछ विशेषताओं पर थप्पड़ मारने के लिए। ...

लागत "थप्पड़ लगाने की विशेषताओं" से नहीं है, यह आसान हिस्सा है। महंगा हिस्सा विकल्प पर खुले प्रश्न से है [3]:

https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198: खुला प्रश्न: क्या हम नए WinHttp- आधारित System.Net.Http के साथ WebRequestHandler कार्य की आंतरिक निर्भरता बना सकते हैं?

पता चला, यह काफी काम है, आंतरिक निर्भरता बस बहुत बुरा है :(

मैं वास्तव में इस पर चर्चा की सभी की सराहना करता हूं। गंभीरता से। यह विस्मयकारी है। इस पर खुले रहने के लिए धन्यवाद।

दिन के अंत में, हालांकि, यहां डॉटनेट / कोरफैक्स # 1 मुद्दा है: आप लोग स्टैक के एक प्रमुख हिस्से को फिर से लिखते हैं। वह हिस्सा जो लगभग हर चीज के लिए केंद्रीय है। और आपके पास दूरस्थ रूप से पर्याप्त परीक्षण कवरेज भी नहीं है। इसके लिए विशेषज्ञों की जरूरत नहीं होनी चाहिए। यह एक स्पष्ट रूप से प्रलेखित परीक्षण मामला होना चाहिए था जो उस समय लिखा गया था जब WebRequestHandler लिखा गया था (या निर्णय कोर को पोर्ट नहीं करने के लिए किया गया था), और इसे तब तोड़ना चाहिए जब आप लोग इसके साथ बंदर करना शुरू कर दें।

शिपिंग के 5 वर्षों के बाद .NET 4.0-संबंधित सामान, वास्तव में एकीकरण परीक्षण कवरेज नहीं होने के लिए कोई बहाना नहीं है जो किसी ने इसे पकड़ा होगा। यदि आप खुद को इसका बहाना बनाते हुए पाते हैं, तो आप अपनी टीम से उत्कृष्टता की मांग नहीं कर रहे हैं।

अगर वहाँ था:

• उचित परीक्षण कवरेज
• एक उचित QA प्रक्रिया
• एक उचित बीटा रिलीज
• और विशिष्ट पैकेज के लिए जिम्मेदार विशिष्ट टीमों को मुद्दों को प्रस्तुत करने का एक उचित तरीका

... ऐसा नहीं होता।

यदि टीम:

• एक ही समय में .NET के हर पहलू को फिर से लिखने के द्वारा समुद्र को उबालने पर इतना नर्क नहीं था
• ".NET 5 / MVC 6" परियोजना के शुरू होने के बाद से हममें से जो इस बारे में मुखर रहे हैं, उनकी चेतावनी को ध्यान में रखा

... ऐसा नहीं होता।

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

इस पर एक _very real_ और _significant_ लागत है। हमें अपने CI सर्वर को हफ्तों पहले बंद करना पड़ा और हर बार मैन्युअल रूप से web.config को सत्यापित करते हुए तैनात करना पड़ा। हम दिन में कम से कम एक बार तैनात करते हैं। अतिरिक्त मैन-आवर्स में हफ़्ते में एक हज़ार डॉलर, उस समय को कुछ और करने में होने वाली देरी का उल्लेख नहीं करना।

फिर, यह भी HttpClient वास्तुकला में मौजूदा खामियों से निपटने में अनगिनत घंटों को ध्यान में नहीं रख रहा है: जो कि इंस्टेंस को ठीक से निपटाना नहीं है, टीसीपी कनेक्शन को खुला रखना और DNS प्रविष्टियों को बहुत लंबे समय तक कैशिंग करना।

तो, आप इसके लिए कुछ उतार-चढ़ाव पकड़ने जा रहे हैं। और इसके लायक है।

और यह तय करने के लिए कि "महंगा" कैसे तय होता है, मुझे उम्मीद है कि आप इसे सही करने के लिए अपने कई सर्वश्रेष्ठ लोगों की एक बाघ-टीम लगा रहे हैं, और इसे एक व्यक्ति के कंधों पर नहीं डाल रहे हैं।

... मनोबल सुधरने तक सजा जारी रहेगी।

उन्हें उस गलती को ठीक करने दें जिसे उन्होंने स्वीकार किया था और उन्हें छेड़छाड़ में नहीं बांधा गया था।

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

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

लेकिन शायद इसे सर्कुलर लॉजिक और उस डबल-टॉक की तरह का झटका नहीं लगना चाहिए जो Microsoft प्रबंधन की कुछ परतों पर व्यापक है, वास्तविक दुनिया के उन ग्राहकों के सामने अच्छा नहीं खेलते जो वास्तव में सामान का उपयोग करते हैं।

.NET कोर Microsoft SQL सर्वर में अहस्ताक्षरित मान लिखने की क्षमता खो दी है। 2014 में वापस जा रहे UserVoice साइटों में सबसे ऊपर एक उपेक्षित मुद्दा है। उद्यमों के पास अपने डेटाबेस स्कीमा (विशेष रूप से अहस्ताक्षरित कुछ के रूप में अहस्ताक्षरित) को बदलने की विलासिता नहीं है, क्योंकि एक जोड़ी कार्यक्रम प्रबंधक तीन के बाद एक ही पृष्ठ पर नहीं मिल सकते हैं वर्षों। इस बीच Redis और SQLite (जो कुछ भी है) बस ठीक काम करते हैं, और स्कॉट हैंसेलमैन रॉकस्टो डेमो जैसे कि यह सामान वास्तव में काम करता है। यहाँ निश्चित रूप से आंतरिक और बाह्य वास्तविकताओं के बीच एक चौड़ी खाई है और मुद्दों को (विनम्रता से) किया जाना चाहिए।

नामकरण मुश्किल है। संस्करण कठिन है। Microsoft का एक अनूठा दृष्टिकोण है, जहाँ वे सभी प्रकार के उद्योगों के ग्राहकों के साथ खून बहने वाले किनारे से लेकर बेल की बेल तक का सौदा करते हैं। CRM में विदेशी हैं, जो कि "स्पष्ट" प्रतीत होते हैं, विकास दृष्टिकोण की अवधारणाएं। आप समस्याओं को कैसे देखते हैं, क्या महत्वपूर्ण है और क्या महत्वपूर्ण नहीं है, अलग-अलग है। और फिर आप अग्रिम प्रौद्योगिकी, समस्याओं के लिए अलग-अलग दृष्टिकोण जोड़ते हैं: DAO बनाम ADO.NET बनाम LINQ बनाम EF एक आम आसान तुलना का उपयोग करने के लिए। अंत में, इंटरनेट सर्वर क्षेत्र में प्रतिस्पर्धा, टर्नकी गोलियों के साथ पूरे नए हार्डवेयर मॉडल और बाल्मर वायरस। अलग-अलग सीमाओं और फायदों के साथ समस्याओं के बारे में सोचने और मॉडलिंग करने के नए तरीके।

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

मैं एक बग से चूक गया जहां अगर हम डी ड्राइव पर स्थापित होते हैं, तो कुछ शर्तों के तहत अनइंस्टॉल पर ... उत्पाद सभी फ़ाइलों को हटा सकता है HD। हमें $ 40k प्रेस की हुई सीडी को जलाना था।

लोग सही नहीं हैं और हम गलतियाँ करते हैं। हालाँकि, दोष एक बेकार अवधारणा है। यह शर्म और अपमान जैसी विनाशकारी अवधारणाओं के माध्यम से हमें शक्तिशाली महसूस कराता है। विनम्रता और क्षमा अधिक शक्तिशाली हैं। यही कारण है कि हम बेहतर करते हैं, बेहतर तरीके सीखते हैं, और कभी-कभी सिर्फ इसलिए कि पहली जगह में कुछ महत्वपूर्ण है।

हाँ समस्या मुझे बहुत गुस्सा करती है, लेकिन यह निश्चित हो रही है। और आप जानते हैं कि क्या - क्या खुला स्रोत समस्याओं की तरह दशकों से पहले भी इस तरह से परेशान करने की कोशिश करता है। बस केर्बोस को एक लिनक्स सिस्टम के लिए प्रयास करें या GSSAPI में देखें। InitializeSecurityContext / AcceptSecurityContext बहुत आसान है। पैसा महत्व रखता है।

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

वे दो अलग-अलग उत्पाद थे। .NET एक एकल उत्पाद है। और मैं किसी एक व्यक्ति को दोष देने की कोशिश नहीं कर रहा हूं। मैं इस प्रक्रिया को दोष देता हूं। ऐसा लगता है कि क्योंकि Microsoft OSS गया था, उन्होंने उन प्रक्रियाओं को फेंक दिया जिससे उन्हें खिड़की से बाहर इतिहास में सबसे स्थिर विकास ढांचे को जहाज करने में मदद मिली। मुझे ऐसा लग रहा है कि अगर इसे NuGet के बजाय .NET 4.6.3 में भेज दिया गया होता तो यह पकड़ा गया होता।

OSS को अनाड़ी संक्रमण निश्चित रूप से मामलों में मदद नहीं कर रहा है। मैं OSS को दोष नहीं देता, लेकिन Microsoft निश्चित रूप से सभी स्पष्ट गलतियाँ करने में गर्व महसूस करता हूँ।

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

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

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

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

यहाँ कुछ बयानबाजी Microsoft के "अच्छे पुराने दिनों" की स्मोक करती है, जो विडंबनापूर्ण है क्योंकि अब हम जो भी बदलाव देख रहे हैं, वह माइक्रोसॉफ्ट की ग्राहक की मांग का सीधा जवाब है।

हम बंद स्रोत और ड्रैकनियन रिवर्स इंजीनियरिंग (डी-संकलन) नियमों से बीमार थे, इसलिए हमें संदर्भ स्रोत और अब खुला स्रोत मिला।

हम .net फ्रेमवर्क बग्स से बीमार थे जो एक मशीन पर स्थापित हर एप्लिकेशन को प्रभावित करते थे और उद्यम वितरण और आईटी विभागों को ठीक करने के लिए एक लंबा समय लगता था और ऐसा होने से पहले हर .net फ्रेमवर्क संस्करण अद्यतन को अर्हता प्राप्त करने के लिए आईटी विभागों की आवश्यकता थी, इसलिए अब हम इसकी ओर बढ़ रहे हैं। हमारे ऐप्स के साथ नौगट पैकेजों की शिपिंग करें ताकि हम उपलब्ध होते ही इसे ठीक कर सकें।

हम Microsoft कनेक्ट से बीमार थे जो हर दूसरे बग को "डिज़ाइन किए गए" के रूप में काम कर रहे थे या रिलीज़ होने के लिए 6 महीने का समय भी ले रहे थे, इसलिए अब हमारे पास Github प्रोजेक्ट्स टीम द्वारा और अधिक बारीकी से प्रबंधित हैं जो वास्तव में कोड लिखते हैं, और पूरे समुदाय प्रत्येक समुदाय द्वारा उठाए गए कार्य मद पर आसानी से अपना 2 सी दे सकता है।

हम Microsoft के हर अच्छे विचार को समुदाय में ले रहे थे और एक मालिकाना क्लोन बना रहे थे जो गैर-Microsoft उपकरणों के साथ अच्छा नहीं खेलता था, इसलिए अब हम NPM, Gulp, NodeJS इत्यादि का उपयोग करते हैं।

हम C # के लिए केवल Windows के लिए व्यवहार्य होने के कारण बीमार थे, और मोनो जैसी परियोजनाएं भी बराबर बनाए रखने के लिए संघर्ष कर रही थीं, जबकि हर जगह #ifdef के साथ बग या कार्यक्षमता की कमी के कारण काम करना पड़ता था, इसलिए अब हमारे पास ज़ैमरीन संदर्भ स्रोतों के साथ मोनो विकास का प्रस्ताव है और हमें अनुमति दे नवीनतम C # भाषा को कोड करने के लिए .net, UWP, iOS, Android और netcore पर समान कोड आधार साझा करें।

यह सब एक बार में हो रहा है क्योंकि यह है। हम Microsoft को पकड़ने के लिए खेलने की प्रतीक्षा नहीं करने जा रहे हैं, क्योंकि यह कार्यक्षमता के सही स्थिर टुकड़ों को जहाज करता है जो किसी भी समय केवल हमारी समस्याओं का आधा हल करता है।

मेरा मुद्दा यह नहीं है कि यह सब परिवर्तन एक ही बार में हो रहा है। और न ही इस तरह की कोई समस्या है। मेरे लिए असली मुद्दा यह है कि _ कैसे ठीक करने के लिए यह पता लगाने में _ और

तीन सप्ताह और कोई अद्यतन नहीं। नया साल मुबारक हो सब लोग।

इस उद्धरण को @karelz से जोड़ने के लिए संपादित करें क्योंकि

मैं अपडेट (उम्मीद है कि अधिक तकनीकी विवरण के साथ) पोस्ट करूंगा, जब हमारे पास उन्हें होगा, कम से कम साप्ताहिक आधार पर।

@chadwackerman गंभीरता से, क्या आप समझते हैं कि आपका बुरा रवैया इस मुद्दे को तेज़ी से ठीक करने में मदद नहीं करेगा? और इसके अलावा, आप यहाँ अपने आप को मूर्ख बना रहे हैं। कृपया अपने स्वर में सुधार करें।

क्या स्वर? उन्होंने एक बयान दिया, जिसमें सटीक होने का लाभ है, फिर सभी को नव वर्ष की शुभकामनाएं दीं। यदि आपने इसे नकारात्मक रूप से लिया, तो यह आपका मुद्दा है।

और उस पहले बयान के बारे में: यह एक प्रमुख ब्रेकिंग मुद्दा है जो रनटाइम तक दिखाई नहीं देता है। पांच साल पहले स्कॉटगू या रॉब हॉवर्ड ने 24-7 पर एक टीम को फिक्स शटडाउन तक दिया होगा। अब यह सिर्फ "आप जानते हैं, हम इसके चारों ओर मिलेंगे।"

आप जानते हैं कि लोगों को क्या खुशी मिलेगी? इस समस्या को ठीक करो। अन्यथा, वहाँ कुछ नाराज ग्राहक हैं, और उनमें से कुछ इस धागे पर हैं। उन्हें पेशाब करने का पूरा अधिकार है। तो अपने आक्रोश के साथ कुछ और करने के लिए खोजें, @pollax। आपने इस सूत्र में कुछ भी सार्थक योगदान नहीं दिया है, और किसी ने आपका गितहब थॉट पुलिस का अभिषेक नहीं किया है। आपने इस समस्या पर अपनी कंपनी के पैसे का $ 5K भी बर्बाद नहीं किया है।

ठीक है, शायद मैं इसमें बहुत कुछ पढ़ता हूं और पिछले टिप्पणियों में इस्तेमाल किए जाने वाले लहजे के कारण, मैंने इसे थोड़ा विडंबनापूर्ण लहजे में पढ़ा। उसके लिए माफ़ करना।
मुद्दे के बारे में; मैं तुम्हें सुनता हूं। मैं खुद इससे परेशान हूं (अन्यथा मैं इस मुद्दे को इतनी बारीकी से नहीं देख रहा होता) इसलिए कृपया इस बारे में कोई धारणा न बनाएं कि मेरे पास इस पैसे / संसाधनों के मामले में क्या है / बर्बाद नहीं हुआ है। लेकिन एक डेवलपर के रूप में, मुझे पता है कि किसी बड़ी समस्या को ठीक करने की कोशिश में किसी को घूरना सबसे बुरी बात है।

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

मैं भी इस बात की रिपोर्ट प्राप्त कर रहा हूं कि हमारे एक्सेप्शनलेस नगेट पैकेज के साथ पूरे ढांचे पर। किसी भी ठोस सुधार या चारों ओर काम?

मैं भी पूर्ण फ्रेमवर्क 4.6.2 चल रहे एक Windows सेवा से ASP.NET कोर इस आत्म होस्टिंग मिल। निर्भरता NETStandard.Library 1.6.1 मुझे System.Net.Http 4.3.0 का उपयोग करने के लिए मजबूर करती है।

निर्भरता NETStandard.Library 1.6.1 मुझे System.Net.Http 4.3.0 का उपयोग करने के लिए मजबूर करती है।

और इस पूरी स्थिति के साथ यह मेरी सबसे बड़ी समस्या है

अधिक से अधिक पैकेज मेटा-पैकेज पर निर्भरता ले रहे हैं, मुझे हर उस निर्भरता को अपग्रेड करने के लिए मजबूर कर रहे हैं (या डाउनग्रेड / विशिष्ट लोगों की अनदेखी की एक कठिन लड़ाई लड़ते हैं)

यह सिस्टम निर्भरता के "मिक्स एंड मैच" के पिछले वादे के विपरीत जाता है

मुझे 4.6.1 (और महत्वपूर्ण समय गंवाते हुए) से अपने सिस्टम को 4.5.2 पर डाउनग्रेड करना पड़ा, क्योंकि प्रत्येक दूसरा पैकेज .net 1.6 और उसके छोटी गाड़ी System.Net.Http में लाया गया था।

यदि ये केवल 3 पार्टी पैकेज थे, तो ठीक है, इसलिए, मैं उनके चारों ओर जा सकता हूं, अधिक दानेदार निर्भरता का उपयोग करने के लिए अनुरक्षकों को रोक सकता हूं, लेकिन मेरे अधिकांश डिप्स एमएस से थे, और मैं उम्मीद कर रहा हूं कि एमएस को दानेदार निर्भरता का उपयोग करने के लिए, नहीं बस थप्पड़ .net 1.6 नगेट फ़ाइल में

मैंने पिछले कुछ दिनों से एक अपडेट भेजने की योजना बनाई है, इसलिए यहां यह है:

@ CIPop के कार्य को सुरक्षा समस्या के कारण पहले से हटा दिया गया था। उनका काम @davidsh ने उठाया था। @davidsh इस सप्ताह के प्रारंभ में पीआर (यानी अब किसी भी दिन) प्रस्तुत करने की योजना बना रहा है।

यहां हमारी निष्पादन योजना और स्थिति का विवरण दिया गया है:

उच्च स्तरीय योजना:
A. बदलें WinHttpHandler को CoreFX बिल्ड के net46 बिल्ड में HttpClientHandler के साथ बदलें
B. HttpClientHandler पर 8 नए एपीआई लागू करें जो हमने 4.1.0.0 OOB पैकेज में पेश किए हैं

निष्पादन योजना:

EDIT 2017/1/12 - निष्पादन योजना को शीर्ष-सबसे पोस्ट https://github.com/dotnet/corefx/issues/11100#issue -173058293 पर ले जाया गया

@niemyjski आसपास कोई ठोस सुधार या काम?

अपमानजनक पैकेज को 4.0.0.0 तक डाउनग्रेड करने के लिए वर्कअराउंड है (देखें https://github.com/dotnet/corefx/issues/11100#issuecomment-246469893), दुर्भाग्य से ऊपर दिए गए टिप्पणियों के अनुसार, नुबेट निर्भरता में कोई भी संपादन इसे वापस लाएगा। - जो महत्वपूर्ण कारण है कि यह मुद्दा इतना दर्दनाक क्यों है।

मुझे आशा है कि इसे हल करने के लिए आंतरिक रूप से कुछ प्रक्रिया में सुधार होगा; यह हम सभी के लिए चूसना होगा यदि एकमात्र तरीका है कि हम सुधार प्राप्त कर सकते हैं शाप शब्दों के माध्यम से।

मेरे पास प्रक्रिया में सुधार के बारे में कुछ विचार (और प्रश्न) हैं, ताकि भविष्य के महत्वपूर्ण प्रभावी मुद्दों को इतने लंबे समय तक किसी का ध्यान न जा सके। हालाँकि, मैं जानबूझकर उस चर्चा को टाल रहा हूँ, जब हमारे पास एक भेज दिया गया ठीक है।

Woot !!!

अच्छा किया दोस्तों @karelz

अद्यतन के लिए धन्यवाद। PlatformNotSupported से बेहतर कुछ नहीं होगा क्योंकि वे नए एपिस हैं जो विरासत सॉफ्टवेयर पर भरोसा नहीं करते हैं।

ऐसा लगता है कि पोस्ट-फिक्स, बाध्यकारी रीडायरेक्ट के माध्यम से एकीकरण अभी भी आवश्यक होगा, लेकिन पुराने असेंबली के बजाय नए पर पुनर्निर्देशित करना, कौन सा नगेट सही तरीके से उत्पन्न कर सकता है?

अब जब PR dotnet / corefx # 15036 चेक किया गया है, तो इस समस्या को दूर किया जाना चाहिए net46। System.Net.Http.dll अब .NET फ्रेमवर्क से अंतर्निहित HTTP स्टैक का उपयोग कर रहा है। इसका मतलब यह है कि यह WebRequestHandler के साथ 100% संगतता है।

कृपया MyGet dev फ़ीड पर नवीनतम पैकेज देखें। आप नवीनतम निर्मित System.Net.Http.dll पैकेज का उपयोग करना चाहेंगे जो आज है:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

संस्करण 4.4.0-बीटा-24913-02।

आप अपने NuGet पैकेज स्रोत फ़ीड को कमांड लाइन टूल या विज़ुअल स्टूडियो के साथ बदलकर देव फ़ीड पैकेज का उपयोग कर सकते हैं।

निर्देश:

कमांड लाइन:
के तहत nuget.config में निम्नलिखित जोड़ेंतत्व:

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

दृश्य स्टूडियो:
VS, टूल्स-> Options-> Nuget Package Manager-> पैकेज स्रोत -> स्रोत के अंतर्गत जोड़ें, इस url, https://dotnet.myget.org/F/dotnet-core/api/v3/index.json का उपयोग

या तो मामले में, सुनिश्चित करें कि आप सूची में पहले फ़ीड के रूप में MyGet देव फ़ीड को सूचीबद्ध करते हैं।

और dotnet / corefx # 15036 में फिक्स को संक्षेप में प्रस्तुत करने के लिए, हमने WebRequestHandler ।

HttpClientHandler (जो .NET कोर 1.1 और उससे आगे का हिस्सा हैं) में जोड़े गए नए गुणों के समर्थन के स्तर के संदर्भ में, 'net46' लक्ष्य पर चलने के दौरान निम्नलिखित इन नए गुणों के अपेक्षित व्यवहार को सारांशित करता है :

1) सार्वजनिक बूल CheckCertificateRevocationList
PlatformNotSupportedException फेंकता है

2) सार्वजनिक X509 सर्टिफिकेट प्रमाण पत्र क्लाइंट सर्टिफिकेट
कार्यान्वित

3) सार्वजनिक ICredentials DefaultProxyCredentials
कार्यान्वित

4) सार्वजनिक int MaxConnectionsPerServer
मौजूदा ServicePoint तर्क के खिलाफ लागू किया गया

5) सार्वजनिक int MaxResponseHeadersLength
कार्यान्वित

6) सार्वजनिक IDEDIAगुण
कार्यान्वित

7) सार्वजनिक दुर्गServerCertificateCustomValidationCallback
सिवाय इसके कि पहले पैरामीटर हमेशा आंतरिक HttpWebRequest से HttpRequestMessage वर्तमान अक्षमता के कारण शून्य है

8) सार्वजनिक SslProtocols SslProtocols
PlatformNotSupportedException फेंकता है

वू हू! धन्यवाद दोस्तों!

क्या किसी को @davidsh के बिट्स को मान्य करने का मौका मिला? हम वास्तव में इस धागे पर संकेतित 7-ईश परिदृश्यों पर कुछ अंत-टू-एंड सत्यापन का स्वागत करेंगे।

हम अब तक @onovotny के सरलीकृत

एक बार जब हमारे पास ऐसा हो जाएगा, हम परिवर्तन को 1.1 शाखा में पोर्ट करने की दिशा में आगे बढ़ेंगे और अगले सप्ताह एक पैच जारी करेंगे।

मैं इस सप्ताह कुछ परीक्षण करवाऊंगा। मुझे लगता है कि 1-2 दिनों के लिए शुरू नहीं किया जा सकता है, मैं सिर्फ एक वृद्धि में खींच लिया गया।

@dluxfordhpf धन्यवाद! आपकी सहायता की सराहना।

मैंने अभी-अभी 4.4.0-beta-24913-02 को अपनी परियोजना में स्थापित किया है। यह मेरे मामले में मदद करता है।

केस: पूर्ण फ्रेमवर्क 4.6.2 चल रहे विंडोज सर्विस से ASP.NET कोर की सेल्फ होस्टिंग। निर्भरता NETStandard.Library 1.6.1 मुझे System.Net.Http 4.3.0 का उपयोग करने के लिए मजबूर करती है।

मेरे अनुभव में myget फीड बहुत धीमा है। System.Net.ttp 4.4.0-beta-24913-02 को स्थापित करने में कुछ मिनट लगे
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 82079ms
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 93813ms

पुष्टि के लिए और परिदृश्य का वर्णन करने के लिए @ annemartijn0 धन्यवाद!

वर्तमान में इस पृष्ठ पर परिणाम आने में पाँच से सात मिनट लग रहे हैं:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Microsoft इन छायादार छोटी कंपनियों और बेवकूफ छोटी साइटों के लिए महत्वपूर्ण अवसंरचना क्यों आउटसोर्सिंग कर रहा है? आप वास्तव में बेल्जियम में टेक टोमेटो नामक कंपनी में अपने व्यवसाय और मेरे व्यवसाय को पिन करने के लिए चुन रहे हैं?

वैसे भी ... मेरे पास पहले से ही एक myget फीड था, लेकिन जब तक मैंने विजुअल स्टूडियो को फिर से शुरू नहीं किया, तब तक इस लाइब्रेरी को नीचे नहीं खींच रहा था, तब कहीं संवाद में दबे "अपडेट" बटन को क्लिक किया, फिर दूसरी बार विजुअल स्टूडियो को फिर से शुरू किया। मैं वर्तमान में इसे टाइप कर रहा हूं जबकि Visual Studio 2015 मेरे पैकेजों को पुनर्स्थापित करने का प्रयास कर रहा है।

अपडेट: विजुअल स्टूडियो अभी भी मंथन कर रहा है, लेकिन मेरे पेज के रिफ्रेश पेज पर आखिरकार दिखाई दिया। यह पुस्तकालय के इस संस्करण के एक दिन में शायद एक दर्जन डाउनलोड दिखाता है। इस बीच विजुअल स्टूडियो इसे "System.Net.Http - 75.8K डाउनलोड" के रूप में सारांशित करता है। मैंने हमेशा यह मान लिया है कि ये आँकड़े मुझे गलत बात बता रहे थे, लेकिन यहाँ एक बढ़िया उदाहरण है कि यह वह क्यों नहीं है जो मैं चाहता हूँ। कम से कम कृपया मुझे वर्तमान संस्करण की स्थिति बनाम सारांश बताएं ताकि मैं अनजाने में .NET इतिहास में इस बेतुके पल के दौरान पागलपन में स्पष्ट रूप से विरोध किए बिना एक अल्फा परीक्षक न बन जाऊं।

5 घंटे बाद और मैं अभी भी इस पैच को आज़माने में असमर्थ हूँ:

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

पाँच मिनट बाद...

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

.NET एक टायर की आग है।

आसान वहाँ @chadwackerman। आपने अपने बीटा / अल्फ़ा / नॉन प्रोडक्शन फीड को _opted in_ कर दिया है ताकि इसका मतलब है कि आप समस्याओं को छोड़कर, आदि के लिए तैयार हैं। उन्होंने कहा, मैं उम्र के लिए myget का उपयोग कर रहा हूं (अब सब्सक्रिप्शन) और बहुत कम मुद्दों के साथ यह। तो शायद .. बस हो सकता है .. यह आपका कंप्यूटर / नेट-कनेक्शन / जो भी हो? (मैंने पिछले 12+ महीनों में MyGet का उपयोग करके कुछ वास्तविक शानदार जीत हासिल की है)।

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

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

@chadwackerman ऐसा लग रहा है कि इस समय मायगेट फ़ीड पीड़ित है। मुझे 100% यकीन नहीं है कि कैसे काम करता है, लेकिन मुझे लगता है कि अगर आपके पास एक समर्पित होस्ट ("dotnet.myget.org") है तो फीड वास्तव में किराए पर हैं और QOS सीमाएं हैं।

यहां जाने से पता चलता है कि पैकेज मौजूद है, लेकिन इसे आने में थोड़ा समय लगता है: https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

@PureKrome मैं एक पूर्व Microsoft देव प्रबंधक हूं, जिसे इस बिल्ड (ऊपर देखें) की जांच करने के लिए कहा गया था। व्यक्तिगत रूप से इस बग को आंतरिक रूप से आगे बढ़ाने के बाद क्योंकि .NET टीम में किसी को भी इसकी जानकारी नहीं थी। और अब वे मुझे लानत बाइनरी जहाज करने का प्रबंधन नहीं कर सकते।

जब मैं एक देखता हूं तो मुझे टायर में आग लगती है। मैं उन्हें Microsoft के लिए एक जीवित करने के लिए इस्तेमाल करता था।

@chadwackerman मैं फ़ीड के साथ मुद्दों के साथ आपकी निराशा को समझ सकता हूं। हालांकि, कॉलिंग नाम ('बेवकूफ छोटी साइटों' और 'छायादार छोटी कंपनियों') क्रम से बाहर है।
टेक टमाटर योग्य व्यक्तियों द्वारा स्थापित / चलाया जाता है: @maartenba , एमवीपी अवार्ड आपके पूर्व नियोक्ता, और @xavierdecoster , वर्तमान एमएस कर्मचारी; एक देश में (जो मैं आंशिक हूं) जो नवाचार को प्रोत्साहित करता है। कंपनी का नाम शायद ही प्रासंगिक है और यह कि कंपनी बेल्जियम में स्थापित की गई थी, पता चलता है कि .NET कोर टीम समाधान के लिए रेडमंड, डब्ल्यूए से परे दिखती है।
मैं इस मुद्दे को हल करने में आपकी रचनात्मक योगदान के लिए तत्पर हूं।

मॉडरेटर द्वारा संपादित की गई सामग्री

इस थ्रेड में कुछ टिप्पणियों के खिलाफ एक आचार संहिता रिपोर्ट प्रस्तुत की गई थी और परिणामस्वरूप हमने उस कोड का उल्लंघन करने के लिए जज की गई कुछ सामग्री को हटा दिया है। यदि आपके पास इसके बारे में कोई प्रश्न या चिंता है तो कृपया आचरण करें @@@netnetfoundation.org।

कंपनी में आपकी पूर्व स्थिति @chadwackerman आपको किसी को

अरे लोग - नेट फाउंडेशन यहां से मार्टिन, समझाने के लिए करना चाहता था इस ।

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

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

क्या किसी और ने टेक टमाटर से संपर्क करने की कोशिश की है? मेरी पूछताछ का कोई जवाब नहीं।

यदि आप फ़ीड जोड़ने के बाद अजीब निर्माण चेतावनियों को छाँटने की कोशिश करते हैं तो यह कैसा दिखता है:

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

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

... और इसी तरह।

और इस लिंक को अभी भी पेज दिखाने में 5+ मिनट लगते हैं:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

यह (a) अभी तक तय नहीं है b) समुदाय द्वारा नजरअंदाज नहीं किया गया है और c) .NET टीम द्वारा दिन-प्रतिदिन के विकास के रूप में सहन किया जाता है, इस बग के कारण प्रक्रिया, टूलिंग, संस्कृति और प्रबंधन में स्पष्ट खामियों को मजबूत करने का काम करता है। शुरुआत के साथ - साथ ही बग को महीनों तक नजरअंदाज किया जाता रहा जब तक कि मैंने व्यक्तिगत रूप से इसे आंतरिक रूप से आगे नहीं बढ़ाया।

मैं आगे पोस्टमार्टम @karelz वादा कर रहा हूँ।

हाय चाड,

वह पृष्ठ लोड समय कुछ ऐसा है जिसे हम देख रहे हैं। NuGet पुनर्स्थापना समय सामान्य नहीं है। यदि संभव हो तो आप MyGet.org पर समर्थन के माध्यम से हमारे (MyGet) तक पहुंच सकते हैं, उपयोग में अपने NuGet.exe संस्करण के उल्लेख के साथ-साथ-साथ-साथ एक विस्तृत विवरण सक्षम करें? यह निश्चित रूप से किसी भी पूर्ण मुद्दों को इंगित करने में हमारी मदद करेगा।

धन्यवाद!

पैकेज प्रबंधक कंसोल होस्ट संस्करण 3.5.0.1996

जब मैं myget.org फ़ीड जोड़ता हूं, तो मैं दृश्य पंक्ति से लॉग को प्राप्त करना देखूंगा क्योंकि दृश्य स्टूडियो रॉक सॉलिड से अस्थिर हो जाता है। और एक बार एक त्रुटि होने पर एक पैकेज पूरी तरह से खत्म हो जाता है।

ps @karelz : टायर की आग।

क्या आप www.nuget.org/downloads से नवीनतम (रात) NuGet.exe का उपयोग करके इस कमांड लाइन को आज़मा सकते हैं?

सटीक आदेश: NuGet.exe स्थापित करें System.Net.Http -Version 4.4.0-beta-24913-02 -Verososity विस्तृत

यह सभी मध्यवर्ती डाउनलोड क्रियाओं को भी आउटपुट करना चाहिए। धन्यवाद!

@maartenba :

आपके द्वारा भेजे गए लिंक पर, "नवीनतम" https://dist.nuget.org/win-x86-commandline/latest/nuget.exe पर इंगित करता है

मैंने रात का पैकेज NuGet.CommandLine.4.0.0-rtm-2254.nupkg डाउनलोड किया, उस पर nuget.exe स्थापित किया, और यह myget.org से फ़ाइलों को खींचने का प्रयास करने में विफल रहा। FYI करें: dotnet.myget.org से 404 वापस करने के लिए 1.5 सेकंड।

यदि यह रात्रि निर्माण या स्थानीय पैकेज स्थापित करने का सही तरीका नहीं है, तो कृपया सूचित करें। यदि आप इसे ऑफ़लाइन लेना चाहते हैं तो आप मुझे इस उपयोगकर्ता नाम पर जीमेल पर ईमेल कर सकते हैं।

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

ps @karelz ... ओह, कोई बात नहीं। :)

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

मैंने अपने आप पर गौर किया है कि myget.org बहुत धीमा है, लेकिन मैं "उचित" समय (सार्वजनिक वाई-फाई नेटवर्क पर) में सफलतापूर्वक प्रश्न में पैकेज स्थापित करने में सक्षम था।

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

हमें निश्चित रूप से समग्र myget.org धीमेपन पर गौर करना चाहिए, लेकिन शायद इस मुद्दे के दायरे से बाहर - यह सब के बाद विशिष्ट ग्राहक परिदृश्य नहीं है। @maartenba जहां चर्चा करने के लिए सबसे अच्छी जगह है?
यहाँ पर (इस विशेष मुद्दे पर), आइए ध्यान दें कि कुछ रचनात्मक वर्कअराउंड का उपयोग करके अंत-टू-एंड सत्यापन को कैसे अनवरोधित किया जाए।
इसके अलावा, मुझे आश्चर्य है कि अगर अन्य लोगों को इतनी बुरी तरह से @chadwackerman के रूप में अवरुद्ध किया गया है, या यदि @chadwackerman का अनुभव दूसरों की तुलना में बहुत बुरा है।

@chadwackerman ने दिया कि यहां मुख्य लक्ष्य एंड-टू-एंड परिदृश्य को मान्य करना है, मुझे आश्चर्य है कि क्या आप अपने परिदृश्य चरण प्रदान कर सकते हैं? यहां कोई दूसरा व्यक्ति (जो myget.org के उपयोग से इतना बुरी तरह से अवरुद्ध नहीं है जितना आप हैं) ऐसे मामले में मान्यता समाप्त कर सकता है। जिससे आपका दर्द कम हो और आपकी तरफ से समय बर्बाद हो। बेशक, यह मानते हुए कि यह आपकी ओर से सस्ते और प्रभावी है।

अंतिम उपाय विकल्प, जिसे मैं बचना चाहता हूं, अपने परिदृश्य सत्यापन को पूरी तरह से छोड़ना है - अगर हमें कुछ अन्य अंत-टू-एंड परिदृश्यों को मान्य किया जाता है, तो हम ठीक-ठीक हो सकते हैं (सबसे खराब स्थिति यह मानते हुए कि @maartenba अपने सुपर-ख़राब myget.org अनुभव का निवारण नहीं कर पाएंगे :()।

चाड के साथ इस ऑफ़लाइन ले जा रहे @karelz , जब हम यह पता लगाएंगे कि क्या चल रहा है, तो हम यहां रिपोर्ट करेंगे।

पृष्ठभूमि के तथ्य:

• myget.org फ़ीड का उपयोग दैनिक बिल्ड, CI, देव-वर्कफ़्लो आदि द्वारा किया जाता है, इसलिए यह दैनिक आधार पर बहुत अधिक अंकित हो जाता है। इन परिशुद्ध समस्याओं में से कोई भी उन परिदृश्यों में प्रकट नहीं होता है (जब वे अतीत में हमने उन पर कार्रवाई की थी, क्योंकि उन्होंने हमारे देवता के वर्कफ़्लो को प्रभावित किया था - हम पिछले कुछ महीनों में 30-60 मिनट सिंक बार <5 मिनट तक लाए थे)। मेरी समझ यह है कि .NET टीम या समुदाय के किसी भी व्यक्ति के लिए VS में myget फीड का उपयोग करना दुर्लभ है - जो IMO बताता है कि खराब परिमाण उस परिदृश्य में क्यों नहीं देखा गया।
• 2016/12/9 को इस मुद्दे पर एक सहकर्मी द्वारा मुझे इस मुद्दे को आगे बढ़ाया गया था - इसीलिए मैं यहां चर्चा में शामिल हुआ। मुझे किसी अन्य आंतरिक वृद्धि के बारे में जानकारी नहीं है। यह देखते हुए कि मैं इस मुद्दे को लगातार कई टीमों (लगभग दैनिक आधार पर) पर आगे बढ़ाता हूं, मुझे लगता है कि मैं इस मुद्दे से संबंधित सभी घटनाओं से अवगत हूं।

@ कर्लेज़ हाँ, मैंने उसी तारीख

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

निश्चित नहीं कि अगर हम इस सूत्र में इस पर चर्चा करते रहें या इसके लिए कोई दूसरा सूत्र खोलें। वैसे भी: स्टेटस रिपोर्ट!

हम ई-मेल के माध्यम से @chadwackerman के साथ संपर्क में हैं - आपके द्वारा भेजे गए लॉग के लिए धन्यवाद चाड!

"सुस्ती" पर - प्रारंभिक रूपरेखा हमें बताती है कि यह पैकेज संस्करणों की संख्या और प्रोटोकॉल डेटा के डाउनलोड आकार पर उस तथ्य के प्रभाव के कारण होता है। उदाहरण के लिए, कुछ संकुल को मेटाडेटा एकत्र करने के लिए 4 एमबी JSON डेटा डाउनलोड करने और पार्स करने की आवश्यकता होती है। यह NuGet क्लाइंट में एक बड़े मेमोरी उपयोग स्पाइक का कारण बनता है और JSON डेटा के एक नाव लोड को पार्स करने की आवश्यकता है - निश्चित रूप से वहां सुधार के लिए जगह है, हालांकि क्लाइंट की 4.0.0 नाइटलाइफ़ बेहतर व्यवहार करती हैं।

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

हम उस पृष्ठ लोड समय को तेज करने पर भी विचार कर रहे हैं (लेकिन यह द्वितीयक है, कार्य को तेजी से स्थापित / पुनर्स्थापित करना प्राथमिकता है)।

प्रयोग के घंटों के बाद मैं Visual Studio को क्रैश किए बिना System.Net.Http 4.4.0-beta-24913-01 में अपग्रेड करने में सक्षम था। मैंने तब 24913-01 से 24913-02 तक अपग्रेड करने की कोशिश की और क्रैश के बजाय एक उचित त्रुटि मिली।

यह 2017 है और "सोमवार के निर्माण" से "मंगलवार के निर्माण" तक पूरे सिस्टम के लिए मुख्य HTTP घटक के रात के निर्माण को अपडेट करने में 8-कोर i7 पर पांच मिनट से अधिक की दीवार घड़ी का समय लगता है और इसके लिए 4GB से अधिक रैम की आवश्यकता होती है।

प्रश्न में परियोजना कोड की 27 लाइनों से मिलकर एक वेबजॉब (एक रीब्रांडेड कमांड लाइन ऐप) है।

दिलचस्प रूप से @karelz बताता है कि यह पूरी .NET टीम के लिए बहुत अच्छा काम करता है और उसे स्थानीय स्टारबक्स से लापरवाही से एक

मैं "उचित" समय में (सार्वजनिक वाई-फाई नेटवर्क पर) सफलतापूर्वक प्रश्न में पैकेज स्थापित करने में सक्षम था।
https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms

यहां कुछ वैकल्पिक तथ्य दिए गए हैं:

पैकेज के लिए निर्भरता की जानकारी इकट्ठा करने का प्रयास 'System.Net.Http.4.4.0-beta-24913-02' के लिए 'webjob' के संबंध में, '.NETFramework, संस्करण = v4.6.1' को लक्षित करना।
निर्भरता की जानकारी प्राप्त करने में 4.22 मिनट लगे
निर्भरता के लिए पैकेज 'System.Net.Http.4.4.0-beta-24913-02' के लिए निर्भरता को हल करने का प्रयास
पैकेज 'System.Net.Http.4.4.0-beta-24913-02' को स्थापित करने के लिए क्रियात्मक समाधान
पैकेज 'System.Net.Http.4.4.0-beta-24913-02' को स्थापित करने के लिए हल किए गए कार्य
System.OutOfMemoryException: 'System.OutOfMemoryException' प्रकार का अपवाद फेंक दिया गया था।
Newtonsoft.Json.Linq.JContainer.ReadContentFrom (JsonReader रैक) पर
Newtonsoft.Json.Linq.JContainer.ReadTokenFrom (JsonReader रीडर) पर
Newtonsoft.Json.Linq.JObject.Load (JsonReader रीडर) पर
NuGet.Protocol.HttpSource पर। <> cb__15_0 (स्ट्रीम स्ट्रीम)

हां, क्या आप लोग इस MyGet / NuGet समस्या को नए मुद्दे पर ले जा सकते हैं? इसका मूल मुद्दे से कोई संबंध नहीं है।

@onovotny - आप अपने मुद्दे को फिर से खोलने पर विचार कर सकते हैं। यह मुद्दा अब सुपर लंबा है, इसलिए इस मुद्दे की उपयोगिता कम कर दी गई है।

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

समुदाय द्वारा रिपोर्ट किए गए सभी ~ 7 एंड-टू-एंड परिदृश्यों का परीक्षण करें (समुदाय से सहायता मांगें, भूल जाने पर मास्टर पैकेजों का उपभोग करने के लिए कदम प्रदान करें)

7 परिदृश्य क्या हैं? क्या हर कोई मदद कर सकता है?

@richlander मुझे एक मुद्दे को खोलने में खुशी होगी, क्या आप मुझे @karelz के अपडेट के साथ

मेरा usecase Azure Storage API के साथ काम कर रहा था, जो पिछली बार 4.0.1-rc2-24027 में काम कर रहा था। ऐसा लग रहा है कि यह अभी काम कर रहा है। मैंने केवल एक त्वरित परीक्षण किया है, क्योंकि MyGet से अपनी परियोजनाओं में सभी पैकेजों को अपडेट करने में लगभग 20 मिनट का समय लगा है।

@onovotny इसे फिर से खोलें नहीं। हमें यहां गति मिली है और हम कम से कम आंशिक संकल्प से इंच दूर हैं। यह धागा अब किसी के लिए भी जुड़ रहा है, लेकिन लंबे समय से चल रहे अन्य अनसुलझे मुद्दों की तरह जो गहरे मुद्दों को उजागर करता है, यह होना ही है। GitHub इस तरह की चीजों के लिए बेकार है।

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

तो हमारे परिदृश्य हैं:

1. एक निर्भर (Raven.Database) पैकेज WebRequestHandler का उपयोग करता है, जो इस समस्या के अनुसार रनटाइम पर टूट रहा था।
2. हमारा कोड नए HttpClientHandler प्रकार और गुणों का उपयोग करता है।

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

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

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

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

20 परियोजनाओं को अद्यतन करने में 6 मिनट 53 सेकंड का समय लगा।

ध्यान दें कि हमारी सभी परियोजनाओं में निम्नलिखित बाइंडिंग रीडायरेक्ट स्वचालित रूप से उत्पन्न हुए थे, मुझे बाध्यकारी रीडायरेक्ट के साथ फिडेल करने की आवश्यकता नहीं थी:

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

उच्च-पित्ती के लिए लगभग समय!

@ जहमाई जब मैंने उस कमांड लाइन का उपयोग किया तो उसने मेरे संदर्भ को 4.0 से 4.2 तक अद्यतन नहीं किया और न ही आवश्यक कॉपी फ़्लैग को जोड़ा। सुनिश्चित करें कि वे System.Net.Http और निर्भरता के लिए सेट किए गए हैं और यह Azure पर ठीक काम करना चाहिए।

हमारा परिदृश्य System.Net.Http के प्रकारों पर सीधा निर्भरता है।
मैंने एक परियोजना पर Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core परीक्षण किया और अब तक यह अच्छी तरह से काम करता है। यह बहुत अच्छी खबर है।
अपडेट यह उल्लेख करना भूल गया कि 4.0.0.0 से 4.2.0.0 तक बाध्यकारी पुनर्निर्देशन स्वचालित रूप से लागू किए गए थे।

Nuget / MyGet मुद्दों के बारे में, मुझे इस एकल प्रोजेक्ट के लिए निम्न आउटपुट मिला:

निर्भरता की जानकारी प्राप्त करने में 37.47 सेकंड लगे
नगेट क्रियाओं को निष्पादित करने में 35.15 सेकंड लगे
समय बीता: 00: 01: 14.7537429

ध्यान दें कि मैं टाइमजोन UTC +01: 00 में हूं, न जाने कब MyGet को सबसे अधिक ट्रैफ़िक मिल रहा है।

@ पॉल्क्स धन्यवाद। हमें समस्या मिली (ऊपर मेरी अंतिम टिप्पणी देखें) - क्लाइंट + सर्वर संयोजन। इसे बेहतर बनाने पर काम किया जा रहा है।

मैं बीटा System.Net का उपयोग करके पुष्टि कर सकता हूं। MyGet से http लाइब्रेरी ने मेरे परिदृश्य के लिए काम किया:

• .NET 4.6 कंसोल अनुप्रयोग जो किसी लायब्रेरी पर निर्भरता के साथ System.Net.Http का उपयोग करता है

माईगेट से डाउनलोड करने के लिए नौगेट पैकेज के लिए लगभग 90 सेकंड का समय लगा था और app.config में बाइंडिंग अप्रत्यक्ष रूप से सही तरीके से लागू किया गया था।

अगर उन्हें कहीं वर्णित किया गया है, तो अधिक परिदृश्यों की मदद करने में मुझे खुशी होगी।

दिलचस्प साइड इफेक्ट: विंडोज-केवल .NET लाइब्रेरी के 4.4.0-बीटा को जोड़ने से लिनक्स पर .NET कोर एप्लिकेशन की तैनाती टूट गई।

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

हां, मैंने इसे कहीं और लॉग किया। और हाँ, यह इस बग से संबंधित है, भले ही आप इसे अभी तक नहीं देखते हैं।

हर कोई हमें परिदृश्यों को सत्यापित करने में मदद करने के लिए धन्यवाद! हमें अब तक 5 पुष्टियां मिलीं - शीर्ष-सबसे पोस्ट में लिंक के साथ विस्तृत सूची देखें। मैं अगले चरणों में जाने के लिए इसे पर्याप्त मान्यता मानता हूं।

• [4.a.ii] मैं अब भी नुगेट विश्लेषण का पीछा कर रहा हूं।
• [५. ए] मैं @davidsh को रिलीज / १.१.० शाखा के खिलाफ पीआर तैयार करने के लिए कहूंगा।

• [५. बी] मैं रिलीज के लिए प्रक्रिया को पूर्व निर्धारित कर रहा हूं (हमें निर्देशक-स्तर की मंजूरी की आवश्यकता है, लेकिन ग्राहकों पर प्रभाव को देखते हुए मुझे किसी भी धक्का की उम्मीद नहीं है)।

• मैं पैच रिलीज के बारे में आधिकारिक जानकारी तैयार कर रहा हूं - सभी तकनीकी ब्रेकिंग परिवर्तन और वर्कआर्ड्स (डेटा के लिए @davidsh के लिए धन्यवाद) की सूची।

यदि किसी को इस बीच (इस विशिष्ट मुद्दे से संबंधित) किसी भी चिंता का पता चलता है, तो कृपया ASAP कहें। उंगलियों को पार कर।

@onovotny - ऐसा लगता है कि यह मुद्दा अब आगे बढ़ रहा है, तो चलिए इस मुद्दे को जारी रखें। यह देखना बहुत अच्छा है कि लोग सकारात्मक प्रगति कर रहे हैं।

@karelz आप मेरे परिदृश्यों की जांच कर सकते हैं जिसमें सर्विसबस निर्भरता के साथ 4.6 कमांड लाइन (एज़्योर वेबजॉब) और एज़्योर बैच पर निर्भरता के साथ 4.6 ऐप शामिल हैं। एडब्ल्यूएस और ड्रॉपबॉक्स पर निर्भरता के साथ एक तीसरा ऐप, जिसे मैंने पहले .NET कोर में स्थानांतरित किया था, बस इस मुद्दे से दूर जाने के लिए (मैंने आज परीक्षण करने के लिए एक पुराना संस्करण खींचा)।

डॉटनेट पुनर्स्थापना समस्या https://github.com/NuGet/Home/issues/2534 पर पुनर्जीवित, योगदानकर्ता वाचा निश्चित बैकचैनल, टायर https://github.com/Azure/azure-storage/issues/372 , MyGet पर लात मारी लॉग भेजे गए, अतिरिक्त प्रदर्शन लॉग https://github.com/dotnet/cli/issues/5328 पर अनुरोध किए गए, और मैंने पोस्टमॉर्टम चर्चा के लिए पॉपकॉर्न का एक बड़ा बैग खरीदा।

आपकी मदद और पुष्टि के लिए @chadwackerman धन्यवाद! आपको मार्ग में हुई परेशानी के लिए क्षमा करें।
मैंने सबसे ऊपर की पोस्ट अपडेट की है।

ऊपर मेरी सूची से:

मैं पैच रिलीज के बारे में आधिकारिक जानकारी तैयार कर रहा हूं - सभी तकनीकी ब्रेकिंग परिवर्तन और वर्कआर्ड्स (डेटा के लिए @davidsh के लिए धन्यवाद) की सूची।

मैंने शीर्ष-सबसे पोस्ट में जानकारी जोड़ दी है - तकनीकी ब्रेकिंग परिवर्तन (4) की सूची के लिए "बदलाव का प्रभाव - ब्रेकिंग परिवर्तन" देखें, प्रत्येक को वर्कअराउंड के साथ।

NuGet पुस्तकालय तकनीकी ब्रेकिंग परिवर्तन (शीर्ष-सबसे पद में वर्णित) से प्रभावित हैं - सौभाग्य से "सिर्फ" 4 NuGet पुस्तकालय जो इन नए APIs में से किसी का उपयोग करते हैं:

System.Private.ServiceModel_4.3.0

• https://www.nuget.org/packages/System.Private.ServiceModel/
• लेखक: डॉटनेटफ्रेमवर्क
• डाउनलोड: 11K (नवीनतम संस्करण) / 800K (कुल)
• विवरण: आंतरिक कार्यान्वयन पैकेज प्रत्यक्ष उपभोग के लिए नहीं था। कृपया सीधे संदर्भ न दें। System.ServiceModel पैकेज का कार्यान्वयन प्रदान करता है।
• टिप्पणियाँ:
• स्थिति: पैकेज प्रभावित नहीं - WCF टीम से @zhenlan @mconnew ने पुष्टि की कि वे केवल .NET कोर बिल्ड में गुणों का उपयोग करते हैं। डेस्कटॉप पर वे अंतर्निहित डेस्कटॉप बायनेरिज़ पर वापस आते हैं।

Consul_0.7.2.1

• https://www.nuget.org/packages/Consul/
• नाम: कौंसुल
• लेखक: https://www.nuget.org/profiles/highlyunavailable
• डाउनलोड: 500 (नवीनतम संस्करण) / 65K (कुल)
• विवरण: https://github.com/PlayFab/consuldotnet/blob/master/CHANGELOG.md
• टिप्पणियाँ:
  
  
  
  • 2 उपयोगों: https://github.com/PlayFab/consuldotnet/search?utf8=%E2%9C%93&q=ServerCertificateCustomValidationCallback
  
  
  • GitHub पर जारी किया गया मुद्दा: https://github.com/PlayFab/consuldotnet/issues/79
  
  
  • लेखक को nuget.org के माध्यम से ईमेल भेजा गया
  
  
• स्थिति: पैकेज प्रभावित नहीं होता है (GitHub मुद्दा https://github.com/PlayFab/consuldotnet/issues/79/)

Octopus.Client_4.6.1

• https://www.nuget.org/packages/Octopus.Client/
• लेखक:
  
  
  
  • https://www.nuget.org/profiles/paulstovell
  
  
  • https://www.nuget.org/profiles/OctopusDeploy
  
  
• डाउनलोड: 250 (नवीनतम संस्करण) / 55K (कुल)
• विवरण: कोई नहीं
• टिप्पणियाँ:
  
  
  
  • GitHub पर दायर मुद्दा: https://github.com/OctopusDeploy/OctopusClients/issues/121
  
  
  • Alias ​​का समर्थन करने के लिए ईमेल भेजा गया: [email protected]
  
  
  • लेखक को nugget.org के माध्यम से ईमेल भेजा गया
  
  
• स्थिति: पैकेज प्रभावित नहीं हुआ (GitHub मुद्दे में विवरण https://github.com/OctopusDeploy/OctopusClients/issues/121)

Geotab.Checkmate.ObjectModel_5.7.1701

• https://www.nuget.org/packages/Geotab.Checkmate.ObjectModel/
• नाम: गीतोत एसडीके
• लेखक: https://www.nuget.org/profiles/neilcawse
• डाउनलोड: 150 (नवीनतम संस्करण) / 10K (कुल)
• विवरण:
  
  
  
  • MyGeotab ग्राहक डेटाबेस तक पहुँचने के लिए SDK लाइब्रेरी
  
  
  • Https://my.geotab.com/sdk/default.html#/whatsNew पर पूरी सूची परिवर्तन
  
  
• टिप्पणियाँ:
  
  
  
  • Nugget.org के माध्यम से लेखक (geotab.com CEO) को ईमेल भेजा गया
  
  
• स्थिति: स्वामी ने संपर्क किया, प्रतिक्रिया पर प्रतीक्षा की

सभी प्रभावित संकुल लेखकों को असुविधा के लिए क्षमा करें।

दृश्य स्टूडियो / NuGet क्रैश / लिनक्स पर स्वैपिंग: इसका कारण यह है कि जिस तरह से NuGet प्रोटोकॉल काम करता है। मैंने इस मुद्दे में निष्कर्ष निकाला है: https://github.com/NuGet/Home/issues/4448

MyGet की ओर से हम सप्ताहांत (वर्तमान में परीक्षण के बाद, उत्पादन में ETA सोमवार 7 फरवरी) के बाद एक बदलाव की तैनाती करेंगे।

MyGet साइड पर फिक्स लाइव है। विजुअल स्टूडियो में ठीक काम करना चाहिए। NuGet.exe का उपयोग करते समय, https://dotnet.myget.org/F/nuget-build/api/v2/package/NuGet.CommandLine (4.0 रात्रिकालीन - 3.5 में एम्बेडेड NuGet.exe का उपयोग करना सुनिश्चित करें। https://github.com/NuGet/Home/issues/4512

इस @maartenba पर गहरे गोता लगाने के लिए धन्यवाद। कभी भी प्रभाव को कम मत समझना यहां तक ​​कि एक मामूली टूलींग फिक्स हो सकता है!

दिलचस्प है कि पूरी .NET टीम विजुअल स्टूडियो क्रैश और NuGet समस्या दोनों को याद कर सकती है।

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

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

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

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

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

Write-Host "Start fixing all app.config"

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

Write-Host "Done"`

उदाहरण का उपयोग करें:
./scripts/FixAppConfig.ps1 -SourceDirectory "--project-path--" -Package "System.Net.Http" -OldVersion "0.0.0.0-4.3.0.0" -NewVersion "4.0.0.0"

यह फिर से कब सार्वजनिक होता है? :)

हमारा परिवर्तन मंगलवार को रिलीज़ / 1.1.0 शाखा में हुआ - पैकेज संस्करण 4.3.1। शाखा के सभी पैकेजों को कल स्थिर करने के लिए फ्लिप किया गया था (स्वतंत्र प्रयास, लेकिन साथ ही साथ हमारी मदद करता है :))।
@davidsh myget फीड (ईटीए: आज) पर विवेक परीक्षण करेगा, फिर हम समुदाय द्वारा यहां एक अंतिम सत्यापन (ईटीए: आज, ईओडी) के लिए कहेंगे। एक बार जब हम उस बिल्ड पर अंतिम सत्यापन कर लेंगे, तो हम पैकेज को NuGet पर धकेल देंगे। मेरी उम्मीद है कि इसमें एक सप्ताह से कम समय लगेगा।

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

यह स्वागत योग्य समाचार है, और netstandard2.0 उपयोग करने के लिए आसान बना देगा।

@davidsh ने रिलीज शाखा से 4.3.1 पैकेज को सत्यापित किया (चेतावनी: मेरे लिए यह बहुत धीमा था - 5 मिनट)
यहाँ मान्य करने के लिए कदम हैं:

कृपया MyGet dev फ़ीड पर नवीनतम पैकेज देखें। आप System.Net.Http.dll पैकेज - 4.3.1 के नवीनतम STABLE (Prerelease) के निर्माण का उपयोग करना चाहते हैं:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

आप अपने NuGet पैकेज स्रोत फ़ीड को कमांड लाइन टूल या विज़ुअल स्टूडियो के साथ बदलकर देव फ़ीड पैकेज का उपयोग कर सकते हैं।

निर्देश:

कमांड लाइन:
के तहत nuget.config में निम्नलिखित जोड़ेंतत्व:

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

दृश्य स्टूडियो:
VS, टूल्स-> Options-> Nuget Package Manager-> पैकेज स्रोत -> स्रोत के अंतर्गत जोड़ें, इस url, https://dotnet.myget.org/F/dotnet-core/api/v3/index.json का उपयोग

या तो मामले में, सुनिश्चित करें कि आप सूची में पहले फ़ीड के रूप में MyGet देव फ़ीड को सूचीबद्ध करते हैं।

[संपादित करें]
अपनी कॉन्फ़िगरेशन फ़ाइल में 4.1.1.0 के लिए बाध्यकारी पुनर्निर्देशन की अपेक्षा करें:

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

मैंने अगले चरणों के साथ शीर्ष पद 'निष्पादन योजना' को अपडेट किया है:

• 5.c अंतिम / अंतिम सत्यापन (अधिकांश) ~ 7 एंड-टू-एंड परिदृश्य - वे लोग जिन्होंने पहले (या किसी और) की मदद की थी, क्या आप एक बार परिदृश्य संक्षिप्त विवरण के साथ सत्यापित करने पर जवाब दे सकते हैं? धन्यवाद! (हम बस पहुँच गए)
  
  
  
  • cc: @ annemartijn0 @karelkrivanek @jahmai @pollax @MikeGoldsmith @chadwackerman @dluxfordhpf @onovotny
  
  
• 5. myget.org पर पैकेज प्रकाशित करें

सत्यापित करने की कोशिश की गई, लेकिन मुझे उस पैकेज को स्थापित करने का प्रयास करने में त्रुटि हो रही है।

जब मैंने अपना सत्यापन किया, तो मैंने इसे एक नए प्रोजेक्ट के साथ किया।

मुझे संदेह है कि "रिड्यूसिंग को अपडेट करने में विफल" के साथ आपको होने वाली त्रुटि पैकेज और असेंबली संस्करणों में डाउनग्रेड के कारण है। आपकी वर्तमान परियोजना [मास्टर] शाखा के पैकेजों पर आधारित प्रतीत होती है। System.Net.Http.4.4। * [मास्टर] शाखा (.NET कोर 2.0 के लिए पूर्व-रिलीज का हिस्सा) से पैकेज नंबरिंग है। यह System.Net.Http के लिए एक असेंबली संस्करण है जो 4.2 है। *।

पैकेज System.Net.Http संस्करण 4.3.1 एक STABLE (पूर्व-रिलीज़ नहीं) पैकेज है और इसे .NET कोर 1.1 सर्विसिंग शाखा (.NET कोर 1.1.1 सर्विसिंग रिलीज़ के साथ संगत) से बनाया गया है। इसमें अलग-अलग असेंबली संस्करण के साथ System.Net.Http dll का एक बाइनरी होता है।

मुझे लगता है कि आपके द्वारा खोजा गया बग तब है जब Visual Studio / NuGet System.Net.Http के परिवर्तित असेंबली संस्करण के लिए आपके बाइंडिंग पुनर्निर्देशन को फिर से लिखने की कोशिश कर रहा है।

तो, आप या तो एक नया नया समाधान / परियोजना बनाने की कोशिश कर सकते हैं। या शायद अपने बाध्यकारी पुनर्निर्देशों को हटा दें और फिर उन्हें वापस रख दें।

FYI करें। मेरे पैकेज से मेरा लॉग इन करें:

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

हम्म, मैं परीक्षण करते समय उलझन में हूं। मैंने ४.३.१ को अद्यतन किया और मेरे वेब.कॉन्फ़िग में निम्नलिखित बाध्यकारी पुनर्निर्देशित किया।

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

अपेक्षित होना?
हो सकता है कि मैंने पहले थ्रेड में कुछ याद किया हो, या शायद यह उन भ्रामक संकुल संस्करण बनाम dll संस्करण मिसमैच स्थितियों में से एक है।
मैंने पैकेज को अनइंस्टॉल भी कर दिया, बाइंडिंग पुनर्निर्देश को हटा दिया और फिर पुनः स्थापित किया और मुझे वही परिणाम मिला।

मेरा मशीन ™ पर काम करना और चलाना।

संयोग से मुझे पूरा यकीन नहीं है कि यह संस्करण 4.4 से गिरकर 4.3.1 हो गया, लेकिन ठीक है।

संस्करण को नंबरिंग में गिरा दिया गया क्योंकि 4.4 संस्करण नवीनतम होगा लेकिन यह अभी भी पूर्व-रिलीज़ है और इसे .NET कोर 2.0 के भाग के रूप में भेज दिया जाएगा। @karelz ने लोगों को पहले उस पैकेज का परीक्षण करने के लिए कहा क्योंकि फिक्स पहले था।

4.3। * पैकेज RTM .NET कोर 1.1 पर आधारित हैं। और उसी की सर्विसिंग रिलीज होगी। तो, उस कोडबेस पर आधारित अद्यतन पैकेज System.Net.Http के लिए 4.3.1 है (चूंकि .NET Core 1.0 पैकेज System.Net.Http के लिए 4.3.0 था।

हो सकता है कि मैंने पहले थ्रेड में कुछ याद किया हो, या शायद यह उन भ्रामक संकुल संस्करण बनाम dll संस्करण मिसमैच स्थितियों में से एक है।

हां, यह भ्रामक है। NuGet पैकेज संस्करण बाइनरी के .NET असेंबली संस्करण के समान नहीं है।

System.Net.Http 4.3.1 NuGet पैकेज के लिए, इसमें System.Net.Http का एक बाइनरी होता है जिसमें 4.1.1.0 असेंबली संस्करण होता है। तो, आप सही परिणाम प्राप्त कर रहे हैं।

अपने अंतिम-से-अंत परिदृश्य (अद्यतन शीर्ष पोस्ट) के सत्यापन के लिए @pollax धन्यवाद।
और अधिक सत्यापन के लिए प्रतीक्षा

मेरी क्षमा याचना जो हम निर्देशों में बाध्यकारी पुनर्निर्देशन से चूक गए (मुझे नहीं पता था कि संभावित GAC'ing के कारण हमें स्वचालित रूप से असेंबली संस्करण टक्कर देगा, लेकिन यह समझ में आता है)।
यह भी क्षमा याचना करता है कि myget आपको myget से सभी पैकेजों में बाध्य करता है - मैं आंतरिक रूप से यह जानने के लिए लोगों के साथ अनुसरण कर रहा हूं कि क्या हमारे पास केवल एक पैकेज को भूल जाने से हड़पने के लिए है। कम से कम भविष्य के सत्यापन के लिए।

@davidsh आप एंड-टू-एंड सत्यापन समन्वय, जबकि मैं OOF हूँ खुश कर सकते हैं? एक बार जब हमारे पास 3 सत्यापन हो जाएं, तो कृपया nuget.org पर पैकेज प्रकाशित करने के लिए @weshaggard से पूछें। धन्यवाद!

हे लोगों,

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

समर्थन लोगों के लिए धन्यवाद और अच्छे काम को बनाए रखें। गलतियाँ होती हैं। इसे ठीक करने के लिए धन्यवाद, मैं समझता हूं कि इसमें समय लगता है।

यहां एक और पुष्टि है कि नया संस्करण समस्या को हल करता है।

हम KeyVault का उपयोग करते हैं, 4.3.1 से टकराकर इस मुद्दे को ठीक किया।

नमस्ते, मुझे सिग्नलआर के साथ यह समस्या है। लेकिन मुझे System.Net.Http 4.3.1 कैसे मिलेगा? मैं केवल 4.3.0 में देखता हूं
https://www.nuget.org/packages/System.Net.Http/

ओह, CoreFx के बारे में संदेश छूट गए - https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

यह मेरे सिग्नलआर मुद्दे को ठीक करता है।

जैसा कि दूसरों ने बताया, फ़ीड सुपर धीमी है। सामान्य नगेट चैनल में 4.3.1 प्राप्त करने का कोई मौका? यह दोपहर 1:30 बजे है और हू .... (8 मिनट डिपो के लिए इंतजार कर रहा है)

पैकेज के लिए 'System.Net.Http.4.3.1' के लिए निर्भरता की जानकारी इकट्ठा करने का प्रयास किया जा रहा है।
निर्भरता की जानकारी प्राप्त करने में 5.85 मिनट लगे
पैकेज 'System.Net.Http.4.3.1' के लिए निर्भरता को हल करने का प्रयास निर्भरता के साथ 'सबसे कम'
मौजूदा पैकेजों में एक या एक से अधिक अनसुलझे पैकेज निर्भरता की कमी का पता लगाया गया है। फाइल फाइल। पैकेजों को जोड़ने या अपडेट करने के लिए सभी निर्भरता की बाधाओं को हल किया जाना चाहिए। यदि इन पैकेजों को अपडेट किया जा रहा है तो इस संदेश को अनदेखा किया जा सकता है, यदि निम्न त्रुटि नहीं है तो वर्तमान पैकेज ऑपरेशन को अवरुद्ध किया जा सकता है: 'System.Net.Http 4.3.0'
निर्भरता जानकारी को हल करने में 0 एमएस लिया गया
पैकेज 'System.Net.Http.4.3.1' को स्थापित करने के लिए क्रियात्मक समाधान
पैकेज 'System.Net.Http.4.3.1' को स्थापित करने के लिए हल किए गए कार्य

'Dict \ Kumquat.Dict.CE.Tests' परियोजना के संबंध में पैकेज 'System.Net.Http.4.3.1' के लिए निर्भरता जानकारी इकट्ठा करने का प्रयास करते हुए, '.NETFramework, संस्करण = v4.6' को लक्षित किया गया
निर्भरता की जानकारी इकट्ठा करने में 3.84 मिनट लगे
पैकेज 'System.Net.Http.4.3.1' के लिए निर्भरता को हल करने का प्रयास निर्भरता के साथ 'सबसे कम'
मौजूदा पैकेजों में एक या एक से अधिक अनसुलझे पैकेज निर्भरता की कमी का पता लगाया गया है। फाइल फाइल। पैकेजों को जोड़ने या अपडेट करने के लिए सभी निर्भरता की बाधाओं को हल किया जाना चाहिए। यदि इन पैकेजों को अपडेट किया जा रहा है तो इस संदेश को अनदेखा किया जा सकता है, यदि निम्न त्रुटि नहीं है तो वर्तमान पैकेज ऑपरेशन को अवरुद्ध किया जा सकता है: 'System.Net.Http 4.3.0'
निर्भरता जानकारी को हल करने में 0 एमएस लिया गया
पैकेज 'System.Net.Http.4.3.1' को स्थापित करने के लिए क्रियात्मक समाधान
पैकेज 'System.Net.Http.4.3.1' को स्थापित करने के लिए हल किए गए कार्य

@karelz Azure Storage API परिदृश्य MyGet से 4.3.1 संस्करण के साथ अमान्य है।

जल्द जवाब नहीं देने के लिए क्षमा करें।

तार पर बहुत अधिक मेटाडेटा जाने के कारण @tofutim सभा निर्भरता धीमी है - https://github.com/NuGet/Home/issues/4448

मुझे लगा कि। किसी भी ETA इसे nuget.org पर प्राप्त करने पर?

@ डेविड डेविड, क्या यह सप्ताह ४.३.१ इसे नुगेट करने के लिए करेगा? मेरे पास एक काफी जटिल परियोजना है और यह महसूस करता है कि परियोजना में पैकेज की संख्या के साथ प्रतीक्षा समय का पैमाना होना चाहिए। फिर भी, फिक्स होना कुछ नहीं से बेहतर है। मुझे लगता है कि मैं कहीं-कहीं नुप किलोग्राम की नकल कर सकता हूं।

पैकेज 'Kumiat.Translate.8.6.2' के लिए निर्भरता संबंधी जानकारी इकट्ठा करने का प्रयास 'qi' प्रोजेक्ट के संबंध में, '.NETFramework, संस्करण = v4.6' को लक्षित करना।
निर्भरता की जानकारी प्राप्त करने में 8.76 मिनट लगे

सबसे हाल ही में 8.76 मि।

@davidsh यह सिर्फ OwlMQ मेलिंग सूची पर पॉप अप हुआ। मैं रिपोर्ट कर सकता हूं कि अद्यतन पैकेज इसे हल करता है।

इसके आगे बढ़ने के लिए टीम को बहुत-बहुत धन्यवाद। अद्भुत कार्य!

पैकेज की सभी मान्यताओं के लिए धन्यवाद।

System.Net.Http 4.3.1 पैकेज को NuGet.org पर प्रमोट किया गया है।

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

हम्म, बहुत विचित्र - रेवेनडीबी ग्राहक अब शिकायत करता है कि यह 4.1.1 विधानसभा नहीं पा सकता है

EDIT: कैविएट - एक्मे.कोर संदर्भ रेवेनडीबी। क्लिएंट और एक्मे। मुख्य संदर्भ एक्मे।कोर। VS2015 निर्भरता के रूप में System.Net.Http की नकल नहीं करेगा लेकिन बाध्यकारी पुनर्निर्देशन वहाँ है -> बूम। क्या यह अपेक्षित व्यवहार है? पाठ्यक्रम के सरल पर्याप्त तय ...

तय किए गए मुद्दे को बंद करना। यहाँ उनके काम के लिए @davidsh और @CIPop को धन्यवाद!
सभी को उनके धैर्य के लिए धन्यवाद। और देरी के लिए हमारी माफी। अगला चरण: पोस्टमार्टम (जैसा कि वादा किया गया है) - कृपया मुझे यहाँ के सभी ऐतिहासिक विवरणों का पता लगाने के लिए ~ 2 सप्ताह का समय दें ...

क्या आप एक नया मुद्दा दर्ज कर सकते हैं और एक

@ कर्लज धन्यवाद!

जानकारी के लिए:

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

@ कर्लज क्विक

@PureKrome मैं निश्चित रूप से इस थ्रेड को अपडेट करूंगा - अधिसूचना पाने के लिए पहले से ही इच्छुक हर किसी के लिए यह आसान है। इसके अलावा मेरा लक्ष्य पोस्टमार्टम को कम करना और इसे लोगों से छिपाना नहीं है।
मैं सबसे अधिक संभावना है कि चर्चा के लिए एक नया मुद्दा बनाऊंगा (जैसा कि मुझे कुछ उम्मीद है) ;-)।
उच्च स्तर पर, मुझे कवर करने की योजना है:

1. कैसे जारी करने के माध्यम से मुद्दा फिसल गया? भविष्य में ऐसी स्थिति को कैसे रोका जाए?
2. इसे ठीक करने में 6 महीने क्यों लगे? पहले उच्च-प्रभाव वाले मुद्दे के रूप में इसका इलाज / संचार क्यों नहीं किया गया? भविष्य में उच्च-प्रभाव वाले मुद्दों को कैसे पहचानें और प्रतिक्रिया करें?
3. अन्य चिंताएँ (जैसे समग्र संचार)

इसके अलावा, अगर हमें 4.3.1 के साथ कुछ टूटा हुआ / सही ढंग से काम नहीं करता है (जैसे @georgiosd ऊपर मिल जाए), तो हमें जागरूकता के लिए इसका उल्लेख करना चाहिए, लेकिन आसान चर्चा के लिए अलग से मुद्दे पर जानकारी लें।

शुक्रिया @karelz (और MS Team)। मैं तो इस धागे के लिए सदस्यता ली जाएगी। 👍

अच्छी लड़ाई लड़ते रहो, टीम! 💯

मुझे @ chadwackerman2 को भी धन्यवाद देना

.NET के इतिहास में सबसे कष्टप्रद बगों में से एक को हल करने के लिए सभी को एक बार फिर बधाई। :)

@ कारेलज़ ऐसा करने से खुश है लेकिन मुझे आश्चर्य है कि क्या यह किसी तरह का अपेक्षित व्यवहार है?

@georgiosd मुझे नहीं पता - अलग-अलग मुद्दे पर इस पर चर्चा करना आसान होगा ;-) (दाएं हाथ में

इस काम को चलाने के लिए धन्यवाद, @karelz

मुझे पता है कि मुझे यहां पोस्टमार्टम करने में देर हो गई है, मेरी माफी।
मैं भूल नहीं गया, मैं अभी तक उच्च प्राथमिकताओं (नियोजन / ट्रैकिंग 2.0) के कारण नहीं मिला, बाध्यकारी पुनर्निर्देश के मुद्दे पर गहराई से देख रहा हूं जो यहां भी सामने आया है - डॉटनेट / रनटाइम # 17770)
मैं अगले 1-2 हफ्तों में पोस्टमार्टम खत्म करने की पूरी कोशिश करूंगा।

नमस्ते, सभी ने इसे हल करने में शामिल किया। खिचड़ी भाषा का कहना है कि मैं सभी नट और बोल्ट को समझता हूं, लेकिन एक बात मुझे अभी भी समझ में नहीं आई है कि यह केवल तब क्यों हुआ जब हमने वीएस 2015 अपडेट 3 से वीएस 2017 तक हमारे समाधान को अपग्रेड किया। प्रश्न में समाधान ASP.Net कोर परियोजनाओं का एक लक्ष्य था .net फ्रेमवर्क 4.6। समस्या Azure KeyVaultClient के हमारे उपयोग से शुरू हो रही थी।

धन्यवाद, डोनल

हाय @karelz , मैं अब तक लगातार दो रात शोध कर रहा हूं और काम कर रहा हूं लेकिन मैं इसे ठीक नहीं कर पा रहा हूं। मेरे सभी System.Net.Http संकुल को 4.3.1 संस्करण में अद्यतन किया गया है लेकिन फिर भी वही त्रुटि मिलती है। कृपया मेरी मदद करें, मुझे नहीं पता कि क्या और कहाँ जाना है। धन्यवाद!

FileNotFoundException: फाइल या असेंबली को लोड नहीं कर सका 'System.Net.Http, संस्करण = 4.1.1.0, संस्कृति = तटस्थ, PublicKeyToken = b03f5f7f11d50a3a'। सिस्टम निर्दिष्ट फाइल का पता लगाने में नाकामयाब रहा।

यहाँ मेरे .csproj

netcoreapp1.1

$ (PackageTargetFallback); पोर्टेबल-net45 + Win8 + wp8 + wpa81;

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

@parismiguel को यह सुनकर खेद है कि :( क्या आपके पास अपने ऐप में 4.0.0.0 से 4.1.1.0 तक बाइंडिंग अप्रत्यक्ष है?

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

हम इस बात की तलाश कर रहे हैं कि कैसे बाइंडिंग अप्रत्यक्ष कहानी को आसान बनाया जाए: https://github.com/dotnet/corefx/issues/9846#issuecomment -287941109

अद्यतन: आपकी त्रुटि को देखते हुए, ऐसा लगता है कि समस्या यह है कि आपका 4.1.1.0 संस्करण नहीं मिला। यदि सही विधानसभा संस्करण सही मायने में है तो क्या आप अपनी ऐप निर्देशिका की जांच कर सकते हैं?

@ कर्लज़ जो तेज़ था, बहुत-बहुत धन्यवाद! मैंने पिछली पोस्टों में बाइंडिंग अप्रत्यक्ष सामान देखा है, लेकिन मुझे यकीन नहीं है कि इसे कहां रखा जाए ... मैंने अपने .csproj के अंदर की कोशिश की है, लेकिन मुझे त्रुटियां मिली हैं (.txt के रूप में) संबंधित संस्करण 4.1.1.0 I एम का पालन करने के लिए निश्चित नहीं हूँ ... मैं इसे 4.3.1 में अपग्रेड करने वाला नहीं हूं?

IbmVcaCore.csproj.txt

बाइंडिंग रीडायरेक्ट आपके app.config या web.config फ़ाइल में जाते हैं:

विवरण के लिए इसे देखें:
https://msdn.microsoft.com/en-us/library/7wd6ex19 (v = vs.110.aspx)

हाय @davidsh , आपकी मदद के लिए धन्यवाद!
मेरी परियोजना के पास उन फ़ाइलों में से कोई भी नहीं है ... इसका एक NET कोर प्रोजेक्ट Visul Studio 2017 टेम्पलेट का उपयोग करके बनाया गया है ... मुझे क्या याद आ रहा है?

पुन :: 4.3.1 बनाम 4.1.1 - 4.3.1 NuGet पैकेज संस्करण है, 4.1.1.0 असेंबली संस्करण है (ildasm / ILSpy / VS इसे आपको दिखाएगा)।
नूगेट बनाम असेंबली के संस्करण थोड़े भ्रमित करने वाले हैं और इसे जोड़ना कठिन है जो किस से संबंधित है। यह मेरी चीजों की सूची पर है कि यदि हम दस्तावेज़ के माध्यम से डॉट्स कनेक्ट कर सकें (जैसे कि नुगेट पृष्ठ पर)।

यदि आप .NET कोर पर हैं, तो आपको बाइंडिंग अप्रत्यक्ष और इसके अतिरिक्त की आवश्यकता नहीं है, यह समस्या आपको बिल्कुल प्रभावित नहीं करती है। यह समस्या डेस्कटॉप (= .NET फ्रेमवर्क) के लिए विशिष्ट है।
4.3.1 NuGet पैकेज ने केवल अपने डेस्कटॉप असेंबली को संशोधित किया, न कि .NET कोर असेंबली को।

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

सभी के लिए : मैंने पोस्टमार्टम का वादा करने के लिए एक नया मुद्दा डॉटनेट / कोरफैक्स # 17522 बनाया है।
अफसोस की बात यह है कि मैंने अभी तक इसकी दिशा में बहुत प्रगति नहीं की है :( ... लेकिन कम से कम हर कोई दिलचस्पी उस मुद्दे का पालन करना शुरू कर सकता है और इस मुद्दे पर संभावित शोर से बच सकता है (लोगों को इस बात पर ध्यान केंद्रित करने में मदद करने के लिए कि वे क्या चाहते हैं)।

@ कर्लज़ धन्यवाद, मैं आपके निर्देशों का पालन करूंगा और आपके ब्रांड के नए अंक ट्रैकर पर पोस्ट करूंगा। सादर।

@parismiguel मेरे द्वारा बनाए गए नए मुद्दे पर नहीं, कृपया एक नया ब्रांड बनाएं। मैंने जो बनाया (# 17522) पोस्टमार्टम विश्लेषण के लिए है कि इस मुद्दे (# 11100) को हल करने में इतना समय क्यों लगा।

इस विषय को गड़बड़ाने के लिए @karelz और मेरी ईमानदार क्षमायाचना का शुक्रिया .... नए निर्देश में कुछ मदद मिलने की उम्मीद है। नमस्कार,

मुझे लगता है कि यह एक आदर्श तूफान के माध्यम से सामना करना पड़ा है।

मैं Azure Key Vault (2.0.6) और ऑक्टोपस क्लाइंट (4.1.3.3) के संयोजन के साथ Azure Functions प्रीव्यू का उपयोग कर रहा हूं।

मैंने System.Net.Http से 4.3.2 लिए अपग्रेड करने का प्रयास किया है, हालांकि Key Vault का उपयोग करने की कोशिश करते समय यह अभी भी विफल रहता है।

कोई सुझाव?

@karelz

क्या आप यह सुनिश्चित कर सकते हैं कि 4.3.2 नगेट पैकेज से असेंबली वास्तव में रनटाइम पर उपयोग की जाती है? (यह 4.3.1 में तय किया गया था)