TypeLoadException का कहना है कि 'कोई कार्यान्वयन नहीं', लेकिन इसे लागू किया गया है

270

हमें हमारी परीक्षण मशीन पर एक बहुत ही अजीब बग मिला है। त्रुटि है:

System.TypeLoadException: Method 'SetShort' in type 'DummyItem' from assembly 'ActiveViewers (...)' does not have an implementation.

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

c# .net fusion typeloadexception

— Benjol
स्रोत

15

मैं प्यार करता हूँ कि कैसे अपने समुदाय के साथ अपने अनुभव को साझा करने के लिए हम सभी की मदद, और यहां तक कि हमें अन्य उत्तर भी पढ़ने के लिए प्रोत्साहित किया, धन्यवाद। अफसोस की बात है, मेरे लिए किसी भी सुझाव ने काम नहीं किया। जानना चाहते हैं कि आखिर मेरे लिए क्या काम किया? Visual Studio को पुनरारंभ करना। मैंने पहले कोशिश क्यों नहीं की?

— पॉल मैकलीन

धन्यवाद पॉल, आपकी टिप्पणी पढ़ने के बाद मैंने कोशिश की है कि पहले। एक आकर्षण की तरह काम किया :-)

— Jan_V

धन्यवाद पॉल, मुझे कुछ घंटों तक लगातार मेरे सिर को बंदर की तरह खरोंचने से बचाओ ...

— कीन चू

इसके अलावा, वीएस 2017 15.7 अपडेट के बाद, वीएस आपको रिबूट करने के लिए कहता है। आपने ऐसा नहीं किया होगा (मेरी तरह, मीटिंग्स के कारण मैं भूल गया था)। मुझे इन जैसे

— कटावों की बकवास मिली

बस अपना 2p जोड़ने के लिए - मुझे यह समस्या तब मिली जब MsTest में यूनिट टेस्ट चल रहे थे। परीक्षण के तहत कक्षाएं एक हस्ताक्षरित विधानसभा में थीं। इस विधानसभा का एक अलग संस्करण GAC में हुआ। MsTest बिन फ़ोल्डर से एक का उपयोग करने के बजाय GAC'd असेंबली उठा रहा था, और इसके खिलाफ परीक्षण चलाने की कोशिश कर रहा था, जो स्पष्ट रूप से काम नहीं कर रहा था। समाधान GAC'd असेंबली को हटाने के लिए किया गया था

— टॉम

244

नोट - यदि यह उत्तर आपकी सहायता नहीं करता है, तो कृपया उन अन्य उत्तरों के माध्यम से स्क्रॉल करने के लिए समय निकालें, जिन्हें लोगों ने जोड़ा है।

संक्षिप्त जवाब

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

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

लंबा जवाब

यदि आप इसे पुन: प्रस्तुत करने का प्रयास करना चाहते हैं, तो निम्न प्रयास करें:

एक क्लास लाइब्रेरी प्रोजेक्ट बनाएं: InterfaceDef, सिर्फ एक क्लास जोड़ें, और बनाएँ:
```
public interface IInterface
{
    string GetString(string key);
    //short GetShort(string key);
}
```
एक दूसरी श्रेणी की लाइब्रेरी प्रोजेक्ट बनाएं: कार्यान्वयन (अलग समाधान के साथ), प्रोजेक्ट डायरेक्टरी में InterfaceDef.dll की प्रतिलिपि बनाएँ और फ़ाइल संदर्भ के रूप में जोड़ें, बस एक वर्ग जोड़ें, और निर्माण करें:
```
public class ImplementingClass : IInterface
{
    #region IInterface Members
    public string GetString(string key)
    {
        return "hello world";
    }

    //public short GetShort(string key)
    //{
    //    return 1;
    //}
    #endregion
}
```
एक तीसरा, कंसोल प्रोजेक्ट बनाएँ: ClientCode, प्रोजेक्ट निर्देशिका में दो dll की प्रतिलिपि बनाएँ, फ़ाइल संदर्भ जोड़ें, और मुख्य विधि में निम्न कोड जोड़ें:
```
 IInterface test = new ImplementingClass();
 string s = test.GetString("dummykey");
 Console.WriteLine(s);
 Console.ReadKey();
```
कोड को एक बार चलाएं, कंसोल कहता है "हैलो वर्ल्ड"
दो dll प्रोजेक्ट्स में कोड को अनइंस्टॉल करें और फिर से बनायें - दो dlls वापस ClientCode प्रोजेक्ट में कॉपी करें, फिर से बनाएँ और फिर से चलाने का प्रयास करें। TypeLoadException तब लागू होती है जब ImplementingClass को त्वरित करने का प्रयास किया जाता है।

— Benjol
स्रोत

1

आपको यह जोड़ना होगा कि कॉनसोल ऐप को नए DLL के साथ संदर्भ के रूप में फिर से बनाया जाना चाहिए। डीएलएल की नकल करने से काम नहीं चलेगा और यह संस्करण बेमेल के कारण हो सकता है (यानी जब आप स्रोत डीएलएल को संकलित करेंगे तो संस्करण बदल जाएगा)। क्या यह उचित समझ है?

— शुक्लपक्ष

@ शशाकलेश अच्छा बिंदु - मेरे लिए 'फिर से चल रहा है' F5 निहित। मैंने जवाब अपडेट कर दिया है। बेशक यह सब एक सभ्य स्रोत नियंत्रण उपकरण के साथ नहीं हुआ होगा, लेकिन मुझे उस विषय पर शुरुआत नहीं

— करनी चाहिए

4

हम्म, ऐसा लगता है कि Microsoft के त्रुटि संदेश में एक त्रुटि है - यह कह रहा है कि क्लास "DummyItem" की एक विधि का कार्यान्वयन नहीं है, जो कि वर्तमान में गलत है .... वास्तव में समस्या यह है कि इंटरफ़ेस की एक विधि isn टी डमी इट द्वारा लागू किया गया।

— क्वर्टी जू

3

इसके बारे में कोई अच्छा अंतिम समाधान? Microsoft ने क्या समाधान सुझाया था?

— Kiquenet

12

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

— डीजे।

33

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

public interface IFoo
{
    void DoFoo();
}

public class Foo : IFoo
{
    public void DoFoo() { Console.WriteLine("This is _not_ the interface method."); }
    void IFoo.DoFoo() { Console.WriteLine("This _is_ the interface method."); }
}

Foo foo = new Foo();
foo.DoFoo();               // This calls the non-interface method
IFoo foo2 = foo;
foo2.DoFoo();              // This calls the interface method

— Timwi
स्रोत

इसने इसे मेरे लिए हल कर दिया, आक्षेप के अतिरिक्त स्तर के साथ कि यह जिस विधि से दावा किया गया था वह गायब था, एक मूल वर्ग द्वारा कार्यान्वित इंटरफ़ेस में घोषित किया गया था, और फिर से उपवर्ग में घोषित किया गया था। उपवर्ग से डुप्लिकेट को हटाने से त्रुटि दूर हो गई।

— ilikeprogramming

22

मुझे यह तब मिला जब मेरे आवेदन में क्लास को परिभाषित करने वाली एक अन्य विधानसभा का संदर्भ नहीं था जो कि त्रुटि संदेश में प्रयुक्त विधि है। चल रहे PEVerify ने अधिक उपयोगी त्रुटि दी: "सिस्टम निर्दिष्ट फ़ाइल नहीं ढूँढ सकता।"

— मौन स्वर
स्रोत

19

मैं एक ही संदेश भर आया और यहां हमने पाया है: हम अपने प्रोजेक्ट में थर्ड पार्टी dll का उपयोग करते हैं। उन लोगों की एक नई रिहाई के बाद हमने dlls के नए सेट की ओर संकेत करने के लिए अपनी परियोजना को बदल दिया और सफलतापूर्वक संकलित किया।

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

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

त्रुटि संदेश काफी भ्रामक था, लेकिन कमोबेश सही दिशा (सही विधि, गलत संदेश) को इंगित करता है।
अपवाद हालांकि हमने प्रश्न में विधि का उपयोग नहीं किया था।
जो मुझे इस सवाल की ओर ले जाता है: यदि यह अपवाद किसी भी स्थिति में फेंक दिया जाता है, तो संकलक इसे क्यों नहीं उठाता है?

— बेन
स्रोत

17

मुझे निम्न परिदृश्य में यह त्रुटि मिली।

दोनों असेंबली ए और बी को संदर्भित करते हैं। System.eb.Mvc संस्करण 3.0.0.0
असेम्बली ए ने असेंबली बी का उल्लेख किया था और इसमें क्लास बी के उन तरीकों के साथ लागू किया गया था जो सिस्टम .eb.Mvc से कक्षाएं लौटाते थे।
असेंबली A को System.Web.Mvc संस्करण 4.0.0.0 में अपग्रेड किया गया है
असेंबली C ने नीचे कोड चलाया (FertPin.Classes.Contact विधानसभा ए में निहित था):

var target = Assembly.GetAssembly(typeof(FertPin.Classes.Contact));

मेरे लिए फिक्स विधानसभा बी में 4.0.0.0 के लिए System.Web.Mvc संदर्भ को अपग्रेड कर रहा था। अब स्पष्ट लगता है!

मूल पोस्टर के लिए धन्यवाद!

— डेमियन सॉयर
स्रोत

मेरे पास कुछ समान था लेकिन संस्करणों के साथ दूसरा तरीका गोल था। .NET 2 को लक्षित करने वाली एक विधि, System.Windows.Forms के v2 से एक प्रकार लौटाया गया। .NET 4-टारगेटेड असेंबली में इसके ओवरराइड कार्यान्वयन को उसी प्रकार लौटाया गया, लेकिन System.Windows.Forms के v4 से। यह ठीक संकलित है, लेकिन ReflectionOnlyLoadFrom इसे पसंद नहीं आया।

— स्टीफन हेवलेट

मुझे लोडिंग प्रकारों के कारण एक ऐसी ही समस्या थी, जो .NET .NET के रिफ्लेक्शनऑनली संदर्भ में .NET2 को लक्षित करते थे। मैंने .NET2 कोर असेंबली के सभी असेंबली अनुरोधों को AppDomain.ReflectionOnlyAssemblyResolve इवेंट में उनके .NET4 समकक्षों पर पुनर्निर्देशित करके समस्या के आसपास काम किया।

— चौकोट्टे

यह मेरा मुद्दा था :) धन्यवाद!

— एंटोन एलानकोव

13

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

asp.net प्रोजेक्ट में असेंबली A और असेंबली B है, B को दृढ़ता से नाम दिया गया है
असेंबली A, उत्प्रेरक C का उपयोग करती है। असेंबली C को लोड करने के लिए बनाएँ (यानी अलग से निर्मित C का कोई संदर्भ नहीं है)
C को वर्तमान में मौजूद असेंबली B के पुराने संस्करण का संदर्भ देते हुए बनाया गया था

आशा है कि किसी की मदद करता है - यह पता लगाने के लिए मुझे उम्र लग गई।

— टिम
स्रोत

9

मेरे पास यह त्रुटि भी थी, यह किसी भी सीपीयू एक्सई द्वारा संदर्भित किसी भी सीपीयू असेंबली के कारण था जो बदले में एक x86 असेंबली का संदर्भ देता था।

अपवाद ने MyApp.Implementations (किसी भी CPU) में एक वर्ग पर एक विधि के बारे में शिकायत की, जो MyApp.Interfaces (किसी भी CPU) से प्राप्त हुई, लेकिन fuslogvw.exe में मुझे एक गलत प्रारूप के साथ प्रोग्राम को लोड करने का एक छिपा हुआ 'प्रयास मिला' MyApp से अपवाद .CommonTypes (x86) जिसका उपयोग दोनों द्वारा किया जाता है।

— रिचर्ड डिंगवाल
स्रोत

6

मैं इस पर वापस आ रहा हूँ ... यहाँ कई उत्तर यह समझाने का एक बड़ा काम करते हैं कि समस्या क्या है लेकिन इसे ठीक नहीं करना है।

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

मैं प्रकाशित टूल का उपयोग करके फ़ंक्शन को हटाने का सुझाव नहीं देता क्योंकि यह IIS को बंद करने के लिए जाता है।

— डीजे।
स्रोत

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

— d219

मुझे IIS रीसेट करना पड़ा और साथ ही यह विशेष परियोजना IIS का स्थानीय स्तर पर (दुर्भाग्य से) उपयोग कर रही है।

— टिम विल्सन

6

मेरे पास इस त्रुटि संदेश का एक और गूढ़ समाधान है। मैंने अपना लक्ष्य ढाँचा .net 4.0 से 4.6 तक उन्नत किया, और मेरी इकाई परीक्षण परियोजना मुझे "System.TypeLoadException ... का कार्यान्वयन नहीं है" त्रुटि दे रही थी जब मैंने बनाने की कोशिश की थी। इसने कथित रूप से गैर-कार्यान्वित विधि के बारे में एक दूसरा त्रुटि संदेश भी दिया, जिसमें कहा गया था कि "बिल्डशैडो टैस्क 'अप्रत्याशित रूप से विफल रहा।" यहाँ कोई भी सलाह मदद करने वाली नहीं थी, इसलिए मैंने "बिल्डशैडो टैस्क" की खोज की, और एमएसडीएन पर एक पोस्ट पाया, जिसके कारण मुझे यूनिट टेस्ट प्रोजेक्ट की csproj फ़ाइल से इन लाइनों को हटाने के लिए एक टेक्स्ट एडिटर का उपयोग करना पड़ा ।

<ItemGroup>
  <Shadow Include="Test References\MyProject.accessor" />
</ItemGroup>

उसके बाद, दोनों त्रुटियां चली गईं और परियोजना का निर्माण हुआ।

— टोनी पुलोकस
स्रोत

यह मेरे लिए जवाब था। .NET 4.5 से 4.6 तक अपग्रेड करने के बाद मैं इस त्रुटि में भाग गया।

— टिम्बलर 12:03

6

मुझे इस त्रुटि का संदर्भ एक संदर्भ में मिला जहां मैं ऑटोफैक और बहुत सारे डायनामिक असेंबली लोडिंग का उपयोग कर रहा था।

एक ऑटोफेक रिज़ॉल्यूशन ऑपरेशन करते समय, रनटाइम असेंबलियों में से एक को लोड करने में विफल होगा। त्रुटि संदेश की शिकायत की Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation। लक्षण उस समय हुआ जब एक विंडोज सर्वर 2012 R2 वी एम पर चल रहा है, लेकिन किया नहीं Windows 10 या Windows Server 2016 VMs पर होते हैं।

ImplementationAssemblyसंदर्भित System.Collections.Immutable1.1.37, और इसमें एक IMyInterface<T1,T2>इंटरफ़ेस का कार्यान्वयन शामिल था, जिसे एक अलग तरीके से परिभाषित किया गया था DefinitionAssembly। DefinitionAssemblyसंदर्भित System.Collections.Immutable1.1.36।

जिन तरीकों से IMyInterface<T1,T2>"लागू नहीं किया गया था" में प्रकार के पैरामीटर थे IImmutableDictionary<TKey, TRow>, जो में परिभाषित किया गया है System.Collections.Immutable।

System.Collections.Immutableकार्यक्रम निर्देशिका में पाई गई वास्तविक प्रतिलिपि संस्करण 1.1.37 थी। मेरे विंडोज सर्वर 2012 R2 वीएम पर, जीएसी में System.Collections.Immutable1.1.36 की एक प्रति शामिल थी। विंडोज 10 और विंडोज सर्वर 2016 पर, जीएसी में System.Collections.Immutable1.1.37 की एक प्रति शामिल थी। लोडिंग त्रुटि केवल तब हुई जब GAC में DLL का पुराना संस्करण था।

इसलिए, असेंबली लोड विफलता का मूल कारण बेमेल संदर्भ थे System.Collections.Immutable। इंटरफ़ेस की परिभाषा और कार्यान्वयन में समान दिखने वाली विधि हस्ताक्षर थे, लेकिन वास्तव में के विभिन्न संस्करणों पर निर्भर थे System.Collections.Immutable, जिसका मतलब था कि रनटाइम इंटरफ़ेस परिभाषा से मेल खाने के लिए कार्यान्वयन वर्ग पर विचार नहीं करता था।

मेरे अनुप्रयोग कॉन्फ़िग फ़ाइल में निम्नलिखित बाइंडिंग रीडायरेक्ट को जोड़ने से समस्या ठीक हो गई:

<dependentAssembly>
        <assemblyIdentity name="System.Collections.Immutable" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.1.37.0" newVersion="1.1.37.0" />
</dependentAssembly>

— hydrargyrum
स्रोत

क्या मैं आपसे पूछ सकता हूं कि आपने इसे कैसे पाया? क्या आपने किसी गैर-मानक डिबगिंग तकनीक का उपयोग किया था? मुझे एक ही त्रुटि मिलती है, लेकिन मुझे लगता है कि यह एक अलग dll के कारण होता है क्योंकि मेरे पास पहले से ही अपरिवर्तनीयों के लिए एक बाध्यकारी रीडायरेक्ट है।

— t3chb0t

1

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

— ४३ पर

1

बहुत बहुत धन्यवाद! ;-) मैंने विज़ुअल स्टूडियो के लिए ILSpy एक्सटेंशन स्थापित किया और संदर्भ शाखा को देखा, System.Net.Httpपैकेज के लिए एक था , मैंने dependentAssemblyइसके लिए तत्व जोड़ा और ILSpy से जानकारी की प्रतिलिपि बनाई और अब यह काम कर रहा है, त्रुटि हो गई है!

— t3chb0t

मुझे लगा कि कोड में इसे डालकर खराब जीएसी असेंबली थी और मूल्यों को देखने के लिए इसके ठीक बाद एक ब्रेकपॉइंट लगाया गया और System.Net.tt के दो संस्करणों को देखा गया। लोड किया गया: AppDainain.CurrentDomain से var loadAssemblies = को लोड किया गया। GetAssemblies () ऑर्डरबी। ए.फलनाम सेलेक्ट (ए.फुलनाम, ए);

— पाउली 4

5

मुझे यह "हीरे" के आकार की परियोजना निर्भरता के साथ मिला:

प्रोजेक्ट ए प्रोजेक्ट बी और प्रोजेक्ट डी का उपयोग करता है
प्रोजेक्ट B प्रोजेक्ट D का उपयोग करता है

मैंने प्रोजेक्ट A को फिर से शुरू किया, लेकिन प्रोजेक्ट B को नहीं, जिसने प्रोजेक्ट B के पुराने संस्करण को प्रोजेक्ट B को "इंजेक्ट" करने की अनुमति दी

— सर्ज डेसमंड
स्रोत

16

हाँ, मुझे यह सोचना पसंद है कि रेनॉल्ट समस्या के रूप में

— बेंजोल

मुझे लगता है कि मेरे पास इस समस्या का एक समान संस्करण था, लेकिन सिर्फ दो परियोजनाओं के बीच। मैंने नए को मैन्युअल रूप से संकलित किया। उसके बाद इसने सुचारू रूप से काम किया।

— डिपार्टमेन्ट B B

5

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

var types = AppDomain.CurrentDomain.
   GetAssemblies().
   ToList().
   SelectMany( s => s.GetTypes() /* exception thrown in this call */ )
;

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

— जी के जानकार
स्रोत

4

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

— Kyberias
स्रोत

4

यह त्रुटि तब भी हो सकती है यदि किसी असेंबली को लोड करके उपयोग किया जाता है। LoadFrom (स्ट्रिंग) और असेंबली का उपयोग करते हुए पहले से लोड की गई असेंबली का संदर्भ दे रहा है। लोड (बाइट [])।

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

लोडफ्रॉम का उपयोग करने के बजाय आपको लोड का उपयोग करना चाहिए। निम्नलिखित कोड काम करेगा:

private static Assembly LoadAssemblyFromFile( String filePath )
{
    using( Stream stream = File.OpenRead( filePath ) )
    {
        if( !ReferenceEquals( stream, null ) )
        {
            Byte[] assemblyData = new Byte[stream.Length];
            stream.Read( assemblyData, 0, assemblyData.Length );
            return Assembly.Load( assemblyData );
        }
    }
    return null;
}

— FrankCoder
स्रोत

3

इस तरह की समस्या के लिए एक और स्पष्टीकरण जिसमें प्रबंधित C ++ शामिल है।

यदि आप प्रबंधित C ++ का उपयोग करके बनाई गई असेंबली में परिभाषित इंटरफ़ेस को स्टब करने का प्रयास करते हैं, जिसमें एक विशेष हस्ताक्षर है, तो स्टब बनाए जाने पर आपको अपवाद मिलेगा।

यह राइनो मोक्स और संभवतः किसी भी नकली रूपरेखा का उपयोग करने के लिए सच है System.Reflection.Emit।

public interface class IFoo {
  void F(long bar);
};

public ref class Foo : public IFoo {
public:
  virtual void F(long bar) { ... }
};

इंटरफ़ेस परिभाषा को निम्नलिखित हस्ताक्षर मिलते हैं:

void F(System.Int32 modopt(IsLong) bar)

ध्यान दें कि C ++ टाइप longमैप्स System.Int32(या केवल intC # में)। यह कुछ हद तक अस्पष्ट है modoptजो राइनो मोक्स मेलिंग सूची में आयेंडे रहियन द्वारा बताई गई समस्या का कारण है ।

— मार्टिन लीवरेज
स्रोत

मुझे यह त्रुटि तब हुई जब मैंने डेटाटाइप का उपयोग किया System::Byte। मैंने स्वीकार करने के लिए हस्ताक्षर बदल दिए unsigned shortऔर आकाश फिर से नीला हो गया।

— कृषक

3

मैंने अभी MVC3 से MVC5 तक एक समाधान का उन्नयन किया, और अपनी इकाई परीक्षण परियोजना से समान अपवाद प्राप्त करना शुरू कर दिया।

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

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-5.1.0.0" newVersion="5.1.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

— shenku
स्रोत

3

मेरे मामले में इसने WinForms Toolbox को रीसेट करने में मदद की।

Formडिजाइनर में एक खोलने पर मुझे अपवाद मिला ; हालाँकि, कोड को संकलित करना और चलाना संभव था और कोड ने अपेक्षा के अनुरूप व्यवहार किया। अपवाद UserControlमेरे संदर्भित पुस्तकालयों में से एक इंटरफ़ेस को लागू करने वाले स्थानीय में हुआ । इस लाइब्रेरी को अपडेट करने के बाद त्रुटि सामने आई।

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

यहाँ मैं इस स्थिति से कैसे उबर पाया:

WinForms टूलबॉक्स पर राइट क्लिक करें और Reset Toolboxसंदर्भ मेनू में क्लिक करें । (यह टूलबॉक्स से कस्टम आइटम हटाता है)।
मेरे मामले में टूलबॉक्स आइटम उनकी डिफ़ॉल्ट स्थिति में बहाल किए गए थे; हालाँकि, पॉइंटर-तीर टूलबॉक्स में गायब था।
Visual Studio को बंद करें।
मेरे मामले में विज़ुअल स्टूडियो ने उल्लंघन के अपवाद को समाप्त कर दिया और निरस्त कर दिया।
Visual Studio को पुनरारंभ करें।
अब सब कुछ सुचारू रूप से चल रहा है।

— ओलिवियर जैकोट-डेसकोम्बेस
स्रोत

3

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

— टिलमैन
स्रोत

3

मुझे यह त्रुटि मिली क्योंकि मेरे पास असेंबली 'C' में एक वर्ग था जो फ्रेमवर्क के संस्करण 4.5 पर था, असेंबली 'A' में एक इंटरफ़ेस लागू करना जो फ्रेमवर्क के संस्करण 4.5.1 पर था और असेंबली के आधार वर्ग के रूप में कार्य कर रहा था। 'बी' जो कि फ्रेमवर्क के संस्करण 4.5.1 पर भी था। विधानसभा 'बी' को लोड करने की कोशिश करते हुए सिस्टम ने अपवाद को फेंक दिया। इसके अतिरिक्त, मैंने तीनों विधानसभाओं पर .net 4.5.1 को निशाना बनाते हुए कुछ नगेट पैकेज स्थापित किए थे। किसी कारण से, भले ही nuget संदर्भ असेंबली 'B' में दिखाई नहीं दे रहे थे, लेकिन यह सफलतापूर्वक निर्माण कर रहा था।

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

— तोलु
स्रोत

3

मेरे मामले में मैंने पहले एक mylibपरियोजना को रेपो के बाहर एक सिबलिंग फ़ोल्डर में संदर्भित किया था - चलो कॉल करते हैं v1.0।

|-- myrepo
|    |-- consoleApp
|    |-- submodules
|         |-- mylib (submoduled v2.0)
|-- mylib (stale v1.0)

बाद में मैंने इसे ठीक से किया और इसे git सबमॉड्यूल के माध्यम से उपयोग किया - जो कि कॉल करता है v2.0। एक परियोजना consoleAppहालांकि ठीक से अद्यतन नहीं किया गया था। यह अभी भी v1.0मेरे गिट परियोजना के बाहर पुरानी परियोजना को संदर्भित कर रहा था ।

भ्रमित करने वाले हैं, भले ही *.csprojस्पष्ट रूप से गलत है और की ओर इशारा करते था v1.0, विजुअल स्टूडियो IDE के रूप में पथ से पता चला है v2.0परियोजना! इंटरफ़ेस और वर्ग का निरीक्षण करने के लिए F12 v2.0संस्करण में भी गया।

संकलक द्वारा बिन फ़ोल्डर में रखी गई विधानसभा v1.0संस्करण थी, इसलिए सिरदर्द।

यह तथ्य कि आईडीई मुझसे झूठ बोल रहा था, उसने त्रुटि का एहसास करने के लिए अतिरिक्त मेहनत की।

हल : हटाए गए प्रोजेक्ट संदर्भों को ConsoleAppउनसे पढ़ा और पढ़ाया गया।

सामान्य सुझाव: सभी असेंबली को खरोंच से (जहाँ संभव हो, कोर्स के नगेट पैकेज के लिए नहीं कर सकते हैं) से हटा दें और bin\debugफ़ोल्डर में डेटाइम स्टैम्प की जाँच करें । कोई भी पुरानी दिनांकित असेंबलियाँ आपकी समस्या हैं।

— व्यवस्थापत्र
स्रोत

3

मैंने लगभग उसी मुद्दे का सामना किया। मैं अपना सिर खुजला रहा था कि यह क्या त्रुटि है। मैंने क्रॉस चेक किया, सभी तरीके लागू किए गए।

Googling पर मुझे यह लिंक अन्य के बीच मिला। @Paul मैकलिंक टिप्पणी के आधार पर, इस दो चरणों ने इस मुद्दे को हल कर दिया।

Visual Studio को पुनरारंभ करें
स्वच्छ, निर्माण (पुनर्निर्माण)

और त्रुटि हो गई ।

वीएस प्लगइन को पुनरारंभ करें

धन्यवाद पॉल :)

आशा है कि इस त्रुटि में आने वाले किसी व्यक्ति की मदद करता है :)

— केजीएन-वेब
स्रोत

2

मैं अपने unittests चलाने के दौरान भी इस समस्या में भाग गया। एप्लिकेशन ठीक चला और कोई त्रुटि नहीं है। मेरे मामले में समस्या का कारण यह था कि मैंने परीक्षण परियोजनाओं के निर्माण को बंद कर दिया था। मेरे टेस्टप्रोजेक्ट के निर्माण को सक्षम करने से मुद्दों का समाधान हुआ।

— वेस्ले
स्रोत

2

मैंने इसे विजुअल स्टूडियो प्रो 2008 में देखा था जब दो परियोजनाओं ने एक ही नाम के साथ असेंबली का निर्माण किया था, एक वर्ग के लिबास SDF.dll, और एक जो असेंबली नाम sdf.exe के साथ लिब को संदर्भित करता था। जब मैंने संदर्भित विधानसभा का नाम बदल दिया, तो अपवाद चला गया

— एन रोमाई
स्रोत

2

इसका सीधा अर्थ है कि कार्यान्वयन परियोजना मेरे मामलों में पुरानी है। इंटरफ़ेस युक्त DLL को फिर से बनाया गया था लेकिन कार्यान्वयन dll बासी था।

— TrustyCoder
स्रोत

2

यहाँ इस त्रुटि पर ले रहा हूँ।

एक externविधि जोड़ी गई , लेकिन मेरा पेस्ट दोषपूर्ण था। DllImportAttributeएक टिप्पणी की लाइन पर डाल दिया गया।

/// <returns>(removed for brevity lol)</returns>[DllImport("user32.dll")] 
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool IsWindowVisible(IntPtr hWnd);

यह सुनिश्चित करना कि वास्तव में स्रोत तय किए गए मुद्दे में विशेषता शामिल थी।

2

मुझे एक x86 बिल्ड प्रकार का चयन करने के कारण WCF सेवा में यह मिला, जिससे बिन के बजाय बिन \ x86 के नीचे रहने के लिए डिब्बे बन गए। किसी भी CPU का चयन करने से recompiled DLL सही स्थानों पर जाते हैं (मैं विस्तार में नहीं जाना कि यह पहली जगह में कैसे हुआ)।

— रूबेन बार्टलिंक
स्रोत

1

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

होम होम संदेश यह है कि आवश्यक असेंबली को लोड करने के लिए लिंक गायब होने के कारण यह त्रुटि दिखाई देती है।

— Almis
स्रोत

1

मेरे मामले में, मैं TypeBuilderएक प्रकार बनाने के लिए उपयोग करने का प्रयास कर रहा था । TypeBuilder.CreateTypeइस अपवाद को फेंक दिया। मुझे अंततः एहसास हुआ कि मुझे एक ऐसी विधि के लिए MethodAttributes.Virtualकॉल TypeBuilder.DefineMethodकरते समय विशेषताओं को जोड़ना होगा जो एक इंटरफ़ेस को लागू करने में मदद करता है। ऐसा इसलिए है क्योंकि इस ध्वज के बिना, विधि इंटरफ़ेस को लागू नहीं करती है, बल्कि एक ही हस्ताक्षर के साथ एक नई विधि के बजाय (निर्दिष्ट किए बिना भी MethodAttributes.NewSlot)।

— जेम्स
स्रोत

1

एक परिशिष्ट के रूप में: यह तब भी हो सकता है यदि आप एक नगेट पैकेज को अपडेट करते हैं जिसका उपयोग फ़ेक असेंबली बनाने के लिए किया गया था। कहते हैं कि आप एक एनगेट पैकेज का V1.0 स्थापित करते हैं और एक नकली असेंबली बनाते हैं "fakeLibrary.1.0.0.0.Fakes"। अगला, आप नगेट पैकेज के नवीनतम संस्करण में अपडेट करते हैं, v1.1 कहते हैं जिसने एक इंटरफ़ेस में एक नया तरीका जोड़ा है। फेक लाइब्रेरी अभी भी पुस्तकालय के v1.0 की तलाश में है। बस नकली विधानसभा को हटा दें और इसे फिर से बनाएं। यदि यह मुद्दा था, तो यह शायद इसे ठीक कर देगा।

— क्रिस पीटरसन
स्रोत

1

मुझे यह त्रुटि हाल ही में विंडोज़ अपडेट के बाद मिली है। मेरे पास एक इंटरफ़ेस से वारिस करने के लिए एक सर्विस क्लास सेट था। इंटरफ़ेस में एक हस्ताक्षर शामिल था जिसने ValueTuple लौटाया, C # में एक काफी नई सुविधा।

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

— Mike_G
स्रोत