TypeLoadException 'uygulama yok' diyor, ancak uygulanıyor

Test makinemizde çok garip bir hata var. Hata:

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

Nedenini anlayamıyorum. sınıfta SetShortvar DummyItemve ben sadece bir dağıtım / sürüm sorunu olmadığından emin olmak için olay günlüğüne yazma içeren bir sürümü yeniden derledim. Garip olan şey, arama kodunun SetShortyöntemi bile çağırmamasıdır .

NOT - Bu yanıt size yardımcı olmazsa, lütfen insanların o zamandan beri eklediği diğer yanıtları aşağı kaydırın.

Kısa cevap

Bu, bir derlemedeki bir arabirime ve sonra başka bir derlemedeki bir uygulama sınıfına yöntem eklerseniz, ancak arabirim derlemesinin yeni sürümüne başvurmadan uygulama derlemesini yeniden oluşturursanız oluşabilir.

Bu durumda, DummyItem başka bir montajdan bir arayüz uygular. SetShort yöntemi yakın zamanda hem arabirime hem de DummyItem'e eklenmiştir - ancak DummyItem içeren derleme arabirim derlemesinin önceki sürümüne başvurularak yeniden oluşturulmuştur. SetShort yöntemi etkili bir şekilde oradadır, ancak sihirli sos, arayüzdeki eşdeğer yönteme bağlanmaz.

Uzun cevap

Bunu yeniden oluşturmayı denemek istiyorsanız aşağıdakileri deneyin:

1. Bir sınıf kütüphanesi projesi oluşturun: InterfaceDef, sadece bir sınıf ekleyin ve derleyin:

   public interface IInterface
   {
       string GetString(string key);
       //short GetShort(string key);
   }
   

2. İkinci bir kütüphane projesi oluşturun: Uygulama (ayrı bir çözümle), InterfaceDef.dll dosyasını proje dizinine kopyalayın ve dosya referansı olarak ekleyin, sadece bir sınıf ekleyin ve derleyin:

   public class ImplementingClass : IInterface
   {
       #region IInterface Members
       public string GetString(string key)
       {
           return "hello world";
       }
   
       //public short GetShort(string key)
       //{
       //    return 1;
       //}
       #endregion
   }
   

3. Üçüncü bir konsol projesi oluşturun: ClientCode, iki dll dosyasını proje dizinine kopyalayın, dosya referanslarını ekleyin ve Main yöntemine aşağıdaki kodu ekleyin:

    IInterface test = new ImplementingClass();
    string s = test.GetString("dummykey");
    Console.WriteLine(s);
    Console.ReadKey();
   

4. Kodu bir kez çalıştırın, konsol "merhaba dünya" diyor

5. Iki dll projelerde kodu uncomment ve yeniden - iki dll geri ClientCode projeye kopyalayın, yeniden oluşturmak ve tekrar çalıştırmayı deneyin. TypeLoadException, ImplementingClass örneğini başlatmaya çalışırken oluşur.

Sorucunun kendi cevabının daha önce belirttiğine ek olarak, aşağıdakileri belirtmeye değer olabilir. Bunun olmasının nedeni, bir sınıfın bu yöntemi uygulamadan bir arabirim yöntemiyle aynı imzalı bir yönteme sahip olabilmesidir. Aşağıdaki kod şunu göstermektedir:

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

Uygulamam kullanılan hata iletisinde yöntem bir sınıf tanımlayan başka bir derleme başvuru yoktu bunu aldım. PEVerify'ı çalıştırmak daha faydalı bir hata verdi: "Sistem belirtilen dosyayı bulamıyor."

Aynı mesajla karşılaştım ve bulduğumuz şey: Projemizde üçüncü taraf dll'leri kullanıyoruz. Bunların yeni bir çıkışından sonra projemizi yeni dll setine işaret edecek şekilde değiştirdik ve başarıyla derledik.

Çalışma süresi boyunca arabirim sınıflarından birini oluşturmaya çalıştığımda istisna atıldı. Tüm diğer referansların güncel olduğundan emin olduk, ancak hala şans yok. Hata iletisindeki yöntemin dönüş türünün yeni, referanssız bir derlemeden tamamen yeni bir tür olduğunu tespit etmek için (Nesne Tarayıcısını kullanarak) bir süre ihtiyacımız vardı.

Derlemeye bir başvuru ekledik ve hata kayboldu.

• Hata mesajı oldukça yanıltıcıydı, ancak az çok doğru yöne işaret etti (doğru yöntem, yanlış mesaj).
• Söz konusu yöntemi kullanmadığımız halde istisna oluştu.
• Bu da beni şu soruya yönlendiriyor: Bu istisna her durumda atılırsa, derleyici neden almaz?

Bu hatayı aşağıdaki senaryoda aldım.

• Hem Meclis A hem de B, System.Web.Mvc Sürüm 3.0.0.0'a başvurdu
• A derlemesi, B derlemesine başvurdu ve B derlemesinden System.Web.Mvc sınıflarını döndüren yöntemlerle arabirimler uygulayan sınıflara sahipti.
• Derleme A, System.Web.Mvc Sürüm 4.0.0.0'a yükseltildi
• C Meclisi aşağıdaki kodu çalıştırmıştır (FertPin.Classes. Kontak A Meclisinde bulunuyordu):

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

Benim için düzeltme B montajında ​​System.Web.Mvc başvurusunu 4.0.0.0'a yükseltiyordu. Şimdi belli görünüyor!

Orijinal poster sayesinde!

Bu hatayı alabileceğiniz diğer bir zaman, imzalı bir montajın yanlış bir sürümüne sahipseniz. Bu nedenin normal belirtisi değil, ama işte aldığım senaryo buydu

• bir asp.net projesi A derlemesini ve B, B derlemesini içerir.

• montaj A, montaj C'yi yüklemek için Activator.CreateInstance kullanır (yani ayrı ayrı inşa edilen C'ye referans yoktur)

• C, B grubunun şu anda mevcut olandan daha eski bir versiyonuna referansla oluşturulmuştur

umarım birisine yardım eder - bunu anlamak benim yaşımı aldı.

Ben de bu hatayı vardı, bir x86 derleme başvuru herhangi bir CPU derlemeleri başvuru herhangi bir CPU exe neden oldu.

İstisna, MyApp.Interfaces'de (Any CPU) türetilen MyApp.Implementations (Any CPU) sınıfındaki bir yöntemden şikayet etti, ancak fuslogvw.exe'de MyApp'dan gizli bir 'programı yanlış formatla yükleme denemesi' buldum Her ikisi tarafından da kullanılan .CommonTypes (x86).

Ben buna geri dönüyorum ... Buradaki cevapların çoğu sorunun ne olduğunu açıklamak için harika bir iş çıkarıyor ama nasıl düzeltileceğini değil.

Bunun çözümü, projelerinizin yayınlanmış dizinindeki bin dosyalarını el ile silmektir. Tüm başvuruları temizler ve projeyi en son DLL'leri kullanmaya zorlar.

IIS araçlarını atma eğiliminde olduğundan, yayımlama araçları Sil işlevini kullanmanızı önermiyorum.

Bu hata iletisine başka bir ezoterik çözüm daha var. Hedef çerçevemi .Net 4.0'dan 4.6'ya yükselttim ve birim sınama projem, oluşturmaya çalıştığımda "System.TypeLoadException ... bir uygulama yok" hatası veriyordu. Ayrıca, "BuildShadowTask" görevi beklenmedik bir şekilde başarısız oldu "diyen aynı uygulanmayan yöntem hakkında ikinci bir hata iletisi verdi. Buradaki tavsiyelerin hiçbiri yardımcı görünmüyordu, bu yüzden "BuildShadowTask" araması yaptım ve MSDN'de bir yazı test projesinin csproj dosyasından bu satırları silmek için bir metin editörü kullanmamı sağlayan bir yazı buldum.

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

Bundan sonra her iki hata da ortadan kalktı ve proje inşa edildi.

Bu hatayı Autofac ve çok sayıda dinamik derleme yüklemesi kullandığım bir bağlamda karşılaştım.

Bir Autofac çözünürlük işlemi gerçekleştirilirken, çalışma zamanı montajlardan birini yükleyemez. Hata mesajı şikayet etti Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. Belirtiler bir Windows Server 2012 R2 VM'sinde çalışırken ortaya çıktı, ancak Windows 10 veya Windows Server 2016 VM'lerinde görülmedi .

ImplementationAssemblySystem.Collections.Immutable1.1.37'ye atıfta bulundu ve IMyInterface<T1,T2>ayrı olarak tanımlanan bir arayüzün uygulamalarını içeriyordu DefinitionAssembly. DefinitionAssemblyBaşvurulan System.Collections.Immutable1.1.36.

IMyInterface<T1,T2>"Uygulanmayan" yöntemler, içinde IImmutableDictionary<TKey, TRow>tanımlanmış tip parametrelerine sahipti System.Collections.Immutable.

System.Collections.ImmutableProgram dizininde bulunan asıl kopya , sürüm 1.1.37 idi. Windows Server 2012 R2 System.Collections.ImmutableVM'imde , GAC 1.1.36'nın bir kopyasını içeriyordu. Windows 10 ve Windows Server 2016'da GAC, System.Collections.Immutable1.1.37'nin bir kopyasını içeriyordu. Yükleme hatası yalnızca GAC ​​DLL'nin eski sürümünü içerdiğinde ortaya çıktı.

Bu nedenle, derleme yük arızasının temel nedeni, eşleşmeyen başvurulardı System.Collections.Immutable. Arayüz tanımı ve uygulaması aynı görünümlü yöntem imzalarına sahipti, ancak aslında farklı sürümlerine bağlıydı, System.Collections.Immutablebu da çalışma zamanının arayüz sınıfıyla eşleşmesi için uygulama sınıfını dikkate almadığı anlamına geliyordu.

Uygulama yapılandırma dosyama aşağıdaki bağlama yönlendirmesini eklemek sorunu çözdü:

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

Bunu bir "elmas" şekilli proje bağımlılığı ile aldım:

• Proje A, Proje B ve Proje D'yi kullanır
• B Projesi, D Projesi'ni kullanıyor

Proje A'yı yeniden derledim, ancak Proje B'nin Proje B dll'sinin eski sürümünü "enjekte etmesine" izin veren Proje B'yi yeniden derlemedim

Bir ASP.NET projesi tarafından bağlı bir proje (ve derleme adı), yeniden adlandırdığımda bu karşılaştı. Web projesindeki türler bağımlı derlemede arabirimler uygular. Build menüsünden Clean Solution uygulamasına rağmen önceki adla derleme binklasörde ve web projem yürütüldüğünde kaldı

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

Yukarıdaki istisna atıfta bulunarak, uygulama web türlerindeki arayüz yöntemlerinin gerçekte uygulanmadığından şikayet edilmiştir. Web projesinin binklasöründeki derlemeyi el ile silmek sorunu çözdü.

Daha önce derlemelerden biri için birim sınaması sırasında Kod Kapsamını etkinleştirdiğimde de bu hatayı aldım. Nedense Visual Studio, arabirimin yeni bir sürümünü uygulamak için güncelleştirmiş olsa bile bu DLL'nin eski sürümünü "arabelleğe aldı". Kod Kapsamını devre dışı bırakmak hatayı ortadan kaldırdı.

Bu hata, Assembly.LoadFrom (String) kullanılarak bir derleme yüklüyse ve Assembly.Load (Byte []) kullanılarak önceden yüklenmiş bir derlemeye başvuruyorsa da oluşabilir.

Örneğin, ana uygulamanın başvurulan derlemelerini kaynak olarak gömdünüz, ancak uygulamanız belirli bir klasörden eklentileri yüklüyor.

LoadFrom kullanmak yerine Load kullanmalısınız. Aşağıdaki kod işi yapacak:

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

Yönetilen C ++ ile ilgili bu tür bir sorun için başka bir açıklama.

Özel bir imzası olan yönetilen C ++ kullanılarak oluşturulan bir derlemede tanımlanan bir arabirimi saplamaya çalışırsanız, saplama oluşturulduğunda istisna elde edersiniz.

Bu Rhino Mocks ve muhtemelen kullanılan herhangi bir alaycı çerçeve için geçerlidir System.Reflection.Emit.

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

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

Arayüz tanımı aşağıdaki imzayı alır:

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

Not C ++ tipi olduğu longeşleştiren System.Int32(veya basitçe intC #). Rhino Mocks posta listesinde Ayende Rahien'in belirttiği gibimodopt soruna neden olan biraz belirsiz .

Bir çözümü MVC3'ten MVC5'e yükselttim ve Unit test projemden aynı istisnayı almaya başladım.

Eski dosyaları arayan tüm referansları kontrol, sonunda birim test projemde Mvc için bazı ciltlemeRedirects yapmak gerektiğini keşfetti.

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

Benim durumumda WinForms Araç Kutusu'nun sıfırlanmasına yardımcı oldu.

FormTasarımcıda a'yı açarken istisna buldum ; ancak, kodun derlenmesi ve çalıştırılması mümkündür ve kod beklendiği gibi davranır. İstisna UserControl, başvurulan kütüphanelerimden birinden bir arabirim uygulayarak yerel olarak meydana geldi . Bu kitaplık güncellendikten sonra hata oluştu.

Bu UserControl, WinForms araç kutusunda listelenmiştir. Muhtemelen Visual Studio, kitaplığın eski bir sürümü için bir referans tuttu veya eski bir sürümü bir yerde önbelleğe alıyordu.

İşte bu durumdan nasıl kurtuldum:

1. WinForms Araç Kutusu'na sağ tıklayın Reset Toolboxve içerik menüsünde üzerine tıklayın . (Bu, özel öğeleri Araç Kutusu'ndan kaldırır).
   Benim durumumda, Araç Kutusu öğeleri varsayılan durumlarına geri yüklendi; ancak, Araç Kutusu'nda İşaretçi oku eksikti.
2. Visual Studio'yu kapatın.
   Benim durumumda Visual Studio bir ihlal istisnasıyla sona erdi ve iptal edildi.
3. Visual Studio'yu yeniden başlatın.
   Şimdi her şey yolunda gidiyor.

FWIW, başvurulan bir derlemenin varolmayan bir sürümüne yönlendirilen bir yapılandırma dosyası olduğunda bunu aldım. Kazanmak için Fusion günlükleri!

Bu hatayı aldım çünkü çerçevenin 4.5 sürümünde olan bir 'C' derlemesinde bir sınıfım vardı, çerçevenin 4.5.1 sürümünde olan 'A' derlemesinde bir arabirim uygulayarak ve derlemenin temel sınıfı olarak hizmet verdim Çerçevenin 4.5.1 sürümünde olan 'B'. 'B' montajını yüklemeye çalışırken sistem istisnayı attı. Ayrıca, her üç derlemede .net 4.5.1 hedefleyen bazı nuget paketleri yükledim. Nedense, nuget referansları 'B' meclisinde gösterilmese de, başarılı bir şekilde inşa ediliyordu.

Asıl mesele, meclislerin arayüzü içeren bir nuget paketinin farklı versiyonlarına atıfta bulunduğu ve arayüz imzasının versiyonlar arasında değiştiği ortaya çıktı.

Benim durumumda daha önce mylibrepo dışında bir kardeş klasördeki bir projeye başvurmuştum - bunu diyelim v1.0.

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

Daha sonra düzgün yaptım ve git alt modülü aracılığıyla kullandım - diyelim v2.0. consoleAppAncak bir proje düzgün şekilde güncellenmedi. Hala eski v1.0projeme git projemin dışında atıfta bulunuyordu .

Şaşırtıcı bir şekilde , *.csprojaçıkça yanlış olmasına ve işaret etmesine rağmen, v1.0Visual Studio IDE v2.0proje olarak yolu gösterdi ! F12 arayüzünü incelemek ve sınıfı da v2.0sürümüne gitti .

Derleyici tarafından bin klasörüne yerleştirilen derleme v1.0, dolayısıyla baş ağrısıydı.

IDE'nin bana yalan söylemesi, hatayı fark etmeyi daha da zorlaştırdı.

Çözüm : Proje referanslarını ConsoleAppsildi ve okudu.

Genel İpucu: Tüm montajları sıfırdan yeniden derleyin (mümkünse, nuget paketleri için olamaz) ve bin\debugklasördeki datetime damgalarını kontrol edin . Eski tarihli meclisler sizin probleminizdir.

Neredeyse aynı sorunla karşılaştım. Bu hataya neden olan şeyi başımı kaşıyordum. Çapraz kontrol ettim, tüm yöntemler uygulandı.

Google'da bu bağlantıyı diğerleri arasında aldım. @ Paul McLink yorumuna dayanarak, Bu iki adım sorunu çözdü.

1. Visual Studio'yu yeniden başlat
2. Temizle, Oluştur (Yeniden Oluştur)

ve hata gitti .

VS Eklentisini Yeniden Başlat

Teşekkürler Paul :)

Umarım bu hatayla karşılaşan birine yardımcı olur :)

Birim testlerimi çalıştırırken de bu sorunla karşılaştım. Uygulama iyi ve hatasız koştu. Benim durumumdaki sorunun nedeni, test projelerinin inşasını kapatmış olmamdı. Test projelerimin yeniden yapılandırılması sorunları çözdü.

Visual Studio Pro 2008'de, aynı proje, biri bir sınıf lib SDF.dll ve diğeri de derleme adı sdf.exe ile başvuruda bulunan derlemeler oluştururken Visual Studio Pro 2008'de gördüm. Referans derlemesinin adını değiştirdiğimde istisna ortadan kalktı

Bu, benim durumlarımda uygulama projesinin güncel olmadığı anlamına gelir. Arayüzü içeren DLL yeniden oluşturuldu, ancak uygulama dll bayat.

İşte bu hatayı almam.

Bir externyöntem eklendi , ancak macam hatalı. DllImportAttributeBir dışarı yorumladı satırda koymak.

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

Özniteliğin kaynağa gerçekten dahil edildiğinden emin olmak sorunu çözdü.

Bir WCF hizmetinde, x86 derleme türü seçildiğinden, depoların bin yerine x \ 86 altında yaşamasına neden olduğu için bunu aldım. Herhangi bir CPU seçmek yeniden derlenmiş DLL'lerin doğru yerlere gitmesine neden oldu (bunun ilk etapta nasıl olduğuna dair ayrıntıya girmeyeceğim).

Ben de aynı problemi yaşadım. Ana program tarafından yüklenen derlememin "Yerel Kopyala" doğru olarak ayarlanmış bazı referansları olduğunu anladım. Başvuruların bu yerel kopyaları, aynı klasördeki diğer başvuruları arıyordu; bu, diğer başvuruların "Yerel Kopyala" seçeneği yanlış olarak ayarlandığından mevcut değildi. "Yanlışlıkla" kopyalanan referansların silinmesinden sonra, ana program referansların doğru konumlarını arayacak şekilde ayarlandığı için hata giderildi. Görünüşe göre referansların yerel kopyaları, çağrı dizisini bertaraf etti, çünkü bu yerel kopyalar, ana programda bulunan orijinal kopyalar yerine kullanıldı.

Eve götür mesajı, gerekli montajı yüklemek için eksik bağlantı nedeniyle bu hatanın görünmesidir.

Benim durumumda, TypeBuilderbir tür oluşturmak için kullanmaya çalışıyordum . TypeBuilder.CreateTypebu istisnayı attı. Sonunda bir arabirimi uygulayan bir yöntem MethodAttributes.Virtualararken özniteliklere eklemek gerektiğini fark ettim TypeBuilder.DefineMethod. Bunun nedeni, bu bayrak olmadan, yöntemin arabirimi uygulamadan ziyade, aynı imzayla yeni bir yöntem (belirtmeden bile MethodAttributes.NewSlot) olmasıdır.

Ek olarak: Bu, sahte bir derleme oluşturmak için kullanılan bir nuget paketini güncelleştirirseniz de oluşabilir. Bir nuget paketinin V1.0'ını yüklediğinizi ve "fakeLibrary.1.0.0.0.Fakes" adlı sahte bir derleme oluşturduğunuzu varsayalım. Daha sonra, nuget paketinin en yeni sürümüne güncellersiniz, örneğin bir arayüze yeni bir yöntem ekleyen v1.1. Fakes kütüphanesi hala kütüphanenin v1.0'ını arıyor. Sahte düzeneği çıkarın ve yeniden oluşturun. Sorun buysa, bu muhtemelen düzeltecektir.

Son zamanlarda yapılan bir Windows güncellemesinden sonra bu hatayı aldım. Bir arabirimden devralmak üzere ayarlanmış bir hizmet sınıfım vardı. Arayüz, C # 'da oldukça yeni bir özellik olan ValueTuple döndüren bir imza içeriyordu.

Tahmin edebileceğim tek şey, Windows güncellemesinin yeni bir tane yüklediğini, ancak açık bir şekilde bağlandığını, bağlayıcı yönlendirmeleri güncellediğini, vb ...