System.MissingMethodException: विधि नहीं मिली?

244

क्या एक बार मेरे asp.net webforms अनुप्रयोग में काम कर रहा था अब इस त्रुटि को फेंकता है:

System.MissingMethodException: विधि नहीं मिली

DoThisविधि एक ही कक्षा में है और यह काम करना चाहिए।

मेरे पास एक सामान्य हैंडलर है:

public class MyHandler: IHttpHandler
{
    public void Processrequest(HttpContext context)
    {
      // throws error now System.MissingMethodException: Method not found?
      this.DoThis(); 
    }

    public void DoThis()
    {
    //
    }
}

— user603007
स्रोत

क्या आप कुछ और कोड पोस्ट कर सकते हैं, क्योंकि यह कोड मान्य नहीं है।

— मिरोनिच

2

क्या है somepage? जैसा कि 'ध्वनि' ने कहा, यह कोड मान्य नहीं है। कृपया हमें एक पूर्ण कोड स्निपेट दें जो समस्या को प्रदर्शित करता है।

— एमी

387

यह एक ऐसी समस्या है जो तब हो सकती है जब DLL का कोई पुराना संस्करण अभी भी कहीं आसपास है। सुनिश्चित करें कि नवीनतम असेंबलियों को तैनात किया गया है और कोई भी डुप्लिकेट पुरानी असेंबलियों को कुछ फ़ोल्डरों में छिपा नहीं है। आपका सबसे अच्छा शर्त होगा कि आप हर निर्मित वस्तु को हटा दें और संपूर्ण समाधान को फिर से तैयार करें / पुन: निर्माण करें।

— राजनीति
स्रोत

62

विशेष रूप से, सुनिश्चित करें कि एक पुराना संस्करण GAC में नहीं है।

— लैडजेज

7

इसके अलावा, यदि आप दुर्भाग्यपूर्ण मामले में काम कर रहे हैं, जहां आपके पास एक पुस्तकालय है जो एक पुस्तकालय पर निर्भर करता है, जो कि एक पुस्तकालय पर निर्भर करता है, आदि तो जो भी dll के एक ही संस्करण के साथ निर्भर पुस्तकालयों के सभी को साफ / पुनर्निर्माण करना सुनिश्चित करें, मेरे मामले में NHibernate ...

— सर्ज सगन

2

प्रोजेक्ट के लिए .NET लक्ष्य ढांचे को अपग्रेड करना भी त्रुटि को ठीक कर सकता है। मैं .NET 4.5 को लक्षित करते हुए MVC4 / Web API 1 परियोजना को अपग्रेड कर रहा था। सभी एमवीसी, वेब एपीआई और एंटिटी फ्रेमवर्क निर्भरता के उन्नयन के बाद, मैं एक ही त्रुटि में भाग गया; .NET 4.5.1 को टारगेट फ्रेमवर्क बदलने से त्रुटि दूर हो गई।

— सर्गेई के

1

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

— हो हो हो

14

मैंने डिबग खोलने के लिए उपयोगी पाया -> विंडोज -> मॉड्यूल विंडो जब डिबगिंग यह देखने के लिए कि असेंबली कहां से लोड की जा रही थी।

— 1

31

⚠️ गलत नगेट पैकेज संस्करण ug

मैं एक इकाई परीक्षण परियोजना है जो हमारे कंपनियों आंतरिक एफई Nuget डेटा का उपयोग पैकेज और में खींच रहा था था कि कोड में खींच लिया एक बाहरी पैकेज जिसका संस्करण था जिस तरह से वर्तमान संस्करण के पीछे।

मुद्दा यह था कि पैकेज के लिए Nuget सेटिंग्स को सेट किया गया था least version; और पुराने संस्करण जीते और संचालन के दौरान उपयोग किया गया था ...।

इसलिए इसे चुपचाप पैकेज और ऐप दोनों द्वारा उपयोग की जाने वाली एक आम विधानसभा के लिए गलत संस्करण मिला ।

💡 समाधान 💡

उपयोग करने के लिए और नवीनतम [ तय ] प्राप्त करने के लिए Nuget में पैकेज को सेट / अपडेट करके , समस्या को हल किया।

— ΩmegaMan
स्रोत

1

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

— एकॉनसन

मेरा यूनिट टेस्ट प्रोजेक्ट मेरी वास्तविक परियोजना की तुलना में एक नया संस्करण संदर्भित कर रहा था

— Rhyous

26

मैंने सर्वर पर सही .NET फ्रेमवर्क संस्करण स्थापित करके इस समस्या को हल किया। वेबसाइट 4.0 संस्करण के तहत चल रही थी और असेंबली इसे कॉल कर रही थी जिसे 4.5 के लिए संकलित किया गया था। .NET फ्रेमवर्क 4.5 की स्थापना और वेबसाइट को 4.5 में अपग्रेड करने के बाद, सभी ठीक काम करता है।

— बेन ग्रिपका
स्रोत

2

.NET 3.5 संकलन लक्ष्य और स्थापित .NET के साथ कुछ समस्या। मुझे वास्तव में आश्चर्य है कि स्टार्टअप पर अधिक बुनियादी चेतावनी क्यों नहीं है ...

— मार्टिन मीसर

.NET फ्रेमवर्क संस्करण> 4.0 के लिए, आपको स्टॉक-कीपिंग यूनिट (SKU) को निर्दिष्ट करने की आवश्यकता है, यह .NET फ्रेमवर्क के संस्करण को इंगित करता है जो ऐप को लक्षित करता है। docs.microsoft.com/en-us/dotnet/framework/configure-apps/…

— bgcode

21

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

— Jelani
स्रोत

5

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

— जोश नू
स्रोत

5

मैं सिर्फ एक .NET MVC प्रोजेक्ट पर इस में भाग गया। मूल कारण NuGet पैकेज के परस्पर विरोधी संस्करण थे। मेरे पास कई परियोजनाओं के साथ एक समाधान था। प्रत्येक प्रोजेक्ट में कुछ नूगेट पैकेज थे। एक परियोजना में मेरे पास एंटरप्राइज़ लाइब्रेरी सिमेंटिक लॉगिंग पैकेज का एक संस्करण था, और दो अन्य परियोजनाओं में (जो कि पहले संदर्भ में) मेरे पास एक ही पैकेज के पुराने संस्करण थे। यह सभी त्रुटि के बिना संकलित करता है, लेकिन जब मैंने पैकेज का उपयोग करने की कोशिश की तो यह एक रहस्यमय "विधि नहीं मिली" त्रुटि दी।

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

— मार्क मेउर
स्रोत

5

अपने संदर्भ की जाँच करें!

सुनिश्चित करें कि आप अपने समाधान परियोजनाओं में समान तृतीय पक्ष पुस्तकालयों (केवल विश्वास संस्करणों, पथ को देखें) पर इंगित नहीं कर रहे हैं।

उदाहरण के लिए, यदि आप एक परियोजना में iTextSharp v.1.00.101 का उपयोग करते हैं और आप NuGet या संदर्भ iTextSharp v1.00.102 कहीं और करते हैं, तो आपको इस प्रकार की रनटाइम त्रुटियाँ मिलेंगी जो किसी न किसी तरह से आपके कोड में बदल जाती हैं।

मैंने एक ही DLL को इंगित करने के लिए सभी 3 परियोजनाओं में iTextSharp के लिए अपना संदर्भ बदल दिया और सब कुछ काम किया।

— Juls
स्रोत

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

— होन्जा पी।

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

— श्री टीए

4

यदि आपके स्वयं के NuGet सर्वर के साथ विकास हो रहा है, तो सुनिश्चित करें कि असेंबली संस्करण सभी समान हैं:

[assembly: AssemblyVersion("0.2.6")]
[assembly: AssemblyFileVersion("0.2.6")]
[assembly: AssemblyInformationalVersion("0.2.6")]

— सेनेट
स्रोत

मुझे इसकी जांच कैसे करनी चाहिए?

— सर्ज

मुझे लगता है कि nupkg में।

— सेनेट

4

भी .. अपनी परियोजनाओं या समाधान को "साफ" करने और फिर से बनाने की कोशिश करें!

— user384080
स्रोत

3

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

— ली बेली
स्रोत

3

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

अपने समाधानों को फिर से बनाने / स्वच्छ / पुनर्परिभाषित करने की आवश्यकता होने से पहले अन्य सभी परियोजनाओं पर संदर्भ देखें।

— जेमी ल्यूपटन
स्रोत

2

मेरे मामले में यह एक कॉपी / पेस्ट समस्या थी। मैंने किसी तरह अपनी मैपिंग प्रोफ़ाइल के लिए निजी निर्माता के साथ काम किया:

using AutoMapper;

namespace Your.Namespace
{
    public class MappingProfile : Profile
    {
        MappingProfile()
        {
            CreateMap<Animal, AnimalDto>();
        }
    }
}

(ctor के सामने लापता "जनता" पर ध्यान दें)

जो पूरी तरह से ठीक संकलित है, लेकिन जब AutoMapper प्रोफ़ाइल को तुरंत बनाने की कोशिश करता है तो वह (निश्चित रूप से!) कंस्ट्रक्टर को ढूंढ नहीं सकता है!

— DaBeSoft
स्रोत

@RenaudGauthier शायद जॉन स्कैट्स के उत्तर में कुछ गलत था, लेकिन वह बताता है कि कोई एक्सेस संशोधक वाली कक्षाएं आंतरिक नहीं हैं, और टिप्पणियों में वह शाब्दिक रूप से कहता है "नहीं। यह नहीं है। यदि आप एक निर्माता की घोषणा करते हैं और एक पहुंच को निर्दिष्ट नहीं करते हैं, तो यह होगा। निजी हो। सी # कल्पना की धारा 10.3.5 देखें। इसलिए मुझे लगता है कि मेरा कंस्ट्रक्टर आखिर निजी है? कृपया मुझे सही करें अगर मैं गलत हूं। और हाँ मेरा answeer संदर्भ से बाहर था, मैं यहाँ एक और प्रश्न से आया था (जो मेरे लिए कोई उत्तर प्रदान नहीं करता था)। मैं वहां भी अपने जवाब के लिए एक लिंक जोड़ूंगा।

— DaBeSoft

आप बिल्कुल सही हैं, मुझे कोई बात नहीं, मैंने बेकार टिप्पणी को हटा दिया है।

— रेनॉड गौथियर

1

मेरे पास एक समान परिदृश्य था जहां मुझे वही अपवाद दिया जा रहा था। उदाहरण के लिए, DAL और DAL.CustSpec के नाम पर मेरे वेब एप्लिकेशन सॉल्यूशन में मेरे दो प्रोजेक्ट थे। DAL प्रोजेक्ट में Method1 नाम का एक तरीका था, लेकिन DAL.CustSpec ने नहीं किया। मेरी मुख्य परियोजना में डीएएल परियोजना का संदर्भ था और एक अन्य परियोजना का संदर्भ भी था जिसका नाम है एक अन्य परियोजना। मेरे मुख्य प्रोजेक्ट ने Method1 को कॉल किया। अदरप्रोज़ परियोजना के पास DAL.CustSpec परियोजना का संदर्भ था, न कि DAL परियोजना का। बिल्ड कॉन्फ़िगरेशन में DAL और DAL.CustSpec दोनों प्रोजेक्ट्स को कॉन्फ़िगर किया गया था। सब कुछ बन जाने के बाद, मेरी वेब एप्लिकेशन परियोजना के बिन फ़ोल्डर में एक औरप्रोज और डीएएल असेंबली थी। हालाँकि, जब मैंने वेबसाइट चलाई, तो वेबसाइट के लिए अस्थाई ASP.NET फ़ोल्डर में DAL.CustSpec असेंबली थी, न कि DAL असेंबली में, किसी कारण के लिए। बेशक, जब मैंने Method1 नामक भाग को चलाया, तो मुझे "Method not found" त्रुटि मिली।

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

मुझे लगा कि मैं भविष्य में किसी और की मदद करने के मामले में इसे साझा करूंगा।

— रॉन कानूनगी
स्रोत

1

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

— Irshu
स्रोत

1

मैंने अपने परिवर्तनों के साथ एक समतल जगह बनाकर और अपने कार्यक्षेत्र में TFS पॉवर टूल्स 'स्कोरर' चलाकर ( https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f ) को हल किया । तब मैंने बदलावों को अनसुना कर दिया और परियोजना को फिर से शुरू किया। इस तरह आप किसी भी 'हैंगिंग-पार्टियों' की सफाई करेंगे जो आपके कार्यक्षेत्र में हो सकती है और एक नए सिरे से स्टार्टअप करेगी। यह जरूर है, कि आप TFS का उपयोग कर रहे हैं।

— fbastian
स्रोत

1

यह भी संभव है कि समस्या एक पैरामीटर या वापसी प्रकार के साथ है जो गायब होने की रिपोर्ट की गई है, और प्रति "गायब" विधि ठीक है।

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

— सर्व-कुंची
स्रोत

1

Costura.Fody 1.6 और 2.0 का उपयोग करना:
समय का एक गुच्छा बर्बाद करने के बाद काम नहीं कर रहे अन्य सभी संभावित समाधानों के साथ इस तरह की त्रुटि को देखते हुए, मैंने पाया कि जिस DLL को मैं एम्बेड कर रहा था उसका एक पुराना संस्करण उसी निर्देशिका में था, जिसे मैं चला रहा था नव संकलित .exe से जाहिरा तौर पर यह पहले उसी निर्देशिका में एक स्थानीय फ़ाइल की तलाश करता है, फिर अपनी एम्बेडेड लाइब्रेरी की तरफ देखता है। पुराने डीएलएल को हटाने का काम किया।

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

— grep65535
स्रोत

1

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

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

1

यदि समस्या GAC में असेंबली के पुराने संस्करण के कारण होती है ।
यह मदद कर सकता है: कैसे करें: वैश्विक असेंबली कैश से एक असेंबली निकालें ।

— यामागीन फर्स्ट
स्रोत

1

मेरे मामले में, MissingMethodException एक विधि के लिए थी जो एक ही फ़ाइल में थी!

हालाँकि, मैंने अभी-अभी एक NuGet पैकेज जोड़ा है जो .Net Standard2 का उपयोग मेरी 4.7.1-लक्ष्यीकरण परियोजना में करता है, जो System.Net.Http (4.7.1: संस्करण 4.0.0.0) के लिए एक संस्करण संघर्ष का कारण बनता है। .NET का उपयोग करके NuGet पैकेज मानक 2 4.2.0.0 चाहता है)। यह ज्ञात समस्याएँ हैं जो 4.7.2 में बेहतर होनी चाहिए (नोट 2 देखें) ।

मैंने अपनी अन्य सभी परियोजनाओं में इस तरह एक बाध्यकारी पुनर्निर्देशन का उपयोग किया था, क्योंकि इसके अपवाद थे जैसे ही इसने 4.2.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>

इस एक परियोजना को छोड़कर, जहां ऐसा लगता है कि यह System.Net.Http को लोड करने का प्रयास करता है केवल एक स्थानीय फ़ंक्शन को कॉल करते समय जो System.Net.Http.Http.HesppResponseMessage का उपयोग करता है क्योंकि यह पैरामीटर या रिटर्न प्रकार है (डिबगिंग के दौरान पैरामीटर, जब मैं चलता हूं तो वापस आ जाता हूं) डिबगर के बिना परीक्षण, थोड़ा अजीब भी है)। और एक संदेश दिखाने के बजाय कि यह System.Net.Http के 4.2.0.0 संस्करण को लोड नहीं कर सका, यह इस अपवाद को वापस करता है।

— Legolas
स्रोत

0

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

मैंने एक साफ और पुनर्निर्माण किया और नोट किया कि यह दो परियोजनाओं को छोड़ रहा था। जब मैंने उनमें से एक का पुनर्निर्माण किया, तो एक त्रुटि थी कि मैंने एक समारोह कहाँ शुरू किया और इसे समाप्त नहीं किया।

इसलिए वीएस एक मॉडल का उल्लेख कर रहा था जिसे मैंने मुझसे पूछे बिना लिखा था कि क्या मैं ऐसा करना चाहता हूं।

— TheWizardOfTN
स्रोत

0

बस मामले में यह किसी की मदद करता है, हालांकि यह एक पुराना मुद्दा है, मेरी समस्या थोड़ी अजीब थी।

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

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

— रेनाटो चेंकिंस्की
स्रोत

0

मैं इस मुद्दे में भाग गया, और यह मेरे लिए क्या था एक परियोजना एक सूची का उपयोग कर रही थी जो उदाहरण में थी। सेंसर नेमस्पेस और एक अन्य प्रकार ने ISensorInfo इंटरफ़ेस को लागू किया। वर्ग Type1SensorInfo, लेकिन यह वर्ग उदाहरण Sensors.Type1 में नामस्थान में एक परत गहरी थी। जब सूची में Type1SensorInfo को deserialize करने की कोशिश की जा रही है, तो उसने अपवाद को फेंक दिया। जब मैंने ISensorInfo इंटरफ़ेस में Example.Sensors.Type1 का उपयोग करके जोड़ा, तो कोई और अपवाद नहीं!

namespace Example
{
    public class ConfigFile
    {
        public ConfigFile()
        {
            Sensors = new List<ISensorInfo<Int32>>();
        }
        public List<ISensorInfo<Int32>> Sensors { get; set; }
     }
   }
}

**using Example.Sensors.Type1; // Added this to not throw the exception**
using System;

namespace Example.Sensors
{
    public interface ISensorInfo<T>
    {
        String SensorName { get; }
    }
}

using Example.Sensors;

namespace Example.Sensors.Type1
{
    public class Type1SensorInfo<T> : ISensorInfo<T>
    {
        public Type1SensorInfo() 
    }
}

— स्टीवन कोक्सलीन
स्रोत

0

जब मैंने पृष्ठभूमि में कई MSBuild प्रक्रियाएँ चल रही थीं, जो प्रभावी रूप से दुर्घटनाग्रस्त हो गईं (उनके पास कोड के पुराने संस्करणों के संदर्भ थे) तो मेरे पास वही बात थी। मैंने वीएस को बंद कर दिया और प्रक्रिया एक्सप्लोरर में सभी MSBuild प्रक्रियाओं को मार डाला और फिर पुन: संकलित किया।

— bytedev
स्रोत

0

मेरे पास एक परीक्षण परियोजना थी जो 2 अन्य परियोजनाओं को संदर्भित करती है जो प्रत्येक एक ही dll के विभिन्न संस्करणों (अलग-अलग स्थानों में) का संदर्भ देती है। इससे कंपाइलर भ्रमित हो गया।

— nuander
स्रोत

0

मेरे मामले में Spotify.exe उसी पोर्ट का उपयोग कर रहा था जिसे मेरी वेब एपीआई परियोजना एक विकास मशीन पर उपयोग करना चाहती थी। पोर्ट नंबर 4381 था।

मैं Spotify छोड़ दिया और सब कुछ फिर से अच्छी तरह से काम :)

— अरदा बसोगलु
स्रोत

0

मुझे यह समस्या तब हुई जब विधि को एक पैरामीटर की आवश्यकता थी जिसे मैं निर्दिष्ट नहीं कर रहा था

— भगवान डार्थ वडेर
स्रोत

0

मेरे मामले में, कोई भी कोड परिवर्तन नहीं हुआ था और अचानक सर्वर में से एक को यह मिलना शुरू हो गया और केवल इस अपवाद (सभी सर्वरों में समान कोड है, लेकिन केवल एक ही समस्या होने लगी):

System.MissingMethodException: Method not found: '?'.

ढेर:

Server stack trace: 
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at myAccountSearch.AccountSearch.searchtPhone(searchtPhoneRequest request)
   at myAccountSearch.AccountSearchClient.myAccountSearch.AccountSearch.searchtPhone(searchtPhoneRequest request)
   at myAccountSearch.AccountSearchClient.searchtPhone(String ID, String HashID, searchtPhone Phone1)
   at WS.MyValidation(String AccountNumber, String PhoneNumber)

जिस मुद्दे पर मेरा मानना है कि AppPool को दूषित किया गया था - हमारे पास प्रत्येक दिन 3 बजे AppPool पुनर्चक्रण चल रहा है और यह मुद्दा सुबह 3 बजे शुरू हुआ और फिर अगले दिन 3 बजे समाप्त हुआ।

— जॉर्ज
स्रोत

0

Microsoft से एक संदर्भ बग होना चाहिए।

मैंने साफ किया, अपने सभी पुस्तकालयों पर पुनर्निर्माण किया और अभी भी वही समस्या है और इसे हल नहीं कर सका।

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

यह बहुत निराशाजनक है कि इस तरह के एक साधारण मुद्दे को ठीक करने में इतना समय लग सकता है क्योंकि आप यह नहीं सोचेंगे कि यह कुछ ऐसा होगा।

— जयजय बरनार्ड
स्रोत

0

मेरे मामले में, मेरी परियोजना संदर्भित थी Microsoft.Net.Compilers.2.10.0। जब मैंने इसे स्विच किया Microsoft.Net.Compilers.2.7.0, तो त्रुटि चली गई। इस तरह के कारणों के साथ एक रहस्यमय त्रुटि क्या है।

— jaycer
स्रोत