स्थित विधानसभा के प्रदर्शन में परिभाषा से मेल नहीं खाता विधानसभा संदर्भ

Question

मैं एक सी # Windows में कुछ इकाई परीक्षण चलाने के लिए कोशिश कर रहा हूँ आवेदन (विजुअल स्टूडियो 2005) फॉर्म्स, और मैं निम्नलिखित त्रुटि मिलती है:

System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.200, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)**

at x.Foo.FooGO()

at x.Foo.Foo2(String groupName_) in Foo.cs:line 123

at x.Foo.UnitTests.FooTests.TestFoo() in FooTests.cs:line 98**

System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.203, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

मैं देखो मेरे संदर्भ में, और मेरे पास केवल Utility version 1.2.0.203 का संदर्भ है (दूसरा पुराना है)।

इस डीएलएल फ़ाइल के इस पुराने संस्करण को संदर्भित करने का प्रयास करने के तरीके के बारे में कोई सुझाव क्या है?

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

Answer 1

.NET असेंबली लोडर 1.2.0.203 को खोजने में असमर्थ है, लेकिन 1.2.0.200 मिला। यह असेंबली जो अनुरोध किया गया था उससे मेल नहीं खाता है और इसलिए आपको यह त्रुटि मिलती है। सरल शब्दों में, यह संदर्भित असेंबली नहीं मिल सकता है। सुनिश्चित करें कि यह इसे जीएसी में या एप्लिकेशन पथ में डालकर सही असेंबली पा सकता है। http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx भी देखें।

Answer 2

आप इस समस्या का निवारण करने के लिए कुछ चीजें कर सकते हैं। सबसे पहले, अपनी असेंबली (.dll) के लिए अपनी हार्ड ड्राइव खोजने के लिए विंडोज फ़ाइल खोज का उपयोग करें। एक बार आपके पास परिणामों की एक सूची हो जाने के बाद, देखें-> विवरण चुनें ... और फिर "फ़ाइल संस्करण" की जांच करें। यह परिणाम की सूची में संस्करण संख्या प्रदर्शित करेगा, ताकि आप देख सकें कि पुराना संस्करण कहां से आ रहा है।

इसके अलावा, लार्स ने कहा, यह देखने के लिए कि आपका संस्करण किस संस्करण में सूचीबद्ध है, अपने जीएसी की जांच करें। This Microsoft article बताता है कि जीएसी में मिली असेंबली को बिल्ड के दौरान स्थानीय रूप से कॉपी नहीं किया जाता है, इसलिए आपको पुनर्निर्माण करने से पहले पुराने संस्करण को हटाने की आवश्यकता हो सकती है।

आप अभी भी समझ नहीं कर सकते हैं, जहां पुराने संस्करण से आ रहा है (एक बैच फ़ाइल बनाने आप के लिए यह करने के लिए पर नोट्स के लिए this question को मेरा उत्तर देखें), तो आपको fuslogvw.exe अनुप्रयोग का उपयोग कर सकते हैं कि साथ जहाजों बाइंडिंग विफलताओं के बारे में अधिक जानकारी प्राप्त करने के लिए विजुअल स्टूडियो। माइक्रोसॉफ्ट के पास इस उपकरण here के बारे में जानकारी है। ध्यान दें कि आपको HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog रजिस्ट्री कुंजी को

Answer 3

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

Answer 4

मैं बस इस समस्या में खुद भाग गया, और मैंने पाया कि यह मुद्दा दूसरों के साथ चलने से कुछ अलग था।

मेरे पास दो डीएलएल थे जो मेरा मुख्य प्रोजेक्ट संदर्भित कर रहा था: CompanyClasses.dll और CompanyControls.dll। मैं एक रन-टाइम त्रुटि कहावत हो रही थी:

Could not load file or assembly 'CompanyClasses, Version=1.4.1.0, Culture=neutral, PublicKeyToken=045746ba8544160c' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference

मुसीबत, था मैं 1.4.1 का एक संस्करण संख्या के साथ अपने सिस्टम पर किसी भी CompanyClasses.dll फ़ाइलें नहीं था। जीएसी में कोई नहीं, ऐप फ़ोल्डरों में से कोई नहीं ... कहीं भी नहीं। मैंने अपनी पूरी हार्ड ड्राइव की खोज की। मेरे पास सभी कंपनीClasses.dll फ़ाइलें 1.4.2 थीं।

वास्तविक समस्या, मैंने पाया, कंपनीControls.dll ने CompanyClasses.dll के संस्करण 1.4.1 का संदर्भ दिया था। मैंने अभी CompanyControls.dll को पुन: संकलित किया है (इसे संदर्भ देने के बाद CompanyClasses.dll 1.4.2) और यह त्रुटि मेरे लिए चली गई।

Answer 5

हमारे लिए, समस्या किसी और चीज के कारण हुई थी। DevExpress घटकों के लिए लाइसेंस फ़ाइल में दो पंक्तियां शामिल थीं, एक ऐसे घटकों के पुराने संस्करण के लिए जो इस विशेष कंप्यूटर पर स्थापित नहीं थीं।लाइसेंस फ़ाइल से पुराने संस्करण को हटाने से समस्या हल हो गई।

कष्टप्रद हिस्सा यह है कि त्रुटि संदेश ने कोई संदर्भ नहीं दिया कि संदर्भ किस समस्या का कारण बन रहा था।

Answer 6

वैश्विक असेंबली कैश में जो कुछ भी गुम है उसे जोड़ने का प्रयास करें।

Answer 7

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

Answer 8

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

त्रुटि को हल करने के लिए आपको सही सार्वजनिक कुंजी टोकन (आप इसे डीएल पर स्न-टी का उपयोग करके प्राप्त कर सकते हैं) जोड़ना होगा। उम्मीद है की यह मदद करेगा।

Answer 9

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

अंतिम परिणाम: प्रत्यक्ष संदर्भ (1) और अप्रत्यक्ष संदर्भ (2) क्लाइंट मशीन पर बदले गए डीएल के विभिन्न संस्करणों को इंगित कर रहे थे। मेरी देव मशीन पर यह ठीक काम किया।

संकल्प: आवेदन निकालें; एप्लिकेशन फ़ोल्डर से सभी डीएलएलएस हटाएं; पुन: इंस्टॉल करें। मेरे मामले में उतना ही सरल।

Answer 10

सत्य में वीएस सेट "विशिष्ट संस्करण" संपत्ति में संदर्भ पर राइट क्लिक करें।

Answer 11

मेरे मामले में यह सी: \ विन्डोज़ \ Microsoft.NET \ Framework \ ~ \ अस्थायी ASP.NET फ़ाइलें \ निर्देशिका में DLL का पुराना संस्करण था। आप पुराने संस्करण को हटा या बदल सकते हैं, या आप अपने प्रोजेक्ट में डीएलएल के संदर्भ को हटा सकते हैं और वापस जोड़ सकते हैं। असल में, किसी भी तरह से अस्थायी ASP.NET फ़ाइलों को एक नया सूचक बना देगा।

Answer 12

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

यह संकलित है लेकिन यह वर्तमान परियोजना असेंबली के साथ संदर्भित असेंबली को ओवरराइट करता है - इस प्रकार त्रुटि उत्पन्न करता है।

इसे ठीक करने के लिए मैंने प्रोजेक्ट का नाम बदल दिया, और परियोजना पर राइट-क्लिक करके और 'गुण' चुनकर उपलब्ध असेंबली गुणों को बदल दिया।

Answer 13

मैं किसी को अपनी कतरनी मूर्खता से लाभ दूंगा। मेरे पास पूरी तरह से अलग एप्लिकेशन के लिए कुछ निर्भरताएं हैं (चलो इस ऐप 1 को कॉल करें)। उस ऐप 1 से डीएलएल को मेरे नए एप्लिकेशन (ऐप 2) में खींचा जाता है। जब भी मैं APP1 में अपडेट करता हूं, मुझे नया डीएलएल बनाना होगा और उन्हें ऐप 2 में कॉपी करना होगा। कुंआ। । मैं 2 अलग-अलग ऐप 1 संस्करणों के बीच प्रतिलिपि बनाने और चिपकाने से थक गया, इसलिए मैंने बस डीएल के लिए 'NEW_' उपसर्ग जोड़ा।

ठीक है। । । मैं अनुमान लगा रहा हूं कि बिल्ड प्रक्रिया/bin फ़ोल्डर स्कैन करती है और जब यह गलत तरीके से कुछ मेल खाती है, तो यह उपरोक्त जैसा त्रुटि संदेश के साथ बारफ करता है। मैंने अपने "new_" संस्करणों को हटा दिया और यह सिर्फ बेवकूफ बनाया गया।

Answer 14

मेरा मुद्दा किसी भी संदर्भित असेंबली को खींचने के बिना स्रोत कोड को नई मशीन पर कॉपी कर रहा था।

कुछ भी नहीं जो मैंने त्रुटि को ठीक किया है, इसलिए जल्दबाजी में, मैंने पूरी तरह से बीआईएन निर्देशिका हटा दी। मेरे स्रोत कोड को पुनर्निर्मित करें, और यह तब से बाहर काम किया।

Answer 15

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

कारण publisher policy था। जब मैंने जीएसी से लाइब्रेरी के संस्करणों को अनइंस्टॉल किया, तो मैं प्रकाशक नीति असेंबली को अनइंस्टॉल करना भूल गया, इसलिए स्थानीय रूप से तैनात असेंबली का उपयोग करने के बजाय असेंबली लोडर को जीएसी में प्रकाशक नीति मिली, जिसने इसे एक नए संस्करण की खोज करने के लिए कहा।

Answer 16

मुझे अपनी वेब साइट की एक डीएलएल फ़ाइल अपडेट करने का प्रयास करते समय भी एक ही समस्या थी।

यह त्रुटि तब हो रही थी जब मैंने बस इस DLL फ़ाइल को एफ़टीपी पर बिन फ़ोल्डर में कॉपी किया था।

मैं द्वारा इस समस्या का समाधान:

1. वेब साइट को रोकने;
2. आवश्यक डीएलएल फ़ाइल/डीएलएल फाइलों की प्रतिलिपि बनाना;
3. वेब साइट शुरू करने

Answer 17

मेरे app.config एक

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/> 

npgsql के लिए

शामिल हैं। किसी भी तरह उपयोगकर्ता की मशीन पर, मेरा app.exe.config गायब हो गया। मुझे यकीन नहीं है कि यह एक मूर्ख उपयोगकर्ता था, इंस्टॉलर गड़बड़, या अभी तक एंटी-वायरस बाहर wacked। फ़ाइल को प्रतिस्थापित करने से समस्या हल हो गई।

Answer 18

निम्नलिखित किसी भी असेंबली संस्करण को संस्करण 3.1.0.0 पर रीडायरेक्ट करता है। हमारे पास एक ऐसी स्क्रिप्ट है जो हमेशा इस संदर्भ को App.config में अपडेट करेगी, इसलिए हमें इस समस्या से फिर से निपटना नहीं होगा।

प्रतिबिंब के माध्यम से आप असेंबली सार्वजनिक प्राप्त कर सकते हैं और इस ब्लॉक को .dll फ़ाइल से ही उत्पन्न कर सकते हैं।

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
<dependentAssembly> 
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" /> 
    <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" /> 
    </dependentAssembly> 
</assemblyBinding> 

ध्यान दें कि एक्सएमएल नेमस्पेस विशेषता (xmlns) के बिना यह काम नहीं करेगा।

Answer 19

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

Answer 20

मुझे अपने यूनिट टेस्टकेस चलाने के दौरान एक ही समस्या का सामना करना पड़ा।

त्रुटि स्पष्ट रूप से समस्या बताती है: जब हम असेंबली लोड करने का प्रयास करते हैं, तो .NET असेंबली लोडर अपने प्रकट डेटा (संदर्भित असेंबली नाम, सार्वजनिक कुंजी टोकन, संस्करण) के आधार पर इसकी निर्दिष्ट असेंबली लोड करने का प्रयास करता है।

प्रकट डेटा की जांच करने के लिए:

1. ओपन दृश्य स्टूडियो कमांड प्रॉम्प्ट,
2. प्रकार 'ILDASM' और ILDASM खिड़की करने के लिए आवश्यक विधानसभा खींचें और MANIFEST दृश्य खोलें।कभी-कभी मैनिफ़ेस्ट में दो संस्करण पुराने संस्करण के साथ-साथ नए संस्करण (जैसे Utility, Version=1.2.0.200 और Utility, Version=1.2.0.203) के साथ एक असेंबली होती है। हकीकत में, निर्दिष्ट असेंबली Utility, Version=1.2.0.203(new version) है, लेकिन चूंकि मेनिफेस्ट में Utility, Version=1.2.0.200(old version) भी शामिल है, इसलिए .NET असेंबली लोडर इस संस्करण वाली DLL फ़ाइल को खोजने का प्रयास करता है, खोजने में विफल रहता है और इसलिए अपवाद फेंकता है।

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

Answer 21

यदि आपको संस्करण की परवाह नहीं है और आप बस अपने ऐप को चलाने के लिए चाहते हैं तो संदर्भ पर राइट क्लिक करें और 'विशिष्ट संस्करण' को गलत पर सेट करें। अन्य समाधान मेरे लिए काम नहीं करेंगे।

Answer 22

मैं सिर्फ यह जोड़ना चाहता हूं कि मैं मूल एएसपी.नेट एमवीसी 4 प्रोजेक्ट बना रहा हूं और NuGet के माध्यम से DotNetOpenAuth.AspNet जोड़ा। माइक्रोसॉफ्ट.Web.WebPages.OAuth के लिए एक विसंगति डीएलएल फ़ाइल का संदर्भ देने के बाद इसके परिणामस्वरूप एक ही त्रुटि हुई।

इसे ठीक करने के लिए मैंने Update-Package किया और पूर्ण पुनर्निर्माण के लिए समाधान साफ़ किया।

वह मेरे लिए काम किया है और एक आलसी तरीका की तरह है, लेकिन समय पैसा :-P

Answer 23

है AssemblyInfo.cs फ़ाइल में अपने AssemblyVersion में, बजाय निर्दिष्ट करने * की एक निश्चित संस्करण संख्या का उपयोग करें। * प्रत्येक संकलन पर संस्करण संख्या बदल जाएगा। मेरे मामले में इस अपवाद के लिए यह मुद्दा था।

Answer 24

मैं आंतरिक पैकेज भंडार का उपयोग करते समय इस समस्या में भाग गया। मैंने आंतरिक भंडार में मुख्य पैकेज जोड़ा था, लेकिन पैकेज की निर्भरता नहीं। सुनिश्चित करें कि आप सभी निर्भरताओं, निर्भरताओं की निर्भरताओं, पुनरावर्ती आदि को अपने आंतरिक भंडार में भी जोड़ दें।

Answer 25

मैंने एक NuGet पैकेज जोड़ा, केवल मेरे एप्लिकेशन का ब्लैक-बॉक्स भाग लाइब्रेरी के पुराने संस्करण का संदर्भ देने के लिए था।

मैं पैकेज निकाले गए और पुराने संस्करण के स्थिर DLL फ़ाइल संदर्भित, लेकिन web.config फ़ाइल से अद्यतन नहीं किया गया:

<dependentAssembly> 
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" /> 
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" /> 
</dependentAssembly> 

क्या यह जब मैं पैकेज की स्थापना रद्द मिल गए हैं चाहिए

:

<dependentAssembly> 
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" /> 
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" /> 
</dependentAssembly> 

Answer 26

मैन्युअल रूप से पुरानी असेंबली को फ़ोल्डर स्थान से हटाकर और फिर नई असेंबली के संदर्भ को जोड़ने से मदद मिल सकती है।

Answer 27

मेरे पास आज भी यही समस्या थी जिसने मुझे एंटिटी फ्रेमवर्क में बदलाव करने के बाद एड-माइग्रेशन करने से रोक दिया।

मेरे समाधान में दो परियोजनाएं थीं, चलिए उन्हें "क्लाइंट" और "डेटा" कहते हैं - एक क्लास लाइब्रेरी प्रोजेक्ट जो मेरे ईएफ मॉडल और संदर्भ आयोजित करता है। क्लाइंट ने डेटा प्रोजेक्ट का संदर्भ दिया।

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

मुझे आशा है कि यह किसी के लिए उपयोगी हो सकता है, उन्हें लंबे समय तक हताशा का बख्शते ..

Answer 28

मैं InstallShield उपयोग करने के लिए शुरू करने के बाद इस समस्या थी।भले ही निर्माण आदेश ने इंस्टॉलेशन प्रोजेक्ट को आखिरी बार दिखाया कि यह ऑर्डर से बाहर हो रहा था।

मैं हर दूसरे परियोजना यह पर निर्भर बनाकर इस को सही - इस स्थापना पिछले और इस तरह से हटाया मेरी विधानसभा बेमेल निर्माण करने के लिए मजबूर कर दिया। आशा है कि ये आपकी मदद करेगा।

Answer 29

मेरे मामले में समस्या कुर्सी और कीबोर्ड के बीच था :-)

Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0, 
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies. 
The located assembly's manifest definition does not match the assembly reference. 
(Exception from HRESULT: 0x80131040) 

दो या दो से अधिक विभिन्न विधानसभाओं DotNetOpenAuth पुस्तकालय का एक भिन्न संस्करण का उपयोग करना चाहता था, और कहा कि एक समस्या नहीं होगी। इसके अलावा, अपने स्थानीय कंप्यूटर पर एक web.config स्वचालित रूप से NuGet द्वारा अद्यतन किया गया था:

<dependentAssembly> 
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" /> 
     <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" /> 
    </dependentAssembly> 
    <dependentAssembly> 
     <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" /> 
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" /> 
</dependentAssembly> 

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

Answer 30

मैं एक ही त्रुटि ... मिला मेरी मामले में इस प्रकार के रूप में यह संकल्प लिया गया:

• पहले जब आवेदन तो स्थापित किया गया था यहाँ के लोग आवेदन में माइक्रोसॉफ्ट उद्यम पुस्तकालय 4.1 का इस्तेमाल किया था पर।
• पिछले सप्ताह में मेरी मशीन है कि आज के बाद & स्वरूपित किया गया था जब मुझे लगता है कि आवेदन बनाया तो यह मुझे एक त्रुटि है कि उद्यम लाइब्रेरी विधानसभा याद आ रही है दे दी है।
• तो मैं माइक्रोसॉफ्ट उद्यम पुस्तकालय 5.0 जो मैं पहले खोज प्रविष्टि के रूप में गूगल पर मिल गया स्थापित किया।
• फिर जब मैं आवेदन तो बनाया यह मेरे ऊपर त्रुटि अर्थात स्थित विधानसभा के प्रकट परिभाषा विधानसभा संदर्भ से मेल नहीं खाता दे दी है।
• एक खोज कार्य & विश्लेषण के बहुत बाद, मैंने पाया है कि आवेदन 4.1.0.0 & जिक्र कर रहे थे बिन फ़ोल्डर में DLL संस्करण 5.0.0.0
• क्या मैं तो था मैं माइक्रोसॉफ्ट उद्यम पुस्तकालय 4.1 स्थापित किया था ।
• पिछले संदर्भ निकाला गया (5.0) & 4.0 संदर्भ गयी।
• निर्मित आवेदन & देखा ... यह काम किया।

Answer 31

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

टीम फाउंडेशन सर्वर एक निर्देशिका में सभी DLL फ़ाइलों डालता है, और वहाँ केवल पाठ्यक्रम के एक समय पर एक निश्चित नाम से एक DLL फ़ाइल हो सकता है।

Answer 32

यह भी अगर आप AssemblyVersion टैग और अपने .csproj फ़ाइल के साथ दोनों AssemblyInfo.cs उपयोग कर रहे हैं हो सकता है एक अलग मूल्य के साथ है। असेंबलीइन्फो से मेल खाते हुए या अनुभाग को सभी को एक साथ हटाकर समस्या दूर हो जाती है।

Answer 33

मेरे मामले में, यह त्रुटि ASP.NET एप्लिकेशन चलाते समय हुई। समाधान के लिए किया गया था:

1. प्रोजेक्ट फ़ोल्डर में obj और bin फ़ोल्डर हटाएँ

स्वच्छ काम नहीं किया, पुनर्निर्माण काम नहीं किया, सभी संदर्भों को ठीक थे, लेकिन ऐसा नहीं था पुस्तकालयों में से एक लिखना। उन निर्देशिकाओं को हटाने के बाद, सब कुछ पूरी तरह से काम किया।

Answer 34

यहां इस समस्या को ठीक करने की मेरी विधि है।

1. अपवाद संदेश से, "समस्या" लाइब्रेरी और "अपेक्षित" संस्करण संख्या का नाम प्राप्त करें।

1. सभी अपने समाधान में है कि .dll की प्रतियां का पता लगाएं, उन पर राइट क्लिक करें, और .dll यह है का कौन सा संस्करण की जाँच करें।

ठीक है, इस उदाहरण में तो, मेरे .dll निश्चित रूप से 2.0.5022.0 है (ताकि अपवाद संस्करण संख्या गलत है)।

संस्करण संख्या जो अपने समाधान में .csproj फ़ाइलों के सभी में अपवाद संदेश में दिखाया गया था के लिए
1. खोजें। इस संस्करण संख्या को डीएल से वास्तविक संख्या के साथ बदलें।

तो, इस उदाहरण में, मैं इस जगह लेंगे ...

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" /> 

... इस के साथ ...

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" /> 

नौकरी हो गया!

Answer 35

ठीक है, एक और जवाब। मैंने पहले अपने ऐप को 64 बिट के रूप में बनाया और तदनुसार आउटपुट पथ (प्रोजेक्ट/प्रॉपर्टीज/बिल्ड/आउटपुट/आउटपुट पथ) बदल दिया। हाल ही में मैंने ऐप को 32 बिट (x86) में बदल दिया, एक नया आउटपुट पथ बनाया। मैंने एक शॉर्टकट बनाया जहां मैं संकलित संकलित .exe जा रहा था। कोई फर्क नहीं पड़ता कि मैंने स्रोत के बारे में क्या बदल दिया है, यह मैनिफेस्ट त्रुटि मिलान नहीं मिला है। निराशा के लगभग एक घंटे बाद, मैं .exe फ़ाइल की दिनांक/समय की जांच करने के लिए हुआ, देखा कि यह पुराना पुराना संदर्भ पुराना था। डीएलएस। मैं ऐप को पुरानी निर्देशिका में संकलित कर रहा था और मेरा शॉर्टकट नए संदर्भ में था। आउटपुट पथ को बदल दिया जहां .exe जाना चाहिए, शॉर्टकट चला गया और त्रुटि समाप्त हो गई। (माथे थप्पड़)

Answer 36

प्रश्न पहले से ही एक उत्तर है, लेकिन यदि समस्या एक ही समाधान में विभिन्न संस्करणों में NuGet पैकेज द्वारा हुई है, तो आप निम्न को आजमा सकते हैं।

ओपन NuGet पैकेज प्रबंधक, जैसा कि आप देखते हैं कि मेरा सेवा प्रोजेक्ट संस्करण दूसरों से अलग है।

फिर उन परियोजनाओं को अपडेट करें जिनमें आपके पैकेज का पुराना संस्करण शामिल है।

Answer 37

बस अपनी परियोजना के बिन फ़ोल्डर की सामग्री को हटाने और पुनर्निर्माण समाधान मेरी समस्या हल।

Answer 38

समाधान को साफ और पुनर्निर्माण आउटपुट निर्देशिका से सभी डीएलएल को प्रतिस्थापित नहीं कर सकता है।

मैं क्या सुझाव देंगे "oldbin" या "obj" "oldobj"

और फिर अपने silution फिर से निर्माण की कोशिश करने के लिए "बिन" से फ़ोल्डर का नाम बदलने की कोशिश है।

अगर आप किसी तीसरे पक्ष के डीएल का उपयोग कर रहे हैं तो आपको सफल निर्माण के बाद नए बनाए गए "बिन" या "ओबीजे" फ़ोल्डर में कॉपी करने की आवश्यकता होगी।

उम्मीद है कि यह आपके लिए काम करेगा।

Answer 39

मेरे साथ समस्या यह थी कि पुराने डीएल के तैनात किए गए थे जो नए निर्माण में हटा दिए गए थे। इसे ठीक करने के लिए, मैंने प्रकाशन के दौरान गंतव्य पर अतिरिक्त फ़ाइलों को निकालने के लिए बस बॉक्स को चेक किया। Remove additional files at destination