System.MissingMethodException: Yöntem bulunamadı?

Bir zamanlar asp.net webforms uygulamasında ne çalışıyordu şimdi bu hatayı atıyor:

System.MissingMethodException: Yöntem bulunamadı

DoThisYöntem aynı sınıfta olduğunu ve çalışması gerekir.

Ben böyle bir genel işleyici var:

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

    public void DoThis()
    {
    //
    }
}

Bu, hala bir yerde kalan bir DLL'nin eski bir sürümü olduğunda ortaya çıkabilecek bir sorundur. En son derlemelerin konuşlandırıldığından ve bazı klasörlerde yinelenen eski derlemelerin gizlenmediğinden emin olun. Yapabileceğiniz en iyi şey, inşa edilen her öğeyi silmek ve tüm çözümü yeniden oluşturmak / yeniden yerleştirmek olacaktır.

Nug️ Yanlış Nuget Paket Sürümü ⚠️

Ben şirketlerimizin iç EF Nuget veri erişim paketi ve çekerek bir birim test proje vardı o kod çekilmiş olan versiyonudur harici paketin yolu güncel sürümü arkasında.

Sorun paket için Nuget ayarlarının least version; ve eski sürümü kazandı ve operasyonlar sırasında kullanıldı ....

Bu nedenle , hem paket hem de uygulama tarafından kullanılan ortak bir montaj için sessizce yanlış sürümü aldı.

💡 Çözüm 💡

Nuget'teki paketi En son kullanmak ve [almak] için ayarlayarak / güncelleyerek sorunu düzeltti.

Sunucuya doğru .NET Framework sürümünü yükleyerek bu sorunu çözdüm. Web sitesi sürüm 4.0 altında çalışıyordu ve çağırdığı derleme 4.5 için derlendi. .NET Framework 4.5 yüklendikten ve web sitesini 4.5 sürümüne yükselttikten sonra, hepsi iyi çalışır.

Visual Studio'yu yeniden başlatmak aslında benim için düzeltti. Hala kullanımda olan eski montaj dosyaları neden olduğunu düşünüyorum ve bir "Temiz Build" gerçekleştirme veya VS yeniden başlatma sorunu çözmelidir.

Bu bana aynı derleme, ayrı bir dll başvurulan bir dosya ile oldu. Dosyayı projeden hariç tutup tekrar ekledikten sonra her şey yolunda gitti.

Ben sadece bir .NET MVC projesinde karşılaştım. Temel neden, NuGet paketlerinin çakışan sürümleriydi. Birkaç projeyle bir çözüm buldum. Her projenin bazı NuGet paketleri vardı. Bir projede Enterprise Library Semantic Logging paketinin bir sürümü vardı ve diğer iki projede (ilkine gönderme yapan) aynı paketin eski sürümleri vardı. Her şey hatasız derler, ancak paketi kullanmaya çalıştığımda gizemli bir "Yöntem bulunamadı" hatası verdi.

Çözüm, eski NuGet paketlerini iki projeden kaldırmaktı, böylece sadece gerçekten ihtiyaç duyulan tek projeye dahil edildi. (Ayrıca tüm çözümü temiz bir şekilde yeniden yaptım.)

Referanslarınızı kontrol edin!

Çözüm projelerinizde sürekli olarak aynı üçüncü taraf kitaplıklarını (yalnızca sürümlere güvenmeyin, yola bakın) işaret ettiğinizden emin olun.

Örneğin, bir projede iTextSharp v.1.00.101 kullanıyorsanız ve NuGet'e veya iTextSharp v1.00.102'ye başka bir yerde başvuruyorsanız, bir şekilde kodunuza damlayan bu tür çalışma zamanı hataları alırsınız.

Ben aynı DLL işaret etmek için her 3 projede iTextSharp benim referans değişti ve her şey çalıştı.

Kendi NuGet sunucunuzla geliştirme yapıyorsanız, montaj sürümlerinin aynı olduğundan emin olun:

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

Ayrıca .. proje veya çözüm "temiz" çalışın ve tekrar inşa!

Kapatıp tekrar açmayı denediniz mi? Şaka bir yana, bilgisayarımı yeniden başlatmak benim için hile yaptı ve diğer cevapların hiçbirinde bahsedilmedi.

Ben sadece bu sorunu yaşadım ve bunun nedeni benim UI projesinden DLL önceki bir sürümünü referans olduğu ortaya çıktı. Bu nedenle, derlerken mutluydu. Ancak çalıştırırken DLL'in önceki sürümünü kullanıyordu.

Çözümlerinizi yeniden oluşturmanız / temizlemeniz / yeniden konuşlandırmanız gerektiğini varsaymadan önce diğer tüm projelerin referanslarını kontrol edin.

Benim durumumda bir kopyalama / yapıştırma sorunu vardı. Eşleme profilim için bir şekilde ÖZEL bir yapıcı buldum:

using AutoMapper;

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

(kasanın önündeki eksik "kamuoyunu" not edin)

Bu da mükemmel bir şekilde derlendi, ancak AutoMapper profili somutlaştırmaya çalıştığında (elbette!) yapıcıyı bulamıyor!

Ben de aynı istisnayı atılmaya benzer bir senaryo vardı. Web uygulama çözümümde DAL ve DAL.CustSpec örneklerinden oluşan iki projem vardı. DAL projesinin Method1 adlı bir yöntemi vardı, ancak DAL.CustSpec yoktu. Ana projemin DAL projesine ve başka bir projeye AnotherProj adlı bir referansı vardı. Ana projem Yöntem1'i çağırdı. AnotherProj projesinin DAL projesine değil, DAL.CustSpec projesine bir referansı vardı. Derleme yapılandırmasında hem DAL hem de DAL.CustSpec projeleri oluşturulacak şekilde yapılandırıldı. Her şey oluşturulduktan sonra, web uygulama projemde Bin klasöründe AnotherProj ve DAL derlemeleri vardı. Ancak, web sitesini çalıştırdığımda, web sitesinin Geçici ASP.NET klasörü DAL derlemesinde değil dosyalarında DAL.CustSpec derlemesine sahipti, bazı sebeplerden dolayı. Tabii ki, Method1 adlı bölümü çalıştırdığımda, "Yöntem bulunamadı" hatası aldım.

Bu hatayı düzeltmek için ne yapmak zorunda DAL.CustSpec AnotherProj projedeki başvurusunu sadece DAL olarak değiştirmek, Geçici ASP.NET Dosyaları klasöründeki tüm dosyaları silmek ve sonra web sitesini yeniden oldu. Bundan sonra her şey çalışmaya başladı. Ayrıca, Yapılandırma Yapılandırması'nın işaretini kaldırarak DAL.CustSpec projesinin oluşturulmadığından emin oldum.

Gelecekte başka birine yardım etmesi durumunda bunu paylaşacağımı düşündüm.

ASP.NET web sitemde de aynı durumla karşılaştım. Yayınlanan dosyaları sildim, VS'yi yeniden başlattım, projeyi tekrar temizledim ve yeniden oluşturdum. Bir sonraki yayından sonra hata giderildi ...

Değişikliklerimle bir raf seti oluşturarak ve çalışma alanımda TFS Elektrikli El Aletleri 'kavrulma' çalıştırarak bu sorunu çözdüm ( https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f ). Sonra değişiklikleri kaldırdım ve projeyi yeniden derledim. Bu şekilde, çalışma alanınızda olabilecek ve asılı partileri temizleyecek ve yeni bir partiyle başlayacaksınız. Bu, elbette, TFS kullandığınızı gerektirir.

Ayrıca, sorunun eksik olarak bildirilen yöntemin bir parametresi veya dönüş türüyle ilgili olması ve "eksik" yöntemin iyi olması da mümkündür.

Benim durumumda olan buydu ve yanıltıcı mesaj, sorunu çözmek için daha uzun sürdü. Bir parametrenin türünün GAC'da daha eski bir sürümü olduğu için derleme ortaya çıktı, ancak eski sürüm, kullanılan sürüm numaralandırma şemalarındaki bir değişiklik nedeniyle aslında daha yüksek bir sürüm numarasına sahipti. Bu eski / daha yüksek sürümün GAC'den kaldırılması sorunu çözdü.

Costura.Fody 1.6 ve 2.0 kullanarak: Çalışmayan
tüm diğer potansiyel çözümler ile aynı tür bir hata bakarak bir sürü zaman harcadıktan sonra, gömdüğüm DLL'nin eski bir sürümünün çalıştırdığım aynı dizinde olduğunu buldum yeni derlenmiş .exe. Görünüşe göre önce aynı dizinde yerel bir dosya arar, sonra gömülü kütüphanesine içe doğru bakar. Eski DLL silmek silindi.

Açıkçası, benim referans eski bir DLL işaret değildi, eski bir DLL kopyasını benim uygulama üzerinde derlenmiş olandan ayrı bir sistemde test edildi dizinde oldu.

Benim durumumda yolu açıkça bir şekilde dahil edildi, ancak aynı DLL'lerin çeşitli sürümleri çakışan olmasına rağmen benim .csproj dosyasında başvurulan aynı adı eski DLL'leri olan bir klasör oldu.

Sorunun GAC'deki derlemenin eski bir sürümünden kaynaklanması durumunda .
Bu yardımcı olabilir: Nasıl yapılır: Genel Montaj Önbelleği'nden bir Montajı Kaldırma .

Benim durumumda, MissingMethodException aynı dosyadaki bir yöntem içindi!

Ancak, 4.7.1 hedefleme projeme .Net Standard2 kullanan bir NuGet paketi ekledim, bu da System.Net.Http (4.7.1: sürüm 4.0.0.0, .NET kullanan sürüm çakışması) Standart 2 4.2.0.0'ı istiyor). Bu , 4.7.2'de daha iyi olması gereken bilinen konular gibi görünmektedir (not 2'ye bakınız) .

Diğer tüm projelerimde böyle bir bağlayıcı yönlendirme kullanmıştım, çünkü sahip olmadığım 4.2.0.0'ı yüklemeye çalışır çalışmaz istisnalar vardı:

  <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>

Sadece o System.Net.Http yüklenmeye çalışıyor görünüyor bu bir projeye hariç ederken yerel işlevini çağırarak that use ayıklama sırasında 's parametresi veya dönüş türü (parametre, ben koşmak dönüş türü olarak bir System.Net.Http.HttpResponseMessage hata ayıklayıcı olmadan testler de biraz garip). Ve System.Net.Http'nin 4.2.0.0 sürümünü yükleyemediğine dair bir ileti göstermek yerine, bu özel durumu döndürür.

Bu MVC4 kullanarak bana oldu ve ben hata atılan nesneyi yeniden adlandırmak için bu iş parçacığı okuduktan sonra karar verdi.

Bir temizlik yaptım ve iki projeyi atladığını belirttim. Bunlardan birini yeniden inşa ettiğimde, bir işlevi başlattığım ve bitirmediğim bir hata oluştu.

VS, bunu yapmak isteyip istemediğimi sormadan yeniden yazdığım bir modele atıfta bulundu.

Kimseye yardım etmesi durumunda, eski bir sorun olmasına rağmen, sorunum biraz garipti.

Jenkins kullanırken bu hatayla karşılaştım.

Sonunda sistem tarihinin manuel olarak gelecekteki bir tarihe ayarlandığını öğrendim, bu da dll'nin bu gelecekteki tarihle derlenmesine neden oldu. Tarih normale döndüğünde, MSBuild dosyanın daha yeni olduğunu ve projenin yeniden derlenmesini gerektirmediğini yorumladı.

Bu sorunla karşılaştım ve benim için olan bir örnek, Örnek.Sensors ad alanında olan bir Liste kullanmaktı ve başka bir tür de ISensorInfo arabirimini uyguladı. Sınıf Type1SensorInfo, ancak bu sınıf, example.Sensors.Type1 adresindeki ad alanında bir kat daha derinde idi. List1SensorInfo listeden serisini kaldırmaya çalışırken, istisna attı. ISensorInfo arabirimine Sample.Sensors.Type1 kullanarak eklediğimde, artık bir istisna yok!

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() 
    }
}

Ben etkili bir şekilde çöktü arka planda çalışan MSBuild işlemleri bir dizi vardı aynı şey yaşadım (kod eski sürümleri referansları vardı). VS'yi kapattım ve işlem gezginindeki tüm MSBuild süreçlerini öldürdüm ve sonra yeniden derledim.

Her biri aynı dll farklı sürümleri (farklı yerlerde) başvuru 2 proje referans bir test projesi vardı. Bu derleyiciyi karıştırdı.

Benim durumumda spotify.exe, web api projemin bir geliştirme makinesinde kullanmak istediği bağlantı noktasını kullanıyordu. Bağlantı noktası numarası 4381 idi.

Spotify'dan çıktım ve her şey tekrar iyi çalıştı :)

Yöntem belirtmediğim bir parametre gerektirdiğinde bu sorunu yaşadım

Benim durumumda, hiçbir kod değişikliği yoktu ve aniden sunuculardan biri bunu almaya başladı ve sadece bu istisna (tüm sunucular aynı koda sahip, ancak yalnızca bir tanesi sorun yaşamaya başladı):

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

Stack:

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)

İnanıyorum sorun AppPool bozuldu - biz her gün 03:00 'de devam AppPool geri dönüşüm otomatik ve sorunu 3 am başladı ve ertesi gün 03:00 kendi başına sona erdi.

Microsoft'tan bir referans hatası olmalıdır.

Temizledim, tüm kütüphanelerimi yeniden inşa ettim ve hala aynı sorunu aldım ve bunu çözemedim.

Yaptığım tek şey Visual Studio Uygulamasını kapatmak ve tekrar açtı. Hile yaptı.

Böyle basit bir sorunun düzeltilmesi bu kadar uzun sürebilir, çünkü böyle bir şey olacağını düşünmezsiniz.

Benim durumumda, projem referans veriyordu Microsoft.Net.Compilers.2.10.0. Bunu değiştirdiğimde Microsoft.Net.Compilers.2.7.0hata ortadan kalktı. Böyle çeşitli nedenlerle ne gizemli bir hata.