TypeLoadException dice "nessuna implementazione", ma è implementata

Ho un bug molto strano sulla nostra macchina di prova. L'errore è:

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

Non riesco proprio a capire il perché. SetShortè presente nella DummyItemclasse e ho persino ricompilato una versione con scritture nel registro eventi solo per accertarmi che non si tratti di un problema di distribuzione / controllo delle versioni. La cosa strana è che il codice chiamante non chiama nemmeno il SetShortmetodo.

NOTA - Se questa risposta non ti aiuta, ti preghiamo di scorrere le altre risposte che le persone hanno aggiunto da allora.

Risposta breve

Ciò può accadere se si aggiunge un metodo a un'interfaccia in un assembly e quindi a una classe di implementazione in un altro assembly, ma si ricostruisce l'assembly di implementazione senza fare riferimento alla nuova versione dell'assembly dell'interfaccia.

In questo caso, DummyItem implementa un'interfaccia di un altro assembly. Il metodo SetShort è stato recentemente aggiunto sia all'interfaccia sia a DummyItem, ma l'assembly contenente DummyItem è stato ricostruito facendo riferimento alla versione precedente dell'assembly dell'interfaccia. Quindi il metodo SetShort è effettivamente lì, ma senza la salsa magica che lo collega al metodo equivalente nell'interfaccia.

Risposta lunga

Se si desidera provare a riprodurre questo, provare quanto segue:

1. Crea un progetto di libreria di classi: InterfaceDef, aggiungi solo una classe e crea:

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

2. Crea un progetto di libreria di seconda classe: implementazione (con soluzione separata), copia InterfaceDef.dll nella directory di progetto e aggiungi come riferimento file, aggiungi solo una classe e costruisci:

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

3. Creare un terzo progetto console: ClientCode, copiare le due dll nella directory del progetto, aggiungere riferimenti ai file e aggiungere il seguente codice nel metodo Main:

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

4. Esegui il codice una volta, la console dice "ciao mondo"

5. Decommenta il codice nei due progetti DLL e ricostruiscilo: copia i due DLL nel progetto ClientCode, ricostruisci e prova a eseguire di nuovo. TypeLoadException si verifica quando si tenta di creare un'istanza di ImplementingClass.

Oltre a quanto già affermato dalla risposta del richiedente, può valere la pena notare quanto segue. Il motivo per cui ciò accade è perché è possibile per una classe avere un metodo con la stessa firma di un metodo di interfaccia senza implementare quel metodo. Il codice seguente mostra che:

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

Ho ottenuto questo quando la mia applicazione non aveva un riferimento a un altro assembly che definiva una classe utilizzata dal metodo nel messaggio di errore. L'esecuzione di PEVerify ha dato un errore più utile: "Il sistema non è in grado di trovare il file specificato."

Mi sono imbattuto nello stesso messaggio ed ecco cosa abbiamo trovato: nel nostro progetto utilizziamo DLL di terze parti. Dopo l'uscita di una nuova versione, abbiamo modificato il nostro progetto in modo da puntare al nuovo set di DLL e compilato con successo.

L'eccezione è stata lanciata quando ho provato a installare una delle loro classi interfacciate durante il runtime. Ci siamo assicurati che tutti gli altri riferimenti fossero aggiornati, ma ancora senza fortuna. Abbiamo avuto bisogno di un po 'di tempo per individuare (utilizzando il browser degli oggetti) che il tipo restituito del metodo nel messaggio di errore era un tipo completamente nuovo da un nuovo assembly senza riferimento.

Abbiamo aggiunto un riferimento all'assembly e l'errore è scomparso.

• Il messaggio di errore era abbastanza fuorviante, ma puntava più o meno nella giusta direzione (metodo giusto, messaggio sbagliato).
• L'eccezione si è verificata anche se non abbiamo utilizzato il metodo in questione.
• Il che mi porta alla domanda: se in ogni caso viene generata questa eccezione, perché il compilatore non la rileva?

Ho ricevuto questo errore nel seguente scenario.

• Entrambi gli assiemi A e B fanno riferimento a System.Web.Mvc versione 3.0.0.0
• L'Assemblea A faceva riferimento all'Assemblea B e aveva classi che implementavano interfacce dall'Assemblea B con metodi che restituivano classi da System.Web.Mvc.
• Assembly A aggiornato a System.Web.Mvc versione 4.0.0.0
• L'Assemblea C eseguiva il codice seguente (FertPin.Classes.Contact era contenuto nell'Assemblea A):

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

La correzione per me era l'aggiornamento del riferimento System.Web.Mvc nell'Assemblea B alla 4.0.0.0. Sembra ovvio ora!

Grazie al poster originale!

L'altra volta è possibile ottenere questo errore se si dispone di una versione errata di un assembly firmato. Non è il sintomo normale per questa causa, ma qui è stato lo scenario in cui l'ho preso

• un progetto asp.net contiene l'assemblaggio A e l'assemblaggio B, B è fortemente chiamato

• assembly A utilizza Activator.CreateInstance per caricare l'assembly C (ovvero non esiste alcun riferimento a C che viene creato separatamente)

• C è stato creato facendo riferimento a una versione precedente dell'assembly B di quella attualmente presente

spero che aiuti qualcuno - mi ci sono voluti anni per capirlo.

Ho avuto anche questo errore, è stato causato da un exe Any CPU che fa riferimento a qualsiasi assembly CPU che a sua volta faceva riferimento a un assembly x86.

L'eccezione si è lamentata di un metodo su una classe in MyApp.Implementations (Any CPU), che ha derivato MyApp.Interfaces (Any CPU), ma in fuslogvw.exe ho trovato un'eccezione nascosta "tentativo di caricare un programma con un formato errato" da MyApp .CommonTypes (x86) utilizzato da entrambi.

Continuo a tornare a questo ... Molte delle risposte qui fanno un ottimo lavoro per spiegare qual è il problema ma non come risolverlo.

La soluzione a questo è eliminare manualmente i file bin nella directory pubblicata dei progetti. Pulirà tutti i riferimenti e imporrà al progetto di utilizzare le DLL più recenti.

Non suggerisco di utilizzare la funzione di eliminazione degli strumenti di pubblicazione perché tende a eliminare IIS.

Ho ancora un'altra soluzione esoterica a questo messaggio di errore. Ho aggiornato il mio framework di destinazione da .Net 4.0 a 4.6 e il mio progetto di unit test mi stava dando l'errore "System.TypeLoadException ... non ha un'implementazione" quando ho provato a compilare. Forniva anche un secondo messaggio di errore sullo stesso metodo apparentemente non implementato che diceva "L'attività 'BuildShadowTask' non è riuscita in modo imprevisto". Nessuno dei consigli qui mi è sembrato di aiuto, così ho cercato "BuildShadowTask" e ho trovato un post su MSDN che mi ha portato a utilizzare un editor di testo per eliminare queste righe dal file csproj del progetto unit test.

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

Successivamente, entrambi gli errori sono scomparsi e il progetto è stato realizzato.

Ho riscontrato questo errore in un contesto in cui stavo usando Autofac e un sacco di caricamento dinamico dell'assembly.

Durante l'esecuzione di un'operazione di risoluzione Autofac, il runtime non caricava uno degli assembly. Il messaggio di errore si lamentava che Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. I sintomi si sono verificati durante l'esecuzione su una macchina virtuale Windows Server 2012 R2, ma non si sono verificati su macchine virtuali Windows 10 o Windows Server 2016.

ImplementationAssemblyreferenziato System.Collections.Immutable1.1.37 e conteneva implementazioni di IMyInterface<T1,T2>un'interfaccia, che è stata definita in modo separato DefinitionAssembly. DefinitionAssemblyriferimentoSystem.Collections.Immutable 1.1.36.

I metodi da IMyInterface<T1,T2>cui "non sono stati implementati" avevano parametri di tipo IImmutableDictionary<TKey, TRow>, che è definito inSystem.Collections.Immutable .

La copia effettiva di System.Collections.Immutabletrovato nella directory del programma era la versione 1.1.37. Sulla mia macchina virtuale Windows Server 2012 R2, il GAC conteneva una copia di System.Collections.Immutable1.1.36. Su Windows 10 e Windows Server 2016, il GAC conteneva una copia diSystem.Collections.Immutable dell'1.1.37. L'errore di caricamento si è verificato solo quando GAC conteneva la versione precedente della DLL.

Pertanto, la causa principale dell'errore di caricamento dell'assembly è stata la mancata corrispondenza dei riferimenti System.Collections.Immutable. La definizione e l'implementazione dell'interfaccia avevano firme dei metodi dall'aspetto identico, ma in realtà dipendevano da diverse versioni diSystem.Collections.Immutable , il che significava che il runtime non considerava la classe di implementazione corrispondente alla definizione dell'interfaccia.

L'aggiunta del seguente reindirizzamento di associazione al mio file di configurazione dell'applicazione ha risolto il problema:

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

Ho ottenuto questo con una dipendenza del progetto a forma di "diamante":

• Il progetto A utilizza il progetto B e il progetto D
• Il progetto B utilizza il progetto D

Ho ricompilato il progetto A ma non il Progetto B, che ha permesso al Progetto B di "iniettare" la vecchia versione del Progetto Dll

Ho riscontrato questo quando ho rinominato un progetto (e il nome dell'assembly), da cui dipendeva un progetto ASP.NET. I tipi nel progetto Web hanno implementato le interfacce nell'assembly dipendente. Nonostante abbia eseguito Clean Solution dal menu Build, l'assembly con il nome precedente è rimasto nella bincartella e quando il mio progetto web è stato eseguito

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

è stata generata l'eccezione di cui sopra, lamentando che i metodi di interfaccia nei tipi di web di implementazione non sono stati effettivamente implementati. L'eliminazione manuale dell'assembly nella bincartella del progetto Web ha risolto il problema.

Ho anche riscontrato questo errore quando in precedenza avevo abilitato la copertura del codice durante il test dell'unità per uno degli assiemi. Per qualche motivo Visual Studio ha "bufferizzato" la vecchia versione di questa particolare DLL anche se l'avevo aggiornata per implementare una nuova versione dell'interfaccia. La disabilitazione della copertura del codice ha eliminato l'errore.

Questo errore può anche essere causato se un assembly viene caricato utilizzando Assembly.LoadFrom (String) e fa riferimento a un assembly che è già stato caricato utilizzando Assembly.Load (Byte []).

Ad esempio, hai incorporato gli assembly di riferimento dell'applicazione principale come risorse, ma l'app carica i plug-in da una cartella specifica.

Invece di usare LoadFrom dovresti usare Load. Il seguente codice farà il lavoro:

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

Un'altra spiegazione per questo tipo di problema riguarda il C ++ gestito.

Se si tenta di stub un'interfaccia definita in un assembly creato utilizzando C ++ gestito con una firma speciale, si otterrà l'eccezione quando viene creato lo stub.

Questo è vero per Rhino Mocks e probabilmente per qualsiasi framework beffardo che utilizza System.Reflection.Emit.

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

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

La definizione dell'interfaccia ottiene la seguente firma:

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

Si noti che il tipo C ++ è longmappato a System.Int32(o semplicemente intin C #). È un po 'oscuro modoptche sta causando il problema, come affermato da Ayende Rahien nella mailing list di Rhino Mocks .

Ho appena aggiornato una soluzione da MVC3 a MVC5 e ho iniziato a ricevere la stessa eccezione dal mio progetto di test unitario.

Ho controllato tutti i riferimenti alla ricerca di vecchi file, alla fine ho scoperto che dovevo fare alcuni binding Redirect per Mvc, nel mio progetto di unit test.

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

Nel mio caso ha aiutato a ripristinare la Casella degli strumenti di WinForms.

Ho ottenuto l'eccezione quando ho aperto a Formnel designer; tuttavia, la compilazione e l'esecuzione del codice erano possibili e il codice si comportava come previsto. L'eccezione si è verificata in un localeUserControl implementava un'interfaccia da una delle mie librerie di riferimento. L'errore è emerso dopo l'aggiornamento di questa libreria.

Questo è UserControlstato elencato nella casella degli strumenti di WinForms. Probabilmente Visual Studio ha mantenuto un riferimento su una versione obsoleta della libreria o stava memorizzando nella cache una versione obsoleta da qualche parte.

Ecco come mi sono ripreso da questa situazione:

1. Fare clic con il tasto destro del mouse su WinForms Toolbox e fare clic su Reset Toolboxnel menu contestuale. (Ciò rimuove gli elementi personalizzati dalla casella degli strumenti).
   Nel mio caso gli oggetti Toolbox sono stati ripristinati al loro stato predefinito; tuttavia, la freccia del puntatore mancava nella casella degli strumenti.
2. Chiudi Visual Studio.
   Nel mio caso Visual Studio è terminato con un'eccezione di violazione e interrotto.
3. Riavvia Visual Studio.
   Ora tutto funziona senza intoppi.

FWIW, ho ottenuto questo quando c'era un file di configurazione che reindirizzava a una versione inesistente di un assembly di riferimento. Log di fusione per la vittoria!

Ho ricevuto questo errore perché avevo una classe in un assembly 'C' che era sulla versione 4.5 del framework, implementando un'interfaccia nell'assembly 'A' che era sulla versione 4.5.1 del framework e fungeva da classe base per il assembly 'B' che era anche sulla versione 4.5.1 del framework. Il sistema ha generato l'eccezione durante il tentativo di caricare l'assembly 'B'. Inoltre, avevo installato alcuni pacchetti nuget destinati a .net 4.5.1 su tutti e tre i gruppi. Per qualche ragione, anche se i riferimenti nuget non erano mostrati nell'assemblaggio 'B', stava costruendo con successo.

Si è scoperto che il vero problema era che gli assembly facevano riferimento a diverse versioni di un pacchetto nuget che conteneva l'interfaccia e la firma dell'interfaccia era cambiata tra le versioni.

Nel mio caso in precedenza avevo fatto riferimento a un mylibprogetto in una cartella di fratelli fuori dal repository - chiamiamolo così v1.0.

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

Più tardi l'ho fatto correttamente e l'ho usato tramite un sottomodulo git - chiamiamolo così v2.0. Un progetto consoleApptuttavia non è stato aggiornato correttamente. Faceva ancora riferimento al vecchio v1.0progetto al di fuori del mio progetto git.

Confusamente , anche se *.csprojchiaramente era sbagliato e puntava su v1.0, l'IDE di Visual Studio ha mostrato il percorso come v2.0progetto! F12 per ispezionare l'interfaccia e la classe è andato alv2.0 versione.

L'assembly inserito nella cartella bin dal compilatore era il v1.0 versione, quindi il mal di testa.

Il fatto che l'IDE mi stesse mentendo ha reso ancora più difficile realizzare l'errore.

Soluzione : eliminati riferimenti a progetti ConsoleAppe letti.

Suggerimento generale: ricompilare tutti gli assiemi da zero (ove possibile, ovviamente non è possibile per pacchetti nuget) e controllare i timestamp datetime nella bin\debugcartella. Eventuali vecchie assemblee datate sono il tuo problema.

Ho affrontato quasi lo stesso problema. Mi stavo grattando la testa che cosa sta causando questo errore. Ho fatto un controllo incrociato, tutti i metodi sono stati implementati.

Su Google ho ottenuto questo link tra l'altro. Basato sul commento di @Paul McLink, questi due passaggi hanno risolto il problema.

1. Riavvia Visual Studio
2. Pulisci, costruisci (ricostruisci)

e l' errore è andato .

Riavvia VS Plugin

Grazie Paolo :)

Spero che questo aiuti qualcuno che si imbatte in questo errore :)

Ho anche riscontrato questo problema durante l'esecuzione dei miei unittest. L'applicazione funzionava bene e senza errori. La causa del problema nel mio caso era che avevo disattivato la costruzione dei progetti di test. Riattivare la costruzione dei miei progetti di test ha risolto i problemi.

Ho visto questo in Visual Studio Pro 2008 quando due progetti hanno creato assembly con lo stesso nome, uno SDF.dll di una classe lib e uno che faceva riferimento alla libreria con nome assembly sdf.exe. Quando ho cambiato il nome dell'assembly di riferimento, l'eccezione è scomparsa

Ciò significa semplicemente che il progetto di implementazione non è aggiornato nei miei casi. La DLL contenente l'interfaccia è stata ricostruita ma la dll di implementazione era obsoleta.

Ecco la mia opinione su questo errore.

Aggiunto un externmetodo, ma la mia pasta era difettosa. Sono DllImportAttributestati messi su una riga commentata.

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

Garantire che l'attributo fosse effettivamente incluso nell'origine risolto il problema.

Ho ottenuto questo in un servizio WCF a causa della selezione di un tipo di build x86, facendo sì che i bin vivessero sotto bin \ x86 anziché bin. La selezione di Qualsiasi CPU ha fatto sì che le DLL ricompilate andassero nelle posizioni corrette (non andrò nei dettagli su come ciò è accaduto in primo luogo).

Ho avuto lo stesso problema. Ho capito che il mio assembly, che è stato caricato dal programma principale, aveva alcuni riferimenti con "Copy Local" impostato su true. Queste copie locali di riferimenti cercavano altri riferimenti nella stessa cartella, che non esisteva perché "Copia locale" di altri riferimenti era impostato su false. Dopo l'eliminazione dei riferimenti copiati "accidentalmente" l'errore era scomparso perché il programma principale era impostato per cercare posizioni corrette di riferimenti. Apparentemente le copie locali dei riferimenti hanno rovinato la sequenza della chiamata perché queste copie locali sono state utilizzate al posto di quelle originali presenti nel programma principale.

Il messaggio da portare a casa è che questo errore appare a causa del collegamento mancante per caricare l'assembly richiesto.

Nel mio caso, stavo tentando di utilizzare TypeBuilderper creare un tipo. TypeBuilder.CreateTypeha gettato questa eccezione. Alla fine mi sono reso conto che dovevo aggiungere MethodAttributes.Virtualdegli attributi quando ho chiamato TypeBuilder.DefineMethodun metodo che aiuta a implementare un'interfaccia. Questo perché senza questo flag, il metodo non implementa l'interfaccia, ma piuttosto un nuovo metodo con la stessa firma (anche senza specificare MethodAttributes.NewSlot).

Come addendum: ciò può verificarsi anche se si aggiorna un pacchetto nuget utilizzato per generare un assembly falso. Supponiamo che tu installi V1.0 di un pacchetto nuget e crei un assembly falso "fakeLibrary.1.0.0.0.Fakes". Successivamente, si aggiorna alla versione più recente del pacchetto nuget, ad esempio v1.1 che ha aggiunto un nuovo metodo a un'interfaccia. La libreria Fakes sta ancora cercando la versione 1.0 della libreria. Basta rimuovere il gruppo falso e rigenerarlo. Se quello era il problema, questo probabilmente lo risolverà.

Ho ricevuto questo errore dopo un recente aggiornamento di Windows. Avevo una classe di servizio impostata per ereditare da un'interfaccia. L'interfaccia conteneva una firma che restituiva una ValueTuple, una funzionalità abbastanza nuova in C #.

Tutto quello che posso immaginare è che l'aggiornamento di Windows ne abbia installato uno nuovo, ma anche facendo esplicito riferimento ad esso, aggiornando i reindirizzamenti vincolanti, ecc ... Il risultato finale è stato semplicemente cambiare la firma del metodo in qualcosa di "standard", suppongo che si possa dire.