फ़ाइल या असेंबली लोड नहीं कर सका 'System.Net.Http, संस्करण = 2.0.0.0 MVC4 वेब एपीआई में

92

मुझे थोड़ी अजीब समस्या है।
मैंने MVC 4 और नए वेब एपीआई के साथ एक ऐप विकसित किया है और यह स्थानीय स्तर पर ठीक काम करता है। मैंने सर्वर पर एमवीसी 4 स्थापित किया और ऐप को तैनात किया। अब मुझे निम्नलिखित त्रुटि मिलती है:

फ़ाइल या असेंबली को लोड नहीं किया जा सका 'System.Net.Http, संस्करण = 2.0.0.0, संस्कृति = तटस्थ, PublicKeyToken = 31bf3856ad364e35' या इसकी एक निर्भरता। स्थित असेंबली की प्रकट परिभाषा असेंबली संदर्भ से मेल नहीं खाती है। (HRESULT से अपवाद: 0x80131040)

विवरण: वर्तमान वेब अनुरोध के निष्पादन के दौरान एक अनियंत्रित अपवाद उत्पन्न हुआ। कृपया त्रुटि के बारे में अधिक जानकारी के लिए स्टैक ट्रेस की समीक्षा करें और यह कहां से उत्पन्न हुआ है

काफी मजेदार, System.Net.ttp का संस्करण जो कि मेरे पास स्थानीय रूप से या तो मेरे पैकेज फ़ोल्डर में है या ASP.NET MVC 4 \ Assemblies फ़ोल्डर में 1.0.0.0 है। मैंने वास्तव में अपने प्रोजेक्ट से System.Net.Http का संदर्भ हटा दिया था, लेकिन मुझे अभी भी वही संदेश मिलता है। मैं थोड़ा उलझन में हूं कि इसे 2.0.0.0 संदर्भ कहां से मिलता है और यह स्थानीय रूप से क्यों काम करेगा लेकिन सर्वर पर नहीं।

नगेट निर्भरता को देखते हुए:

ASP.NET WEB एपीआई कोर लाइब्रेरीज़ (बीटा) System.Net.Http.Formatting पर निर्भर करता है।
और System.Net.Http.Formatting System.Net.Http पर निर्भर करता है।
मुझे लगता है कि यह कहाँ से आता है। लेकिन मेरे पास इस पैकेज के संस्करण 2.0.20126.16343 स्थापित हैं, यह सिर्फ इतना है कि dll के अंदर संस्करण 1.0.0.0 है

क्या मैं कुछ भूल रहा हूँ?

अपडेट करें:

यह एक अन्य ASP.NET ऐप का उप-अनुप्रयोग है, लेकिन दूसरा अभी भी WebForms पर आधारित है। तो, कुछ गड़बड़ हो रही है। लेकिन अगर मैं web.config में असेंबली सेक्शन के तहत साफ-सफाई करता हूं, अगर वह ऐप खुद भी नहीं ढूंढता है।

asp.net asp.net-mvc-4 asp.net-web-api

— रेमी
स्रोत

क्या आपने इस परियोजना के लिए "परिनियोज्य निर्भरता जोड़ें" सुविधा का उपयोग किया था?

— क्रिस्टियान

नहीं, ऐसा प्रयास नहीं किया। लेकिन मैंने सब कुछ नए सिरे से सेट किया है और अब यह काम करता है .... वास्तव में संतोषजनक नहीं है, लेकिन ...

— रेमी

मेरे पास यह समस्या है कि मैं हर बार अपनी मशीन को पुनः आरंभ करता हूं और साथ ही दृश्य स्टूडियो को फिर से शुरू करता हूं। किसी तरह मैं दूर चला गया अगर मैं साफ कर दूं और फिर समाधान का निर्माण करूं।

— फ्रॉस्टशॉक्सक्स

30

मुझे अपने ऐप को एप्हारबोर में तैनात करने में एक ही समस्या थी। यह समस्या अभी तक .NET 4.5 का समर्थन नहीं करती है। मैंने क्या किया।

मेरी परियोजना को .NET 4.0 प्रोफ़ाइल पर स्विच किया।
अनइंस्टॉल किया गया वेब एपीआई नुगेट पैकेज।
स्थापित वेब एपीआई (बीटा) NuGet पैकेज फिर से।
सत्यापित कि .csproj फ़ाइल में सभी संदर्भित असेंबली हैं, इसलिए यह हमेशा GAC के बजाय बिन फ़ोल्डर से लेगा।

— अलेक्जेंडर बेलेटस्की
स्रोत

1

किसी तरह मेरी परियोजना ने काम करना शुरू कर दिया, लेकिन मुझे कोई सुराग नहीं मिला कि क्यों ... आपका दृष्टिकोण संभव है।

— रेमी

alexanderb - मैं .NET 4.0 प्रोफ़ाइल में कैसे बदल सकता हूँ। विजुअल स्टूडियो में? बिन फ़ोल्डर कहाँ स्थित है? .Csproj फ़ाइल web.config फ़ाइल है? Thx

— WhoAmI

114

IIS 6.0 पर पहले परिवर्तित (.NET 4.5 से 4.0) वेब ऐप को परिनियोजित करते समय मेरे पास एक ही त्रुटि थी।

Web.config रनटाइम सेक्शन में मैंने पाया है

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

जिसे मैंने बदल दिया है

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

अब आकर्षण की तरह काम करता है।

— Krzysztof
स्रोत

4

क्या इस परिवर्तन के साथ अभी भी असेंबली को स्थानीय कॉपी करने के लिए सेट किया जाना चाहिए?

— रासमस क्रिस्टेंसेन

3

मेरे लिए समस्या यह थी कि मेरे एक वेब एपी नूगेट पैकेज में System.Net.Http 2.0.0.0 पर निर्भरता थी, लेकिन मेरे संदर्भ में मेरे पास 2.1.10.0 था जो मेरे बिन फ़ोल्डर में आउटपुट हो रहा था।

— जस्टिनमिचल्स

2

यह सही है (जैसा कि जस्टिन माइकल्स ने कहा)। निर्भरता 2.0.0.0 को संदर्भित करती है, लेकिन आपका विधानसभा संदर्भ 2.1.xx है। आपको इसे ठीक करने की आवश्यकता है।

— टॉड थॉमसन

2

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

— Blaise

3

समस्या शायद System.Net.Http का प्रत्यक्ष संदर्भ नहीं है, लेकिन एक अप्रत्यक्ष संदर्भ है जो आपके द्वारा संदर्भित अन्य पुस्तकालयों में से एक में उपयोग किया जाता है। इसीलिए कॉपी लोकल सेट करना आम तौर पर इस समस्या को ठीक नहीं करेगा।

— पॉल कीस्टर

10

मेरा साथ काम किया:

1-4 से 2.0 के रीडायरेक्ट पर ध्यान दें

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

— क्लाइव
स्रोत

मैंने कुछ समानताएँ कीं, लेकिन मैंने 4.0V.0 पर नया अपडेट किया और पुराने अनुवाद को 0.0.0.0-2.0.0.0 के रूप में छोड़ दिया

— वेरिटोनिमस

2

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

यह पुस्तकालयों में से एक है जिसे अब नगेट द्वारा प्रबंधित किया जाता है। तो Nuget खोलें और सुनिश्चित करें कि सब कुछ अद्यतित है। और आपके प्रोजेक्ट पैकेज निर्देशिका में फ़ाइल यहाँ होनी चाहिए: \packages\System.Net.Http.2.0.20126.16343\lib\net40

आप एक नया MVC4 ऐप बनाने का भी प्रयास कर सकते हैं और देख सकते हैं कि फ़ाइल उसी के लिए दिखाई देती है या नहीं।

— GeekyMonkey
स्रोत

1

दरअसल, यही मुझे भ्रमित करता है। मैं नगेट का उपयोग करता हूं और मेरे पास यह फ़ोल्डर है। लेकिन अगर मैं System.Net को देखता हूं। इसके लिए इसका संस्करण 1.0.0.0 है

— रेमी

1

यह ठीक है कि मैंने इसे कैसे तय किया! चूंकि यह सब स्थानीय स्तर पर काम करता था। मैंने अभी संदर्भ क्लिक किया है और गुणों में, मैंने सही पर सेट Copy localकिया है जो इसे हल करता है! आसान / बेहतर तो web.config फ़ाइलों में गड़बड़ कर रहा है। बस अपने बिन फ़ोल्डर में dll जोड़ें।

— जेपी हेलिमन्स

2

मेरे मामले में मैंने इसे बहुत आसान तरीके से तय किया, बस नगेट पैकेज के संदर्भ में एक HintPath दें:

     <Reference Include="System.Data.Entity" />
     <Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>
     </Reference>
     <Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>
     </Reference>
     <Reference Include="System.Numerics" />
     <Reference Include="System.Security" />

— knocte
स्रोत

1

मेरे मामले में मैंने अनायास ही NuGet के माध्यम से System.Net.Http संस्करण 2.1.10.0 पर निर्भरता जोड़ दी। मैं इसे NuGet पैकेज मैनेजर में निकाल नहीं सका (क्योंकि अन्य पैकेज इस पर निर्भर लग रहे थे)। हालाँकि वे पैकेज इस विशेष संस्करण पर निर्भर नहीं हैं। यहां मैंने इससे छुटकारा पाने के लिए क्या किया है (आप इसके बजाय NuGet कंसोल का उपयोग कर सकते हैं - -फोर्स पैरामीटर का उपयोग करके):

पैकेज में Microsoft.Net.Http का संस्करण बदलें। 2.1.10.0 से 2.0.0.0 तक कॉन्फ़िगर करें
NuGet पैकेज मैनेजर में BCL पोर्टेबिलिटी पैक को अनइंस्टॉल करें
मैन्युअल रूप से निर्भर पुस्तकालयों से छुटकारा पाएं (System.Net.Http। * जिसका संस्करण 2.1.10.0 है)
System.Net.Http 2.0.0.0 का संदर्भ जोड़ें

— Dunken
स्रोत

1

फ़ाइल कॉन्फ़िगरेशन में मैंने निर्भर असेंबली को हटा दिया:

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

अब यह ठीक काम करता है।

— StefanoM5
स्रोत

XML टैग को ठीक से दिखाने के लिए - अपने पाठ को एक कोड के रूप में प्रारूपित करें। इसके लिए बस प्रत्येक पंक्ति से पहले चार रिक्त स्थान जोड़ें।

— आर्टेमिक्स

Tnx Artemix, यह मेरी पहली टिप्पणी है;)

— StefanoM5

1

मैं एक परीक्षण सर्वर (विंडोज 2008 आर 2) पर इस मुद्दे का सामना कर रहा था जो कि तैनाती के लिए "तैयार" माना जाता था;)

संकेत यह था कि जब मैंने अपने DEV मशीन और परिनियोजन सर्वर के बीच System.net के संस्करणों की जाँच की, तो वे मेल नहीं खाते।

नीचे दिए गए चरणों का उपयोग करके फिक्स्ड:

यहां से .NET फ्रेमवर्क 4.5 स्टैंडअलोन इंस्टॉलर डाउनलोड किया गया
इंस्टॉलर को परिनियोजन मशीन पर चलाएँ

फ्रेमवर्क की स्थापना के बाद, सर्वर रिबूट चाहता था, इसलिए उसने और वोला को! हम जाने के लिए अच्छे हैं !!

— सुधांशु मिश्रा
स्रोत

1

हम वीएस 2013 का उपयोग कर रहे हैं, एक नया एमवीसी 4 वेब एपीआई बनाया गया है और system.net.http.dll के साथ एक समस्या थी जब हमारे टीम सर्वर पर बनाया गया सही संस्करण नहीं है, लेकिन यह वीएस 2013 वाले हमारे स्थानीय डेवलपर मशीनों पर ठीक बनाता है स्थापित।

हमने आखिरकार समस्या का निर्धारण किया।

एक नया MVC 4 वेब एपीआई बनाते समय और प्रोजेक्ट निर्माण पर फ्रेमवर्क 4.0 का चयन करते हुए हमने पाया कि DLL के लिए सही NuGet पैकेज संस्करण को इसमें डाला जा रहा है: .. \ package \ Microsoft.Net.Http.2.0.20710.0 \ lib \ net40 \ System.Net.Http.dll

हालाँकि इस प्रोजेक्ट के लिए .csproj फ़ाइल ने कहा कि इस system.net.http.dll फ़ाइल के लिए पथ है: .. \ पैकेज \ Microsoft.Net.Http.2.0.30506.0 \ lib \ net40 \ System.Net.ttp.ll

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

अब तक यही एकमात्र अंतर है जो हमने पाया है। वीएस .2013 के साथ .csproj फ़ाइल में पथ बदलना और स्थानीय देव मशीन पर निर्माण अभी भी काम करता है।

यह देखते हुए कि संस्करण नियंत्रण में है और हमारे टीमसिटी बिल्ड सर्वर (वीएस 2013 के बिना स्थानीय रूप से स्थापित) के पास अब समाधान के लिए अपने NuGet पैकेज फ़ोल्डर में .dll का सही संस्करण खोजता है और system.net.http के दूसरे संस्करण की खोज करने के बजाय सफलतापूर्वक बनाता है। .dll और एक नया संस्करण ढूंढना जो फ्रेमवर्क से मेल नहीं खाता है इसलिए निर्माण विफलताओं का कारण बनता है।

यकीन नहीं होता अगर यह मदद करता है।

DLL के लिए अपने प्रोजेक्ट फ़ाइल पथ की जाँच करें और सुनिश्चित करें कि यह DLL के लिए आपके पैकेज फ़ोल्डर पथ से मेल खाता है।

— एरिक रीस
स्रोत

1

मेरे लिए जो काम किया उसके लिए अन्य उत्तरों को सरल बनाना।

मैं NuGet प्रबंधक के पास गया, संबंधित पैकेजों की स्थापना रद्द कर दी (मेरे मामले में, "Microsoft ASP.NET वेब API 2.1 क्लाइंट लाइब्रेरी" और "Json.NET") और उन्हें पुनः इंस्टॉल किया। बस कुछ क्लिक लिया।

— रूडी स्कोगिंस
स्रोत

0

प्रोजेक्ट को बंद करें, इसे फिर से खोलें। फिर, क्लीन सॉल्यूशन + बिल्ड। मेरे लिये कार्य करता है

— Lucks
स्रोत

0

संस्करण 2.2.15.0 के लिए, मैंने यह किया:

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

— ओसामा
स्रोत

0

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

— जेवियर गोंजालेज
स्रोत

0

हम तैनाती के बाद एक सर्वर पर यह हो रहा था। यह या तो इसके कारण था:

ए) बिन फ़ोल्डर में पुरानी फाइलें अभी भी हैंग हो गई हैं जिन्हें हटाना चाहिए

या

बी) एप्लिकेशन पूल आइडेंटिटी उपयोगकर्ता के लिए फ़ोल्डर तक पहुंच पढ़ना नहीं।

दूसरे शब्दों में, हमारे लिए यह साइट के लिए फ़ोल्डरों पर अनुमतियों को ठीक करने और बिन फ़ोल्डर को मिटाकर और पुन: उपयोग करके हल किया गया था।

— क्रिस मोसचिनी
स्रोत

0

मैं Gembox.spreadsheet.dll संस्करण 31 के साथ एक ही मुद्दा था।

"फ़ाइल या असेंबली को लोड नहीं किया जा सका 'GemBox.Spreadsheet, Version = 39.3.30.1095, संस्कृति = तटस्थ, PublicKeyToken = b1b72c69714d4847' या इसकी एक निर्भरता। असेंबली की मैनिफ़ेस्ट परिभाषा असेंबली संदर्भ से मेल नहीं खाती है (HRESULT से अपवाद: 0x8013104040) ) "

मैंने इन लेखों से लगभग सब कुछ आज़माया और उनमें से किसी ने भी काम नहीं किया। यह सिर्फ सरल कदम के साथ तय हो गया।

मैंने व्यक्तिगत परियोजनाओं के निर्माण की कोशिश की जो मूल रूप से dll के लिए सही संस्करण संदर्भ सेट करती हैं और त्रुटि पूरी तरह से समाधान से चली गई थी।

— रचना
स्रोत

0

इसी तरह के मुद्दे पर जाएं और कई टिप्पणियों में बताए गए निर्देश ने ठीक काम किया

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

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

— Micael
स्रोत

0

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

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

— mhapps
स्रोत