System.Net.ttp के साथ अजीब समस्या 4.2.0.0 नहीं मिली

Question

मेरे पास एक अजीब मुद्दा है, जो मुझे पागल कर देता है ...

मेरे पास एक साधारण क्लास लाइब्रेरी प्रोजेक्ट (पूर्ण .NET फ्रेमवर्क, 4.6.1) है, जो कॉस्मॉस डीबी के चारों ओर कार्यक्षमता के लिए एक आवरण वर्ग के साथ है। इसलिए मैंने इस परियोजना के लिए "Microsoft.Azure.DocumentDB" NuGet पैकेज 1.19.1 जोड़ा है। इसके अलावा, मेरे पास "Newtonsoft.Json" NuGet पैकेज 10.0.3 के साथ-साथ "Microsoft.Diagnostics.EventFlow। *" "NuGet Package का एक संदर्भ है।

अब तक, सब कुछ बिना किसी त्रुटि के संकलन करता है।

लेकिन जैसे ही मैंने अपने रैपर क्लास को मारा - एक साधारण सेवा फैब्रिक स्टेटलेस सर्विस (पूर्ण .NET फ्रेमवर्क 4.6.1) से भस्म हो गया - और निम्नलिखित कोड कोड निष्पादित करने का प्रयास करें:

_docClient = new DocumentClient(new Uri(cosmosDbEndpointUrl), cosmosDbAuthKey);

मुझे रनटाइम में यह अजीब त्रुटि मिली:

System
। सिस्टम निर्दिष्ट फाइल का पता लगाने में नाकामयाब रहा।
Source = StackTrace: Microsoft.Azure.Documents.Client.DocumentClient.Initialize (Uri serviceEndpoint, ConnectionPolicy कनेक्शन पर क्लिक करें। अतुलनीय, वांछित 1 desiredConsistencyLevel) at Microsoft.Azure.Documents.Client.DocumentClient..ctor(Uri serviceEndpoint, String authKeyOrResourceToken, ConnectionPolicy connectionPolicy, Nullable1 वांछनीयता।

इनर एक्सेप्शन 1: FileNotFoundException: फाइल या असेंबली को लोड नहीं कर सका 'System.Net.Http, वर्जन = 4.0.0.0, कल्चर = न्यूट्रल, PublicKeyToken = b03f5f7f11d50aa' या इसकी एक निर्भरता। सिस्टम निर्दिष्ट फाइल का पता लगाने में नाकामयाब रहा।

मेरे पास कोई सुराग नहीं है, क्यों System.Net.Http असेंबली बिल्कुल नहीं मिली है - यहां तक ​​कि मेरी क्लास लाइब्रेरी प्रोजेक्ट में .Net फ्रेमवर्क असेंबली "System.Net.Http 4.0.0.0" के लिए एक विधानसभा संदर्भ भी है।

जो मुझे समझ में नहीं आ रहा है, वह यह है कि इस अजीब तरह के बंधन को 4.2.0.0 पर पुनर्निर्देशित किया जाता है - वह कहां से आ रहा है? इस एक के आसपास पाने के लिए, मैंने ऐप को निम्नलिखित रीडायरेक्ट में जोड़ने की कोशिश की। सर्विस फैब्रिक सर्विस (जो क्लास लाइब्रेरी का उपभोग कर रही है):

लेकिन अभी भी कोई अंतर नहीं है, मुझे अभी भी रनटाइम पर त्रुटि मिलती है।

किसी को कोई सुराग है? किसी को भी इस तरह के मुद्दे को देखा है?

धन्यवाद और का संबंध है, OliverB

Comments

हाय, ओलिवर! क्या आपको इस समस्या के लिए समाधान मिला? मैं बस एक ही स्थिति का सामना कर रहा हूं और यह एक बुरा सपना है :-(

— user1178399

@ हांसपेसेंट वह लिंक अब टूट गया है

— reggaeguitar

मैं इसका उत्तर देता हूं: stackoverflow.com/a/63031440/330680

— Mahdi

Answer 1

जो समस्या आप सामना कर रहे हैं, वह विज़ुअल स्टूडियो से संबंधित है, विशेष रूप से 2017 के साथ जो इसे शिप किया गया है System.Net.Http v4.2.0.0। हालाँकि, System.Net.Httpन्यूगेट के माध्यम से किसी भी संदर्भ को नया तरीका अपनाना चाहिए, जिसका नवीनतम संस्करण 4.3.3 है जिसमें dll संस्करण 4.1.1.2 है।

समस्या यह है कि वी.एस. बिल्ड टाइम और रन टाइम के साथ-साथ आपके संदर्भ को नजरअंदाज कर देगा और यह DLL के बारे में जानने की कोशिश करेगा।

इसे कैसे जोड़ेंगे:

• सुनिश्चित करें कि System.Net.Http के किसी भी संदर्भ को NuGet के माध्यम से किया जाता है
• समय त्रुटियों का निर्माण करें: System.Net.Http.dll के विस्तार को बदलें (या इसे कहीं और ले जाएं ... मूल रूप से इससे छुटकारा पाएं) जिसे वीएस 2017 के साथ भेज दिया गया है ( c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\); यदि आपको एक अलग संस्करण मिला है, तो मार्ग थोड़ा अलग होगा, हालांकि बहुत अधिक नहीं

• रनटाइम त्रुटियाँ: असेंबली बाइंडिंग पुनर्निर्देशित करें

यदि आप Google पर ऑनलाइन देखते हैं, तो आपको इस बारे में Microsoft के साथ कुछ खुले मुद्दे मिलेंगे, इसलिए उम्मीद है कि वे भविष्य में इसे ठीक कर लेंगे।

उम्मीद है की यह मदद करेगा।

अपडेट करें:

जब बिल्ड एजेंटों पर काम करने के लिए इस मुद्दे के लिए कुछ स्थायी सुधारों को देखते हुए, आपने देखा कि यदि आप नए NuGet PackageReference मॉडल में माइग्रेट करते हैं ( बेहतर .csprojनहीं है packages.config) तो बेहतर काम करता है। इस अपग्रेड को करने के तरीके के बारे में यहां एक लिंक दिया गया है: https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

Comments

ऐसा लगता है जैसे वे net472 github.com/Microsoft/dotnet-framework-early-access/blob/master/… में

— पॉल

बहुत धन्यवाद, पिछले कुछ घंटों से इसे सुलझाने की कोशिश में पागल हो रहा था!

— फ्लिंकमैन

यदि आप .NET 4.7.2 के साथ काम कर रहे हैं, तो वास्तव में बाइंडरिडायरेक्ट को हटाकर समस्या का समाधान किया जा सकता है।

— अल्टरनेटेक्स

4.7.2 में अपग्रेड करते समय आज भी यही समस्या है। System.IO.Compression और System.Runtime भी प्रभावित हुए थे। बाध्यकारी रीडायरेक्ट को हटाने से समस्या हल हो गई।

— जेबी मोनिका के साथ।

हाँ! आखिरकार! 4.7.2 के लिए @Alternatex और JB के अनुसार, बाइंडिंग अप्रत्यक्ष और अब सुनहरा हटा दें। System.Net.Http के लिए आवश्यक नवीनतम गीत और नृत्य दिनचर्या का पता लगाने वाले हर फ्रेमवर्क अपडेट के लिए क्या दर्द है।

— टेड

Answer 2

मेरे लिए काम कर रहे बाध्यकारी पुनर्निर्देशन को हटाना, आप इसे हटाने की कोशिश कर सकते हैं:

<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />

Comments

यह उन 1 चीजों में से एक थी, जिन्हें मैंने आजमाया, लेकिन सफलता के बिना

— ओलिवर बी

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

— एडू

क्या यह पूर्ण कोडलाइन है? और वास्तव में इसे कहाँ जोड़ा जाना है? मेरे सभी अन्य बाइंडिंग अप्रत्यक्ष टैगdependentAssembly

— फ़्लो

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

— स्कूटर

धन्यवाद। इस पर 2 दिन से मुद्दे पर बनी हुई है। इसने काम कर दिया !!!

— सागर खत्री

Answer 3

@AndreiU पहले से ही दिए गए उत्तर के अलावा और स्थानीय स्तर पर रनटाइम त्रुटियों को कैसे पुन: पेश करें।

मुझे एज़्योर को तैनात करते समय नीचे रनटाइम त्रुटि मिली, स्थानीय रूप से नहीं।

फ़ाइल या असेंबली को लोड नहीं किया जा सका 'System.Net.Http, संस्करण = 4.2.0.0, संस्कृति = तटस्थ, PublicKeyToken = b03f5f7f11d50a3a' या इसकी एक निर्भरता। सिस्टम फ़ाइल निर्दिष्ट नहीं कर सकता। "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" Company.Project.Service.CompanyIntegrationApiS..ctor (Uri baseAddress) \ r \ n में Company.Project पर। .BackOffice.Web.Controllers.OrderController..ctor () C में: \ प्रोजेक्ट \ कंपनी-प्रोजेक्ट \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ Order \ontontroller.cs: लाइन 30 \ r \ n lambda_method पर () सिस्टम पर बंद करें। \ r \ n System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (HttpRequestMessage अनुरोध, HttpControllerDescripter नियंत्रक डेसिस्क्रिप्ट, टाइप कंट्रोलर) "}} संस्कृति = तटस्थ, PublicKeyToken = b03f5f7f11d50a3a 'या इसकी निर्भरता में से एक। सिस्टम फ़ाइल निर्दिष्ट नहीं कर सकता। "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" Company.Project.Service.CompanyIntegrationApiS..ctor (Uri baseAddress) \ r \ n में Company.Project पर। .BackOffice.Web.Controllers.OrderController..ctor () C में: \ प्रोजेक्ट \ कंपनी-प्रोजेक्ट \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ Order \ontontroller.cs: लाइन 30 \ r \ n lambda_method पर () सिस्टम पर बंद करें। \ r \ n System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (HttpRequestMessage अनुरोध, HttpControllerDescripter नियंत्रक डेसिस्क्रिप्ट, टाइप कंट्रोलर) "}} संस्कृति = तटस्थ, PublicKeyToken = b03f5f7f11d50a3a 'या इसकी निर्भरता में से एक। सिस्टम फ़ाइल निर्दिष्ट नहीं कर सकता। "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" Company.Project.Service.CompanyIntegrationApiS..ctor (Uri baseAddress) \ r \ n में Company.Project पर। .BackOffice.Web.Controllers.OrderController..ctor () C में: \ प्रोजेक्ट \ कंपनी-प्रोजेक्ट \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ Order \ontontroller.cs: लाइन 30 \ r \ n lambda_method पर () सिस्टम पर बंद करें। \ r \ n System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (HttpRequestMessage अनुरोध, HttpControllerDescripter नियंत्रक डेसिस्क्रिप्ट, टाइप कंट्रोलर) "}}

जब मैंने विधानसभाओं को देखना शुरू किया तो मैं देख सकता था कि मेरी वेब परियोजना और सेवा परियोजना ने विभिन्न संस्करणों को लक्षित किया है System.Net.Http ।

वेब परियोजना:

सेवा परियोजना:

यह सोचना आसान है कि यह संस्करणों में एक बेमेल के कारण होता है, लेकिन यहां कुंजी त्रुटि को देखने के लिए है The system cannot find the file specified. ।

पथ प्रॉपर्टी को देखते हुए हम देख सकते हैं कि वेब प्रोजेक्ट एक .Net फ्रेमवर्क असेंबली को लक्षित करता है जबकि सेवा विज़ुअल स्टूडियो 2017 से असेंबली को लक्षित करती है। चूंकि सर्वर में विजुअल स्टूडियो 2017 स्थापित नहीं है, इसलिए रनटाइम त्रुटि होगी।

वेब पथ:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Net.Http.dll

सेवा पथ:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll

की स्थापना के रूप में सरल रूप में कुछ Copy Localकरने के लिए trueसभी मामलों में इस समस्या को ठीक कर सकते हैं, फिर भी नहीं।

अपने स्थानीय मशीन पर त्रुटि को पुन: उत्पन्न करने के लिए, केवल System.Net.Http.dllVisual Studio विशिष्ट फ़ोल्डर से आवश्यक निकालें । यह आपको रनटाइम एरर देगा और शायद कुछ बिल्ड एरर भी। ये तय होने के बाद कि सब कुछ काम करना चाहिए, कम से कम यह मेरे लिए था।

यदि आपने चेक के System.Net.Httpमाध्यम से स्थापित NuGetकिया है कि .csprojसंस्करण को देखकर किस विधानसभा का उपयोग किया जाता है । System.Net.Http 4.3.4उदाहरण के लिए निम्नलिखित विधानसभा देता है:

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
  <HintPath>..\packages\System.Net.Http.4.3.4\lib\net46\System.Net.Http.dll</HintPath>
  <Private>True</Private>
  <Private>True</Private>
</Reference>

यदि आप Jenkins, TeamCity या AppVeyor जैसे बिल्ड सर्वर का उपयोग करते हैं तो रनटाइम लापता .dllभी वहां मौजूद हो सकता है। इस स्थिति में यह System.Net.Http के NuGet संस्करण का उपयोग करने में मदद नहीं कर सकता है या .dllस्थानीय रूप से लापता को हटा सकता है । इस त्रुटि को हल करने के लिए उस संस्करण को देखें जो विशिष्ट नहीं है और विशिष्ट है PublicKeyToken। उसके बाद Web.configया तो App.configअपनी परियोजना के आधार पर या तो एक बाध्यकारी रीडायरेक्ट बनाएं । मेरे मामले में मैं इसके बजाय 4.0.0.0 का उपयोग करना चाहूंगा:

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

इस मुद्दे के बारे में एक अच्छा गितुब सूत्र:

https://github.com/dotnet/corefx/issues/22781

Comments

<आश्रितों को जोड़ना> <विधानसभाता नाम = "System.Net.Http" ....... कार्य मुझे बनाता है। धन्यवाद

— रोमियो

मेरे लिए भी! वर्कअराउंड के लिए धन्यवाद! OldVersion = "0.0.0.0-4.2.0.0" newVersion = "4.1.1.3" जब से मैं 4.1.1.3 का उपयोग कर रहा हूं

— Pavel Yermalovich

4.0.0.0 पर रीडायरेक्ट है जो मुझे शीर्ष पर रखता है। धन्यवाद!

— जिम जी।

नीचे पुनर्निर्देशित करना खतरनाक है! आपके पास अपनी परियोजना में एक निर्भरता है, यह संकेत देता है कि यह 4.2 का उपयोग करता है लेकिन आप इसे 4.0 का उपयोग करने के लिए मजबूर करते हैं। यदि यह किसी भी नए गुण या विधि का उपयोग कर रहा है तो पद 4.0 प्रस्तुत किया गया है, आपको समय की भविष्यवाणी करने में मुश्किल समय पर विफलता मिलेगी।

— डेविड बर्ग

गिथब धागे का लिंक मृत है। लेकिन निम्नलिखित सूत्र में संबंधित चर्चा शामिल है: github.com/dotnet/runtime/issues/24382

— Hermann.Gruber

Answer 4

मैंने सिर्फ System.Net.HttpNuGet का उपयोग करके इंस्टॉल किया है । आप इसे यहाँ ले सकते हैं:

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

ASP.NET MVCमैं जिस प्रोजेक्ट पर काम कर रहा हूं, वह निशाने पर है .NET 4.6.1। IIS Expressविजुअल स्टूडियो 2019 के साथ डिबगिंग करते समय यह मेरी मशीन पर पूरी तरह से काम करता है ।

समस्या तब हुई जब एज़्योर को तैनात किए गए एप्लिकेशन को चलाने का प्रयास किया गया। मुझे यह त्रुटि मिल रही थी:

फ़ाइल या असेंबली को लोड नहीं किया जा सका 'System.Net.Http, संस्करण = 4.2.0.0, संस्कृति = तटस्थ, PublicKeyToken = b03f5f7f11d50a3a' या इसकी एक निर्भरता।

क्या वास्तव में मेरे मामले में काम किया है .csproj फ़ाइल खोल रहा था और System.Net.Httpनिम्न स्क्रीनशॉट की तरह खोज रहा था ...

देखें कि .csprojफ़ाइल का संस्करण है 4.1.1.3:

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">

<HintPath>वास्तव में करने के लिए अंक ..\packagesNuget, यह है कि से फ़ोल्डर, यह असली संस्करण Nuget द्वारा स्थापित है। एक बार इस विशिष्ट संस्करण को तैनात करने के बाद सर्वर की तरफ भी बहाल हो जाएगा और सब कुछ एक बाइंड रीडायरेक्ट के साथ काम करना चाहिए।

... और इसलिए बाध्यकारी पुनर्निर्देशन को इस Web.configतरह इस विशिष्ट संस्करण का उल्लेख करना चाहिए :

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

यह मेरे मामले में कुछ हद तक Azure Kudu के आने के बाद तय हुआ । Azure वेब साइट आखिरकार बिना किसी त्रुटि के शुरू हुई।

Answer 5

मैंने इस मुद्दे को ठीक करने के लिए web.config से सभी बाइंडिंग को हटा दिया था और ए

Update-Package -reinstall

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

Answer 6

मुझे इस त्रुटि का सामना करना पड़ा जब मैंने हमारे सर्वर में से एक को एक वेब सेवा तैनात की। परियोजना ने .Net फ्रेमवर्क 4.7.2 को लक्षित किया, जो सर्वर पर स्थापित नहीं था। सर्वर पर 4.7.2 फ्रेमवर्क को स्थापित करने से समस्या ठीक हो गई।

Comments

यह मेरा मुद्दा भी था। यह अन्य संस्करणों के लिए भी एक reoccurring विषय है।

— जेसन गीगर

Answer 7

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

यह एक रनटाइम त्रुटि थी (बिल्ड समय नहीं), जहां बिल्ड सफल हुआ, लेकिन सर्वर नहीं बल्कि एक कंप्यूटर पर काम करेगा। समाधान: - जोड़ा गया System.Net.Http पैकेज। फ़ाइल का नाम बदलें: C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v4.7.2 \ System.Net.Http.dll (जैसे का नाम बदलें: System.Net.Http.dll.BAK) पर सर्वर का निर्माण।

मेरे पास नहीं था और अभी भी इस dll के लिए असेंबली रीडायरेक्ट नहीं है

Answer 8

एक सरल समाधान मैंने पाया कि वेब परियोजना के लिए लक्ष्य ढांचे को 4.6 तक नीचे कर दिया है।

मैं क्लाइंट और वेब एप्लिकेशन बनाता हूं, क्लाइंट के पास .net फ्रेमवर्क 4.7.1 और वेब एक ही है और मैं एक ही मुद्दे का सामना कर रहा हूं, जब डाउनग्रेड लक्ष्य। वेब के लिए फ्रेमवर्क यह मेरे लिए काम करता है।

Answer 9

कुछ दिनों तक इससे जूझने के बाद आखिरकार मुझे .Net 4.7.2 / System.Net.ttp प्रॉब्लम मेरे प्रोजेक्ट के लिए तय हुई। फ्रेमवर्क संस्करण ४.२.२ को लक्षित करने के लिए * .csproj फ़ाइल को बदलने के अलावा, मुझे प्रोजेक्ट्स को भी अपडेट करना पड़ा।

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />

सेवा:

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />

Answer 10

मुझे भी यही समस्या थी। अंत में मैंने इसे कुछ इस तरह से Deploy-FabricApplication.ps1 में बदलकर हल किया

$binFolder = "$LocalFolder\..\..\..\..\Bin"

$httpDllLocation = "$binFolder\System.Net.Http.dll"
$codeFolder = "$ApplicationPackagePath\[ProjectName].ServicesPkg\Code"
$configFile = "$codeFolder\[ProjectName].Services.exe.config"

Copy-Item $httpDllLocation -Destination $codeFolder 

$appConfig = [xml](cat $configFile)
$appConfig.configuration.runtime.assemblyBinding.dependentAssembly | foreach {

    $name = $_.assemblyIdentity.name
    #Write $name
    if($name -eq 'System.Net.Http')
    {
        Write 'System.Net.Http changed'

        $_.bindingRedirect.newVersion = '4.2.0.0'
    }
}
$appConfig.Save($configFile)

मुझे एक 4.2.0.0 System.Net.Http.dll मिला जो x64 है। इस स्क्रिप्ट को परिनियोजित करने से पहले dll को संकुल निर्देशिका में कॉपी करता है और इस फ़ाइल का स्पष्ट रूप से उपयोग करने के लिए विन्यास फाइल को बदलता है। मैंने http://gertjanvanmontfoort.blogspot.nl/2017/11/systemnethttp-dll-version-problems.html पर अपने System.Net.Http समस्याओं के बारे में एक ब्लॉग भी लिखा था

अपने प्रोजेक्ट के नाम के साथ [ProjectName] को बदलना न भूलें

आशा है कि यह मदद करता है, पूछने के लिए स्वतंत्र महसूस करता है

Answer 11

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

मेरे पास एक छोटी सी लाइब्रेरी थी जिसका उपयोग डॉटनेट सीबीआर 2.0 का उपयोग कर किया गया था और मुख्य परियोजना डब्ल्यूसीएफ परियोजना थी जो सामान्य .NET पर आधारित है (मेरा विशेष रूप से v4.6.1 था)। लेकिन डॉटनेट फ्रेड लाइब्रेरी के स्टार्टअप क्लास में मेरा कुछ कोड था जो इस तरह दिखता था:

public static class CoreModule
{
    public static IServiceCollection AddStaticDataConfiguration(
        this IServiceCollection services, Func<IServiceProvider, IStaticDataConfiguration>  staticDataConfiguration) 
    {  
        services.TryAddSingleton(staticDataConfiguration);
        services.TryAddSingleton<Func<HttpClient>>(x =>
        {
            var configuration = staticDataConfiguration(x);

            return configuration.ClientResolver ?? (() => new HttpClient());
        });
        return services;
    }
}

IStaticDataConfiguration इंटरफ़ेस नीचे जैसा दिखता है:

public interface IStaticDataConfiguration
{
    //..... some stuff

    Func<HttpClient> ClientResolver { get; set; }
}  

यह इंटरफ़ेस डॉटनेट फ्रेड लाइब्रेरी के अंदर रहता है, जबकि कार्यान्वयन इसके बाहर है (इसके WCF प्रोजेक्ट में स्थित है)।

लाइब्रेरी के बाहर से मैं AddStaticDataConfigurationनीचे की तरह विधि बुला रहा था :

serviceCollection.AddStaticDataConfiguration(p =>
{
    var staticDataConfig = p.GetService<IStaticDataConfiguration>();
    return new StaticDataProviderConfiguration
    {
        //...some other stuff
        ClientResolver = () => restRequestFactory.GetInstrumentedClient("StaticDataService") //this returns an HttpClient
    };
});

समस्या यह है कि मैं Func<HttpClient>एक सामान्य .NET प्रोजेक्ट से एक डॉटनेट सीबीआर लाइब्रेरी को पारित कर रहा हूं जो कि कुछ पागल कारण के लिए डॉटनेट सीएक्स पसंद नहीं करता है और शायद यह सोचता HttpClientहै कि विभिन्न वर्गों से आ रहा है, परिणामस्वरूप System.Net.Http 4.x.x.xअपवाद नहीं मिला। जब HttpClientएक सामान्य .NET प्रोजेक्ट से स्वीकार नहीं करने के लिए कोड को हटा दिया जाता है, लेकिन funcलाइब्रेरी के अंदर एक नया निर्माण करके अपने खुश और ठीक काम करता है। आशा है कि यह किसी और की मदद कर सकता है क्योंकि यह त्रुटि इतने कारणों से हो रही है :)

Answer 12

मेरा समाधान @ रकीब के समान था। मेरी परियोजना 4.7.2 थी और मेरे पीसी पर ठीक काम किया। जब भी मैं अपने देव सर्वर पर तैनात होता तो मुझे प्रश्न में उल्लिखित मुद्दा मिलता। सर्वर पर उच्चतम .net संस्करण को बाहर किया गया था 4.6.1। मेरी परियोजना को 4.6.1 पर अपग्रेड करना समस्या को निर्धारित करता है। सर्वर के .net संस्करण को अपग्रेड करना मेरे लिए कोई विकल्प नहीं था।

Answer 13

मेरा मानना ​​है कि उत्तर का हिस्सा माइक्रोसॉफ्ट के प्रलेखन में पाया जा सकता है ।

जब आप .NET फ्रेमवर्क 4.5.1 या बाद के संस्करण को लक्षित करने वाले विज़ुअल स्टूडियो में एक डेस्कटॉप ऐप बनाते हैं, तो ऐप स्वचालित बाइंडिंग पुनर्निर्देशन का उपयोग करता है।

@Vivek Sharma का उत्तर बताते हुए, हटाया गया:

<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />

मेरे ऐप में 3 ऐसे मामलों में समस्या हल हो गई। जब आप Powershell के साथ DLL की जांच करते हैं, उदाहरण के लिए:

 ([system.reflection.assembly]::loadfile("C:\MyApp\bin\System.Net.Sockets.dll")).FullName

आउटपुट

System.Net.Sockets, संस्करण = 4.0.0.0

स्पष्ट रूप से एक बाध्यकारी पुनर्निर्देशन 4.2.0.0काम नहीं करने वाला है क्योंकि हम 4.0.0.0बिन में आउटपुट कर रहे हैं ।

यह देखने के लिए भी GAC जाँचने योग्य है कि क्या वहाँ से विधानसभा भी गायब है:

 gacutil -l System.Net.Sockets

मेरे मामले में जीएसी से विशेष संस्करण भी गायब था। अगर DLL GAC में था तो इसे असेंबली बाइंडिंग प्रक्रिया में पाया जाना चाहिए था ।

Answer 14

पहले अपने स्थानीय फाइल सिस्टम से हटाएं:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\Syste.Net.Http.dll

फिर परियोजनाओं में सभी संदर्भों को हटा दें और, 4.0 संदर्भ जोड़ें।
इससे मेरी समस्या हल हो गई।

Comments

ओह माय नो, कृपया अपनी कुछ फ़ाइलों को हटाकर वीएस की अपनी स्थापना को भ्रष्ट न करें।

— डेविड बर्ग