TypeLoadException dice 'no attuazione', ma è implementato

https://stackoverflow.com/questions/948785

09-09-2019
|

Domanda

Ho un molto strano bug 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 c'è in DummyItem classe, e ho anche ricompilato una versione con la scrittura nel registro eventi, solo per assicurarsi che non è una distribuzione/versioning problema.La cosa strana è che il codice chiamante non ha nemmeno chiamare il SetShort metodo.

Soluzione

NOTA - Se questa risposta non sono di aiuto, si prega di prendere il tempo per scorrere le altre risposte che le persone che hanno aggiunto dopo.

Risposta breve

Questo può accadere se si aggiunge un metodo di un'interfaccia in un unico gruppo, e quindi di un'implementazione di classe in un'altra assemblea, ma si ricostruisce l'attuazione di montaggio senza fare riferimento alla nuova versione dell'interfaccia di montaggio.

In questo caso, DummyItem implementa un'interfaccia da un'altra assemblea.Il SetShort metodo è stato recentemente aggiunto l'interfaccia e la DummyItem - ma l'assembly contenente DummyItem è stata ricostruita riferimento alla precedente versione dell'interfaccia di montaggio.Così il SetShort metodo è effettivamente c'è, ma senza la magia di salsa di collegamento al metodo equivalente nell'interfaccia.

Risposta lunga

Se volete provare a riprodurre questo, provare le seguenti opzioni:

Creare un progetto libreria di classi:InterfaceDef, aggiungere solo una classe, e di costruire:

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

Creare un secondo progetto libreria di classi:Attuazione (con soluzione separata), copia InterfaceDef.dll nella directory di progetto e aggiungere file di riferimento, aggiungere solo una classe, e di costruire:

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

    //public short GetShort(string key)
    //{
    //    return 1;
    //}
    #endregion
}

Creare una terza, console di progetto:ClientCode, copiare i due dll nella directory del progetto, aggiungere riferimenti a file, e aggiungere il codice seguente nel metodo Main:
```
 IInterface test = new ImplementingClass();
 string s = test.GetString("dummykey");
 Console.WriteLine(s);
 Console.ReadKey();
```
Eseguire il codice una volta, la console dice "ciao mondo"
Il commento il codice in due progetti di dll e ricostruire - copia le due dll di nuovo nel ClientCode progetto di ricostruzione e provare a eseguire di nuovo.TypeLoadException si verifica quando si tenta di creare un'istanza del ImplementingClass.

Altri suggerimenti

In aggiunta a quanto proprio la risposta del richiedente già detto, può essere la pena di notare quanto segue. Il motivo per cui questo accade è perché è possibile per una classe di avere un metodo con la stessa firma un metodo di interfaccia senza implementare tale metodo. Il codice seguente illustra 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 domanda non ha avuto un riferimento a un altro gruppo di definizione di una classe che il metodo nel messaggio di errore utilizzato. Esecuzione PEVerify dato di errore più utile: "Il sistema non trova il file specificato"

mi sono imbattuto lo stesso messaggio ed ecco cosa abbiamo trovato: Usiamo DLL di terze parti nel nostro progetto. Dopo una nuova release di quelli era fuori abbiamo cambiato il nostro progetto per puntare al nuovo set di DLL e compilato con successo.

Il stata generata un'eccezione quando ho cercato di instatiate una delle loro classi interfacciati in fase di esecuzione. Abbiamo fatto in modo che tutti gli altri riferimenti sono stati fino ad oggi, ma ancora senza fortuna. Avevamo bisogno di un po 'per individuare (utilizzando il Visualizzatore oggetti) che il tipo di ritorno del metodo nel messaggio di errore era un tipo completamente nuovo da un nuovo, il montaggio senza riferimento.

Abbiamo aggiunto un riferimento per il montaggio e l'errore è scomparso.

Il messaggio di errore è del tutto fuorviante, ma ha più o meno nella direzione giusta (giusto metodo, un messaggio sbagliato).
L'eccezione occurred anche se non abbiamo usato il metodo in questione.
Il che mi porta alla domanda:? Se questa viene generata un'eccezione in ogni caso, perché il compilatore non raccoglierla

Ho ricevuto questo errore nel seguente scenario.

entrambi i gruppi A e B riferimento System.Web.Mvc versione 3.0.0.0
Montaggio A Montaggio di riferimento B e aveva classi che implementate le interfacce da Assembly B con metodi che hanno restituito le classi da System.Web.Mvc.
Assembly Un aggiornato alla versione 4.0.0.0 System.Web.Mvc
Assemblea C ha eseguito il codice qui sotto (FertPin.Classes.Contact era contenuta in Assemblea A):

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

La correzione per me è stato l'aggiornamento il riferimento System.Web.Mvc in Assembly B a 4.0.0.0. Sembra ovvio ora!

Grazie al manifesto originale!

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

un progetto asp.net contiene assemblaggio e montaggio A B, B è fortemente denominato
montaggio A utilizza Activator.CreateInstance per caricare assembly C (cioè non v'è alcun riferimento a C che è costruito separatamente)
C è stato costruito riferimento a una versione precedente di montaggio B di quanto sia attualmente presenti

speranza che aiuta qualcuno - mi ci sono voluti secoli per capire questo

Ho avuto questo errore troppo, è stato causato da un exe Qualunque CPU referenziare Eventuali gruppi CPU che a sua volta fa riferimento un assembly x86.

L'eccezione è lamentato un metodo su una classe in MyApp.Implementations (Qualsiasi CPU), che deriva MyApp.Interfaces (Qualsiasi CPU), ma in Fuslogvw.exe ho trovato un 'tentativo di caricare il programma con un formato non corretto' nascosto deroga MyApp.CommonTypes (x86) che viene utilizzato sia.

io continuo a tornare a questo ... Molte delle risposte qui fanno un ottimo lavoro di spiegare qual è il problema, ma non come risolvere il problema.

La soluzione a questo è quella di eliminare manualmente i file bin nei progetti directory pubblicati. Sarà ripulire tutti i riferimenti e la forza il progetto di utilizzare le ultime DLL.

Io non suggerisco di usare gli strumenti di pubblicare funzione Cancella perché questo tende a buttare fuori di IIS.

Ho ancora un'altra soluzione esoterica di questo messaggio di errore. Ho aggiornato il mio framework di destinazione da Net 4,0-4,6, e il mio progetto di test di unità mi stava dando il "System.TypeLoadException ... non ha un'implementazione" l'errore quando ho provato a costruire. Essa ha anche dato un secondo messaggio di errore circa lo stesso metodo apparentemente non implementato, che ha dichiarato: "Il compito 'BuildShadowTask' Errore imprevisto." Nessuno di questi consigli sembrava di aiutare, così ho cercato per "BuildShadowTask", e ha trovato un post su MSDN che mi ha portato ad utilizzare un editor di testo per eliminare queste righe da file csproj del progetto unit test.

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

Dopo di che, sia gli errori se ne andò e il progetto di costruzione.

ho incontrato questo errore in un contesto in cui stavo usando Autofac e un sacco di assemblaggio caricamento dinamico.

Durante l'esecuzione di un'operazione risoluzione Autofac, il runtime sarebbe riuscire a caricare uno dei complessi. Il messaggio di errore si lamentava che Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. Si sono verificati i sintomi durante l'esecuzione su un computer Windows Server 2012 R2 VM, ma ha fatto non si verifica in Windows 10 o Windows Server 2016 VM.

ImplementationAssembly riferimento System.Collections.Immutable 1.1.37, e implementazioni di un'interfaccia IMyInterface<T1,T2>, definita in un DefinitionAssembly separata contenuta. DefinitionAssembly riferimento System.Collections.Immutable 1.1.36.

I metodi da IMyInterface<T1,T2> che sono stati "non implementato" hanno parametri di tipo IImmutableDictionary<TKey, TRow>, che è definito nella System.Collections.Immutable.

La copia effettiva di System.Collections.Immutable trovato nella directory del programma era la versione 1.1.37. Sul mio Windows Server 2012 R2 VM, il GAC conteneva una copia di System.Collections.Immutable 1.1.36. In Windows 10 e Windows Server 2016, il GAC conteneva una copia di System.Collections.Immutable 1.1.37. L'errore di caricamento si è verificato solo quando il GAC conteneva la versione precedente della DLL.

Quindi, la causa principale del fallimento carico di montaggio sono stati i riferimenti di disadattamenti a System.Collections.Immutable. La definizione e l'attuazione di interfaccia avevano firme del metodo identico aspetto, ma in realtà dipendevano da diverse versioni di System.Collections.Immutable, il che significava che il runtime non ha considerato la classe di implementazione in modo che corrisponda alla definizione di interfaccia.

L'aggiunta dei seguenti reindirizzamento vincolante al mio file di configurazione dell'applicazione 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 un "diamante" del progetto a forma di dipendenza:

Progetto A Progetto B usa e Project D
Progetto B utilizza Progetto D

I ricompilato progetto A ma non Progetto B, che ha permesso Progetto B a "iniettare" la vecchia versione del dll Progetto D

ho incontrato questo quando ho rinominato un progetto (e il nome di montaggio), che è stata considerata, da un progetto ASP.NET. Tipi nel progetto web implementate le interfacce in assembly dipendente. Nonostante l'esecuzione Pulisci soluzione dal menu Genera, l'assemblaggio con il precedente nome è rimasto nella cartella bin, e quando il mio progetto web eseguito

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

l'eccezione di cui sopra è stato gettato, lamentando che i metodi di interfaccia nei tipi web di attuazione non sono stati effettivamente attuati. cancellando manualmente l'assembly nella cartella bin del progetto web risolto il problema.

Inoltre ho ottenuto questo errore quando avevo precedentemente abilitato Code Coverage durante i test unità per una delle assemblee. Per qualche ragione di Visual Studio "tamponato" la vecchia versione di questo particolare DLL anche se avevo aggiornato per implementare una nuova versione dell'interfaccia. Disattivazione Code Coverage è sbarazzato dell'errore.

Un'altra spiegazione per questo tipo di problema che coinvolge C ++ gestito.

Se si tenta di stub un'interfaccia definita in un assembly creati con C ++ gestito che ha una firma speciale si otterrà l'eccezione quando si crea lo stub.

Questo è vero per Rhino Mocks e probabilmente qualsiasi quadro di scherno 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 di interfaccia ottiene la seguente firma:

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

Si noti che i ++ mappe tipo long C a System.Int32 (o semplicemente int in C #). È il modopt alquanto oscuro che causa il problema come dichiarato dal Ayende Rahien sulla l'elenco Rhino Mocks mailing .

Questo errore può anche verificarsi se un assembly viene caricato usando Assembly.LoadFrom (String) e fa riferimento a un assieme che già caricato usando Assembly.Load (Byte []).

Per esempio si hanno incorporato assembly referenziati dell'applicazione principale, come le risorse, ma i carichi app plug-in da una cartella specifica.

Invece di usare LoadFrom si dovrebbe usare carico. 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;
}

Ho appena aggiornato una soluzione da MVC3 a MVC5, e cominciato a ricevere la stessa eccezione dal mio progetto di test Unità.

Controllato tutti i riferimenti alla ricerca di vecchi file, eventualy scoperto avevo bisogno di fare un po 'bindingRedirects 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 contribuito a ripristinare il WinForms Casella degli strumenti.

ho avuto l'eccezione quando si apre un Form nella finestra di progettazione; tuttavia, compilare ed eseguire il codice è stato possibile e il codice comportati come previsto. L'eccezione si è verificata in un locale UserControl implementazione di un'interfaccia da una delle mie librerie di riferimento. L'errore è emerso dopo questa libreria è stata aggiornata.

Questa UserControl è stato elencato nel WinForms Toolbox. Probabilmente Visual Studio mantenuto un riferimento su una versione non aggiornata della libreria o è stato caching una versione non aggiornata da qualche parte.

Ecco come ho recuperato da questa situazione:

Fare clic destro sul WinForms Toolbox e cliccare su Reset Toolbox nel menu contestuale. (Questo rimuove elementi personalizzati dalla Casella degli strumenti).
Nel mio caso le voci Toolbox sono stati riportati al loro stato di default; tuttavia, il puntatore freccia mancava nella casella degli strumenti.
Chiudere Visual Studio.
Nel mio caso Visual Studio terminato con un'eccezione violazione e interrotta.
Riavviare Visual Studio.
Ora tutto proceda bene.

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

ho ottenuto questo errore perché ho avuto una classe in un assembly 'C', che era sulla versione 4.5 del framework, implementazione di un'interfaccia in assemblea 'A', che era sulla versione 4.5.1 del framework e servire come base classe assembly 'B' che era anche sulla versione 4.5.1 del framework. Il sistema ha generato l'eccezione durante il caricamento assembly 'B'. Inoltre, avevo installato alcuni pacchetti Nuget mirati .net 4.5.1 su tutti e tre i gruppi. Per qualche ragione, anche se i riferimenti Nuget non mostravano in assemblea 'B', è stato la costruzione di successo.

Si è scoperto che il vero problema era che le assemblee sono state referenziano diverse versioni di un pacchetto di NuGet che contenevano l'interfaccia e la firma di interfaccia erano cambiate tra le versioni.

Nel mio caso ho avuto in precedenza fatto riferimento un progetto mylib in una cartella di pari livello al di fuori del pronti contro termine - chiamiamolo che v1.0.

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

In seguito ho fatto correttamente e usato tramite un modulo git - consente di chiamare quel v2.0. Un progetto consoleApp, tuttavia, non è stato aggiornato correttamente. E 'stato ancora riferimento al vecchio progetto v1.0 al di fuori del mio progetto Git.

Confusamente , anche se il *.csproj era chiaramente sbagliata e indicando v1.0, l'IDE di Visual Studio ha mostrato il percorso come il progetto v2.0! F12 per ispezionare l'interfaccia e la classe è andato alla versione v2.0 troppo.

Il montaggio posizionato nella cartella bin dal compilatore era la versione v1.0, da cui il mal di testa.

Il fatto che l'IDE stava mentendo a me ha reso ancora più difficile rendersi conto dell'errore.

Soluzione :. Soppresso riferimenti del progetto da ConsoleApp e readded li

Suggerimento generale: ricompilare tutti gli assembly da zero (per quanto possibile, non può per i pacchetti Nuget ovviamente) e il check francobolli datetime nella cartella bin\debug. Eventuali vecchie assemblee datati sono il problema.

ho affrontato quasi lo stesso problema. Stavo graffiare la mia testa che cosa sta causando questo errore. Ho un controllo incrociato, sono stati implementati tutti i metodi.

In Googling ho ottenuto questo link tra gli altri. Sulla base di @ Paolo McLink commento, questo a due passi risolto il problema.

Riavviare Visual Studio
Clean, Build (Rebuild)

e Errore andato .

Restart VS Plugin

Grazie Paolo:)

Spero che questo aiuti qualcuno che venire attraverso questo errore:)

Inoltre ho incontrato questo problema durante l'esecuzione miei Unittests. L'applicazione ha funzionato bene e senza errori. La causa del problema nel mio caso era che avevo spento la costruzione dei progetti di test. La riattivazione della costruzione dei miei testprojects ha risolto i problemi.

ho visto questo in Visual Studio Pro 2008, quando due progetti assemblee con lo stesso nome, uno di una classe SDF.dll lib, e uno che fa riferimento il lib con il nome di montaggio sdf.exe costruiti. Quando ho cambiato il nome del gruppo di riferimento, l'eccezione è andato via

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

Ecco il mio prendere su questo errore.

Aggiunto un metodo extern, ma la mia pasta era difettoso. Il DllImportAttribute siamo messi su una linea commentata.

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

Garantire l'attributo è stato effettivamente incluso nella fonte risolto il problema.

Ho trovato questo in un servizio WCF a causa di avere un tipo di costruzione x86 selezionato, causando i bidoni a vivere sotto bin \ x86 invece di bin. La selezione di CPU causato la DLL ricompilato per andare alle posizioni corrette (I wont entrare nel dettaglio di come questo è accaduto in primo luogo).

Ho avuto lo stesso problema. Ho capito che il mio assemblaggio, che viene caricato dal programma principale, ha avuto alcuni riferimenti con "copia locale" impostato su true. Queste copie locali dei riferimenti erano alla ricerca di altri riferimenti nella stessa cartella, che non esistevano perché il "copia locale" di altri riferimenti è stata impostata su false. Dopo la soppressione dei riferimenti "accidentalmente" copiato l'errore era andato perché il programma principale è stato impostato per cercare corrette posizioni dei riferimenti. A quanto pare le copie locali dei riferimenti avvitato la sequenza di chiamare perché queste copie locali sono stati utilizzati al posto di quelli originali presenti nel programma principale.

Il messaggio da recepire è che questo errore viene visualizzato a causa l'anello mancante per caricare l'assembly richiesto.

Nel mio caso, stavo cercando di usare TypeBuilder per creare un tipo. TypeBuilder.CreateType ha gettato questa eccezione. Alla fine ho capito che avevo bisogno di aggiungere MethodAttributes.Virtual agli attributi quando si chiama TypeBuilder.DefineMethod per un metodo che aiuta implementa un'interfaccia. Questo perché senza questa opzione, il metodo non implementa l'interfaccia, ma piuttosto un nuovo metodo con la stessa firma, invece (anche senza specificare MethodAttributes.NewSlot).

Come un addendum: questo può verificarsi anche se si aggiorna un pacchetto NuGet che è stato utilizzato per generare un assembly falsi. Diciamo che si installa V1.0 di un pacchetto NuGet e creare un assembly falsi "fakeLibrary.1.0.0.0.Fakes". Successivamente, si aggiorna alla versione più recente del pacchetto NuGet, dire v1.1 che ha aggiunto un nuovo metodo a un'interfaccia. La biblioteca Fakes sta ancora cercando v1.0 della biblioteca. È sufficiente rimuovere il gruppo falso e rigenerarlo. Se questo era il problema, questo sarà probabilmente risolvere il problema.

Ho ricevuto questo errore dopo un recente aggiornamento di Windows. Ho avuto una classe di set di servizi di ereditare da un'interfaccia. L'interfaccia contiene una firma che ha restituito un ValueTuple, abbastanza nuova funzione in C #.

Tutto quello che posso immaginare è che l'aggiornamento di Windows installato uno nuovo, ma anche in modo esplicito riferimento a esso, l'aggiornamento redirect vincolanti, ecc ... Il risultato finale è stato solo cambiando la firma del metodo per qualcosa di "standard" Ti immagino poteva dire.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow