TypeLoadException mengatakan 'tidak ada implementasi', tetapi ini diterapkan

Saya punya bug yang sangat aneh di mesin uji kami. Kesalahannya adalah:

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

Saya tidak bisa mengerti mengapa. SetShortada di DummyItemkelas, dan saya bahkan telah mengkompilasi ulang sebuah versi dengan menulis ke log peristiwa hanya untuk memastikan bahwa itu bukan masalah penyebaran / versi. Yang aneh adalah bahwa kode panggilan bahkan tidak memanggil SetShortmetode tersebut.

CATATAN - Jika jawaban ini tidak membantu Anda, luangkan waktu untuk menelusuri jawaban lain yang telah ditambahkan orang sejak saat itu.

Jawaban singkat

Ini bisa terjadi jika Anda menambahkan metode ke antarmuka dalam satu rakitan, dan kemudian ke kelas pelaksana di rakitan lain, tetapi Anda membangun kembali rakitan pelaksana tanpa merujuk ke versi baru dari rakitan antarmuka.

Dalam hal ini, DummyItem mengimplementasikan antarmuka dari perakitan lain. Metode SetShort baru-baru ini ditambahkan ke antarmuka dan DummyItem - tetapi perakitan yang berisi DummyItem dibangun kembali dengan merujuk pada versi sebelumnya dari perakitan antarmuka. Jadi metode SetShort ada di sana secara efektif, tetapi tanpa saus ajaib yang menghubungkannya dengan metode yang setara di antarmuka.

Jawaban panjang

Jika Anda ingin mencoba mereproduksi ini, coba yang berikut ini:

1. Buat proyek perpustakaan kelas: InterfaceDef, tambahkan hanya satu kelas, dan bangun:

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

2. Buat proyek perpustakaan kelas kedua: Implementasi (dengan solusi terpisah), salin InterfaceDef.dll ke direktori proyek dan tambahkan sebagai referensi file, tambahkan hanya satu kelas, dan bangun:

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

3. Buat yang ketiga, proyek konsol: ClientCode, salin kedua dll ke direktori proyek, tambahkan referensi file, dan tambahkan kode berikut ke dalam metode Utama:

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

4. Jalankan kode satu kali, konsol mengatakan "hello world"

5. Batalkan komentar kode dalam dua proyek dll dan bangun kembali - salin dua dll kembali ke proyek ClientCode, bangun kembali dan coba jalankan lagi. TypeLoadException terjadi ketika mencoba untuk instantiate ImplementingClass.

Selain apa yang sudah dijawab oleh si penanya, mungkin perlu diperhatikan hal-hal berikut. Alasan ini terjadi adalah karena kelas mungkin memiliki metode dengan tanda tangan yang sama dengan metode antarmuka tanpa menerapkan metode itu. Kode berikut menggambarkan bahwa:

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

Saya mendapatkan ini ketika aplikasi saya tidak memiliki referensi ke majelis lain yang mendefinisikan kelas bahwa metode dalam pesan kesalahan yang digunakan. Menjalankan PEVerify memberi kesalahan lebih bermanfaat: "Sistem tidak dapat menemukan file yang ditentukan."

Saya menemukan pesan yang sama dan inilah yang kami temukan: Kami menggunakan dll pihak ketiga dalam proyek kami. Setelah rilis baru dari mereka keluar kami mengubah proyek kami untuk menunjuk ke set dll baru dan berhasil dikompilasi.

Pengecualian dilemparkan ketika saya mencoba untuk membuat salah satu dari kelas yang saling berhubungan selama waktu berjalan. Kami memastikan bahwa semua referensi lain sudah mutakhir, tetapi masih belum berhasil. Kami perlu beberapa saat untuk mengenali (menggunakan Browser Objek) bahwa tipe kembalinya metode dalam pesan kesalahan adalah tipe yang sama sekali baru dari perakitan baru, yang tidak direferensikan.

Kami menambahkan referensi ke majelis dan kesalahannya hilang.

• Pesan kesalahan itu cukup menyesatkan, tetapi menunjuk kurang lebih ke arah yang benar (metode yang benar, pesan yang salah).
• Pengecualian terjadi meskipun kami tidak menggunakan metode tersebut.
• Yang mengarahkan saya ke pertanyaan: Jika pengecualian ini dilemparkan dalam hal apa pun, mengapa kompilator tidak mengambilnya?

Saya menerima kesalahan ini dalam skenario berikut.

• Assemblies A dan B mereferensikan System.Web.Mvc Versi 3.0.0.0
• Assembly A mereferensikan Assembly B dan memiliki kelas yang mengimplementasikan antarmuka dari Assembly B dengan metode yang mengembalikan kelas dari System.Web.Mvc.
• Majelis A ditingkatkan ke System.Web.Mvc Versi 4.0.0.0
• Majelis C menjalankan kode di bawah ini (FertPin.Classes.Contact terkandung dalam Majelis A):

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

Perbaikan untuk saya adalah meningkatkan referensi System.Web.Mvc di Majelis B ke 4.0.0.0. Tampak jelas sekarang!

Berkat poster aslinya!

Waktu lain Anda bisa mendapatkan kesalahan ini adalah jika Anda memiliki versi yang salah dari rakitan yang ditandatangani. Ini bukan gejala normal untuk penyebab ini, tapi di sini ada skenario di mana saya mendapatkannya

• proyek asp.net berisi rakitan A dan rakitan B, B dinamai sangat

• rakitan A menggunakan Activator.CreateInstance untuk memuat rakitan C (yaitu tidak ada referensi ke C yang dibangun secara terpisah)

• C dibangun dengan referensi versi perakitan B yang lebih lama dari yang ada saat ini

berharap itu bisa membantu seseorang - butuh waktu lama bagi saya untuk mencari tahu.

Saya memiliki kesalahan ini juga, itu disebabkan oleh exe CPU Setiap referensi CPU Setiap majelis yang pada gilirannya direferensikan perakitan x86.

Pengecualian mengeluhkan metode pada kelas di MyApp.Implementations (Any CPU), yang menghasilkan MyApp.Interfaces (Any CPU), tetapi di fuslogvw.exe saya menemukan upaya tersembunyi 'untuk memuat program dengan format yang salah' pengecualian dari MyApp .CommonTypes (x86) yang digunakan oleh keduanya.

Saya terus kembali ke sini ... Banyak jawaban di sini melakukan pekerjaan yang baik untuk menjelaskan apa masalahnya tetapi tidak bagaimana cara memperbaikinya.

Solusi untuk ini adalah menghapus file bin secara manual di direktori proyek yang Anda publikasikan. Ini akan membersihkan semua referensi dan memaksa proyek untuk menggunakan DLL terbaru.

Saya tidak menyarankan menggunakan fungsi Hapus alat terbitkan karena ini cenderung membuang IIS.

Saya memiliki solusi esoterik lain untuk pesan kesalahan ini. Saya memutakhirkan kerangka target saya dari .Net 4.0 ke 4.6, dan proyek unit test saya memberi saya kesalahan "System.TypeLoadException ... tidak memiliki implementasi" kesalahan ketika saya mencoba membangun. Itu juga memberikan pesan kesalahan kedua tentang metode yang seharusnya tidak diterapkan yang sama yang mengatakan "Tugas 'BuildShadowTask' gagal secara tak terduga." Tidak ada saran di sini yang tampaknya membantu, jadi saya mencari "BuildShadowTask", dan menemukan posting di MSDN yang membuat saya menggunakan editor teks untuk menghapus baris-baris ini dari file csproj proyek unit test.

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

Setelah itu, kedua kesalahan hilang dan proyek dibangun.

Saya mengalami kesalahan ini dalam konteks di mana saya menggunakan Autofac dan banyak pemuatan perakitan dinamis.

Saat melakukan operasi resolusi Autofac, runtime akan gagal memuat salah satu rakitan. Pesan kesalahan mengeluhkan itu Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. Gejala terjadi ketika berjalan pada Windows Server 2012 R2 VM, tetapi tidak terjadi pada Windows 10 atau Windows Server 2016 VM.

ImplementationAssemblydireferensikan System.Collections.Immutable1.1.37, dan berisi implementasi IMyInterface<T1,T2>antarmuka, yang didefinisikan secara terpisah DefinitionAssembly. DefinitionAssemblydireferensikanSystem.Collections.Immutable 1.1.36.

Metode IMyInterface<T1,T2>yang "tidak diterapkan" memiliki parameter tipe IImmutableDictionary<TKey, TRow>, yang didefinisikan dalam System.Collections.Immutable.

Salinan aktual yang System.Collections.Immutableditemukan di direktori program adalah versi 1.1.37. Pada VM Windows Server 2012 R2 saya, GAC berisi salinan System.Collections.Immutable1.1.36. Pada Windows 10 dan Windows Server 2016, GAC berisi salinan System.Collections.Immutable1.1.37. Kesalahan pemuatan hanya terjadi ketika GAC ​​berisi versi DLL yang lebih lama.

Jadi, akar penyebab kegagalan beban perakitan adalah referensi yang tidak cocok System.Collections.Immutable. Definisi antarmuka dan implementasi memiliki tanda tangan metode yang tampak identik, tetapi sebenarnya tergantung pada versi yang berbeda System.Collections.Immutable, yang berarti bahwa runtime tidak mempertimbangkan kelas implementasi untuk mencocokkan definisi antarmuka.

Menambahkan pengalihan ikatan berikut ke file konfigurasi aplikasi saya memperbaiki masalah:

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

Saya mendapatkan ini dengan ketergantungan proyek berbentuk "berlian":

• Proyek A menggunakan Proyek B dan Proyek D
• Proyek B menggunakan Proyek D

Saya mengkompilasi ulang proyek A tetapi bukan Proyek B, yang memungkinkan Proyek B untuk "menyuntikkan" versi lama dari Proyek D dll

Saya mengalami ini ketika saya mengganti nama proyek (dan nama perakitan), yang diandalkan oleh proyek ASP.NET. Jenis-jenis dalam proyek web mengimplementasikan antarmuka dalam perakitan dependen. Meskipun menjalankan Solusi Bersih dari menu Bangun, perakitan dengan nama sebelumnya tetap di binfolder, dan ketika proyek web saya dieksekusi

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

pengecualian di atas terlempar, mengeluh bahwa metode antarmuka dalam menerapkan jenis web tidak benar-benar diterapkan. Menghapus perakitan secara manual di binfolder proyek web menyelesaikan masalah.

Saya juga mendapatkan kesalahan ini ketika sebelumnya saya mengaktifkan Cakupan Kode selama pengujian unit untuk salah satu majelis. Untuk beberapa alasan Visual Studio "buffered" versi lama DLL khusus ini meskipun saya telah memperbaruinya untuk mengimplementasikan versi baru dari antarmuka. Menonaktifkan Cakupan Kode menyingkirkan kesalahan.

Kesalahan ini juga dapat disebabkan jika perakitan dimuat menggunakan Assembly.LoadFrom (String) dan merujuk perakitan yang sudah dimuat menggunakan Assembly.Load (Byte []).

Misalnya, Anda telah menyematkan rujukan referensi aplikasi utama sebagai sumber daya tetapi aplikasi Anda memuat plug-in dari folder tertentu.

Alih-alih menggunakan LoadFrom, Anda harus menggunakan Load. Kode berikut akan melakukan pekerjaan:

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

Penjelasan lain untuk jenis masalah ini melibatkan dikelola C ++.

Jika Anda mencoba untuk rintisan antarmuka yang ditentukan dalam rakitan yang dibuat menggunakan C ++ terkelola yang memiliki tanda tangan khusus, Anda akan mendapatkan pengecualian ketika rintisan dibuat.

Ini berlaku untuk Badak Mocks dan mungkin kerangka kerja mengejek yang digunakan System.Reflection.Emit.

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

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

Definisi antarmuka mendapatkan tanda tangan berikut:

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

Perhatikan bahwa tipe C ++ longmemetakan ke System.Int32(atau hanya intdalam C #). Ini adalah sesuatu yang agak tidak jelas modoptyang menyebabkan masalah seperti yang dinyatakan oleh Ayende Rahien di milis Rhino Mocks .

Saya baru saja memutakhirkan solusi dari MVC3 ke MVC5, dan mulai menerima pengecualian yang sama dari proyek pengujian Unit saya.

Memeriksa semua referensi yang mencari file lama, akhirnya menemukan bahwa saya perlu melakukan beberapa bindingRedirect untuk Mvc, dalam proyek unit test saya.

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

Dalam kasus saya ini membantu untuk mereset Toolbox WinForms.

Saya mendapat pengecualian saat membuka Formdi desainer; Namun, mengkompilasi dan menjalankan kode dimungkinkan dan kode berperilaku seperti yang diharapkan. Pengecualian terjadi di lokalUserControl mengimplementasikan antarmuka dari salah satu pustaka referensi saya. Kesalahan muncul setelah perpustakaan ini diperbarui.

Ini UserControlterdaftar di WinForms Toolbox. Mungkin Visual Studio menyimpan referensi pada versi perpustakaan yang sudah ketinggalan zaman atau sedang menyimpan versi yang sudah usang di suatu tempat.

Inilah cara saya pulih dari situasi ini:

1. Klik kanan pada WinForms Toolbox dan klik pada Reset Toolboxmenu konteks. (Ini menghapus item khusus dari Toolbox).
   Dalam kasus saya, item-item Toolbox dikembalikan ke keadaan standarnya; namun, panah-Pointer tidak ada di Toolbox.
2. Tutup Visual Studio.
   Dalam kasus saya, Visual Studio diakhiri dengan pengecualian pelanggaran dan dibatalkan.
3. Mulai ulang Visual Studio.
   Sekarang semuanya berjalan dengan lancar.

FWIW, saya mendapatkan ini ketika ada file konfigurasi yang diarahkan ke versi yang tidak ada dari rujukan yang direferensikan. Log fusion untuk kemenangan!

Saya mendapatkan kesalahan ini karena saya memiliki kelas di majelis 'C' yang ada di versi 4.5 dari framework, mengimplementasikan antarmuka di assembly 'A' yang ada di versi 4.5.1 dari framework dan berfungsi sebagai kelas dasar untuk assembly 'B' yang juga pada versi 4.5.1 dari framework. Sistem melempar pengecualian saat mencoba memuat perakitan 'B'. Selain itu, saya telah menginstal beberapa paket nuget yang menargetkan .net 4.5.1 di ketiga majelis. Untuk beberapa alasan, meskipun referensi nuget tidak ditampilkan di majelis 'B', itu berhasil dibangun.

Ternyata masalah sebenarnya adalah bahwa majelis merujuk pada versi berbeda dari paket nuget yang berisi antarmuka dan tanda tangan antarmuka telah berubah di antara versi.

Dalam kasus saya, saya sebelumnya mereferensikan mylibproyek di folder saudara di luar repo - sebut saja v1.0.

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

Kemudian saya melakukannya dengan benar dan menggunakannya melalui git submodule - sebut saja itu v2.0. consoleAppNamun satu proyek tidak diperbarui dengan benar. Itu masih merujuk v1.0proyek lama di luar proyek git saya.

Yang membingungkan , meskipun *.csprojjelas-jelas salah dan menunjuk v1.0, Visual Studio IDE menunjukkan jalan sebagai v2.0proyek! F12 untuk memeriksa antarmuka dan kelas pergi ke v2.0versi juga.

Perakitan ditempatkan ke folder bin oleh kompiler adalah v1.0versi, maka sakit kepala.

Fakta bahwa IDE berbohong kepada saya membuatnya sangat sulit untuk menyadari kesalahannya.

Solusi : Menghapus referensi proyek dari ConsoleAppdan membacanya.

Tip Umum: Kompilasi ulang semua rakitan dari awal (jika memungkinkan, tentu saja tidak untuk paket nuget) dan periksa prangko seumur hidup di bin\debugfolder. Setiap majelis tua tanggal adalah masalah Anda.

Saya menghadapi masalah yang hampir sama. Saya menggaruk kepala saya apa yang menyebabkan kesalahan ini. Saya diperiksa silang, semua metode diimplementasikan.

Di Googling saya mendapat tautan ini antara lain. Berdasarkan komentar @Paul McLink, Dua langkah ini menyelesaikan masalah.

1. Mulai ulang Visual Studio
2. Bersih, Bangun (Bangun Kembali)

dan kesalahan hilang .

Mulai ulang VS Plugin

Terima kasih paul :)

Semoga ini bisa membantu seseorang yang menemukan kesalahan ini :)

Saya juga mengalami masalah ini saat menjalankan unittests saya. Aplikasi berjalan dengan baik dan tanpa kesalahan. Penyebab masalah dalam kasus saya adalah saya telah mematikan pembangunan proyek pengujian. Mengaktifkan kembali pembangunan proyek pengujian saya memecahkan masalah.

Saya melihat ini di Visual Studio Pro 2008 ketika dua proyek membangun majelis dengan nama yang sama, satu kelas lib SDF.dll, dan satu yang mereferensikan lib dengan nama perakitan sdf.exe. Ketika saya mengubah nama majelis referensi, pengecualian hilang

Ini berarti bahwa proyek implementasi sudah ketinggalan zaman dalam kasus saya. DLL yang berisi antarmuka dibangun kembali tetapi dll implementasi basi.

Inilah pendapat saya tentang kesalahan ini.

Menambahkan externmetode, tetapi tempel saya rusak. The DllImportAttributepunya menempatkan pada baris komentar.

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

Memastikan atribut benar-benar dimasukkan dalam sumber memperbaiki masalah.

Saya mendapatkan ini di layanan WCF karena memiliki tipe build x86 yang dipilih, menyebabkan tempat sampah untuk hidup di bawah bin \ x86 bukan bin. Memilih CPU Apa pun menyebabkan DLL yang dikompilasi untuk kembali ke lokasi yang benar (saya tidak akan menjelaskan bagaimana ini terjadi di tempat pertama).

Saya memiliki masalah yang sama. Saya tahu bahwa perakitan saya, yang dimuat oleh program utama, memiliki beberapa referensi dengan "Salin Lokal" disetel ke true. Salinan referensi lokal ini sedang mencari referensi lain di folder yang sama, yang tidak ada karena "Salin Lokal" dari referensi lain disetel ke false. Setelah penghapusan referensi yang disalin "secara tidak sengaja" kesalahannya hilang karena program utama diatur untuk mencari lokasi referensi yang benar. Rupanya salinan referensi lokal mengacaukan urutan panggilan karena salinan lokal ini digunakan alih-alih yang asli yang ada dalam program utama.

Pesan dibawa pulang adalah bahwa kesalahan ini muncul karena tautan yang hilang untuk memuat rakitan yang diperlukan.

Dalam kasus saya, saya mencoba menggunakan TypeBuilderuntuk membuat tipe. TypeBuilder.CreateTypemelemparkan pengecualian ini. Saya akhirnya menyadari bahwa saya perlu menambahkan MethodAttributes.Virtualatribut ketika memanggil TypeBuilder.DefineMethodmetode yang membantu mengimplementasikan antarmuka. Ini karena tanpa tanda ini, metode ini tidak mengimplementasikan antarmuka, melainkan metode baru dengan tanda tangan yang sama sebagai gantinya (bahkan tanpa menentukan MethodAttributes.NewSlot).

Sebagai tambahan: ini juga dapat terjadi jika Anda memperbarui paket nuget yang digunakan untuk menghasilkan rakitan palsu. Katakanlah Anda menginstal V1.0 dari paket nuget dan membuat rakitan palsu "fakeLibrary.1.0.0.0.Fake". Selanjutnya, Anda memperbarui ke versi terbaru dari paket nuget, katakanlah v1.1 yang menambahkan metode baru ke antarmuka. Perpustakaan Fakes masih mencari v1.0 perpustakaan. Cukup hapus rakitan palsu dan buat ulang. Jika itu masalahnya, ini mungkin akan memperbaikinya.

Saya menerima kesalahan ini setelah pembaruan windows baru-baru ini. Saya memiliki kelas layanan yang diatur untuk mewarisi dari antarmuka. Antarmuka berisi tanda tangan yang mengembalikan ValueTuple, fitur yang cukup baru di C #.

Yang bisa saya tebak adalah bahwa pembaruan windows menginstal yang baru, tetapi bahkan secara eksplisit merujuknya, memperbarui pengalihan yang mengikat, dll ... Hasil akhirnya hanya mengubah tanda tangan metode untuk sesuatu "standar" Saya kira Anda bisa mengatakannya.