TypeLoadException sagt "keine Implementierung", aber es ist implementiert

Ich habe einen sehr seltsamen Fehler auf unserer Testmaschine. Der Fehler ist:

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

Ich kann einfach nicht verstehen warum. SetShortist in der DummyItemKlasse vorhanden, und ich habe sogar eine Version mit Schreibvorgängen in das Ereignisprotokoll neu kompiliert, um sicherzustellen, dass es sich nicht um ein Bereitstellungs- / Versionsproblem handelt. Das Seltsame ist, dass der aufrufende Code die SetShortMethode nicht einmal aufruft .

HINWEIS - Wenn diese Antwort Ihnen nicht hilft, nehmen Sie sich bitte die Zeit, um durch die anderen Antworten zu scrollen, die seitdem hinzugefügt wurden.

Kurze Antwort

Dies kann passieren, wenn Sie einer Schnittstelle in einer Assembly und dann einer implementierenden Klasse in einer anderen Assembly eine Methode hinzufügen, die implementierende Assembly jedoch neu erstellen, ohne auf die neue Version der Schnittstellenassembly zu verweisen.

In diesem Fall implementiert DummyItem eine Schnittstelle von einer anderen Assembly. Die SetShort-Methode wurde kürzlich sowohl zur Schnittstelle als auch zum DummyItem hinzugefügt. Die Assembly mit DummyItem wurde jedoch unter Bezugnahme auf die vorherige Version der Schnittstellenassembly neu erstellt. Die SetShort-Methode ist also effektiv vorhanden, jedoch ohne die magische Sauce, die sie mit der entsprechenden Methode in der Benutzeroberfläche verknüpft.

Lange Antwort

Wenn Sie versuchen möchten, dies zu reproduzieren, versuchen Sie Folgendes:

1. Erstellen Sie ein Klassenbibliotheksprojekt: InterfaceDef, fügen Sie nur eine Klasse hinzu und erstellen Sie:

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

2. Erstellen Sie ein Bibliotheksprojekt der zweiten Klasse: Implementierung (mit separater Lösung), kopieren Sie InterfaceDef.dll in das Projektverzeichnis und fügen Sie es als Dateireferenz hinzu, fügen Sie nur eine Klasse hinzu und erstellen Sie:

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

3. Erstellen Sie ein drittes Konsolenprojekt: ClientCode, kopieren Sie die beiden DLLs in das Projektverzeichnis, fügen Sie Dateiverweise hinzu und fügen Sie der Hauptmethode den folgenden Code hinzu:

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

4. Führen Sie den Code einmal aus, die Konsole sagt "Hallo Welt"

5. Kommentieren Sie den Code in den beiden DLL-Projekten aus und erstellen Sie ihn neu. Kopieren Sie die beiden DLLs zurück in das ClientCode-Projekt, erstellen Sie sie neu und versuchen Sie es erneut. TypeLoadException tritt auf, wenn versucht wird, die ImplementingClass zu instanziieren.

Zusätzlich zu der bereits erwähnten Antwort des Fragestellers kann Folgendes beachtet werden. Der Grund dafür ist, dass eine Klasse möglicherweise eine Methode mit derselben Signatur wie eine Schnittstellenmethode hat, ohne diese Methode zu implementieren. Der folgende Code veranschaulicht Folgendes:

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

Ich habe dies erhalten, als meine Anwendung keinen Verweis auf eine andere Assembly hatte, die eine Klasse definiert, die von der Methode in der Fehlermeldung verwendet wurde. Das Ausführen von PEVerify ergab einen hilfreicheren Fehler: "Das System kann die angegebene Datei nicht finden."

Ich bin auf dieselbe Nachricht gestoßen, und hier ist, was wir gefunden haben: Wir verwenden DLLs von Drittanbietern in unserem Projekt. Nachdem eine neue Version veröffentlicht wurde, haben wir unser Projekt geändert, um auf die neuen DLLs zu verweisen, und erfolgreich kompiliert.

Die Ausnahme wurde ausgelöst, als ich versuchte, eine der Schnittstellenklassen zur Laufzeit zu instanziieren. Wir haben dafür gesorgt, dass alle anderen Referenzen auf dem neuesten Stand waren, aber immer noch kein Glück. Wir brauchten eine Weile, um (mithilfe des Objektbrowsers) festzustellen, dass der Rückgabetyp der Methode in der Fehlermeldung ein völlig neuer Typ aus einer neuen, nicht referenzierten Assembly war.

Wir haben einen Verweis auf die Baugruppe hinzugefügt und der Fehler ist verschwunden.

• Die Fehlermeldung war ziemlich irreführend, zeigte aber mehr oder weniger in die richtige Richtung (richtige Methode, falsche Meldung).
• Die Ausnahme trat auf, obwohl wir die fragliche Methode nicht angewendet haben.
• Was mich zu der Frage führt: Wenn diese Ausnahme auf jeden Fall ausgelöst wird, warum nimmt der Compiler sie nicht auf?

Ich habe diesen Fehler im folgenden Szenario erhalten.

• Beide Baugruppen A und B verwiesen auf System.Web.Mvc Version 3.0.0.0
• Assembly A verwies auf Assembly B und hatte Klassen, die Schnittstellen von Assembly B mit Methoden implementierten, die Klassen von System.Web.Mvc zurückgaben.
• Assembly A aktualisiert auf System.Web.Mvc Version 4.0.0.0
• In Assembly C wurde der folgende Code ausgeführt (FertPin.Classes.Contact war in Assembly A enthalten):

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

Das Update für mich war das Upgrade der System.Web.Mvc-Referenz in Assembly B auf 4.0.0.0. Scheint jetzt offensichtlich!

Danke an das Originalplakat!

Das andere Mal können Sie diesen Fehler erhalten, wenn Sie eine falsche Version einer signierten Assembly haben. Es ist nicht das normale Symptom für diese Ursache, aber hier war das Szenario, in dem ich es bekam

• Ein asp.net-Projekt enthält Assembly A und Assembly B, B ist stark benannt

• Assembly A verwendet Activator.CreateInstance, um Assembly C zu laden (dh es gibt keinen Verweis auf C, der separat erstellt wird).

• C wurde unter Bezugnahme auf eine ältere Version von Baugruppe B als derzeit vorhanden erstellt

Ich hoffe, das hilft jemandem - ich habe ewig gebraucht, um das herauszufinden.

Ich hatte auch diesen Fehler, der durch eine beliebige CPU-Exe verursacht wurde, die auf beliebige CPU-Assemblys verweist, die wiederum auf eine x86-Assembly verweisen.

Die Ausnahme beschwerte sich über eine Methode für eine Klasse in MyApp.Implementations (Beliebige CPU), die MyApp.Interfaces (Beliebige CPU) ableitete. In fuslogvw.exe fand ich jedoch eine versteckte Ausnahme "Versuch, ein Programm mit einem falschen Format zu laden" von MyApp .CommonTypes (x86), das von beiden verwendet wird.

Ich komme immer wieder darauf zurück ... Viele der Antworten hier erklären hervorragend, was das Problem ist, aber nicht, wie es behoben werden kann.

Die Lösung hierfür besteht darin, die bin-Dateien im veröffentlichten Verzeichnis Ihres Projekts manuell zu löschen. Es werden alle Referenzen bereinigt und das Projekt gezwungen, die neuesten DLLs zu verwenden.

Ich schlage nicht vor, die Löschfunktion der Veröffentlichungstools zu verwenden, da dies dazu neigt, IIS auszuschalten.

Ich habe noch eine andere esoterische Lösung für diese Fehlermeldung. Ich habe mein Zielframework von .Net 4.0 auf 4.6 aktualisiert und mein Unit-Test-Projekt hat mir beim Versuch zu erstellen den Fehler "System.TypeLoadException ... hat keine Implementierung" angezeigt. Es gab auch eine zweite Fehlermeldung über dieselbe angeblich nicht implementierte Methode, die besagte: "Die Aufgabe 'BuildShadowTask' ist unerwartet fehlgeschlagen." Keiner der Ratschläge hier schien zu helfen, also suchte ich nach "BuildShadowTask" und fand einen Beitrag auf MSDN, der mich dazu veranlasste, diese Zeilen mit einem Texteditor aus der csproj-Datei des Unit-Test-Projekts zu löschen.

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

Danach verschwanden beide Fehler und das Projekt wurde erstellt.

Ich bin auf diesen Fehler in einem Kontext gestoßen, in dem ich Autofac und viel dynamisches Laden von Baugruppen verwendet habe.

Während einer Autofac-Auflösungsoperation konnte die Laufzeit eine der Assemblys nicht laden. Die Fehlermeldung beschwerte sich darüber Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. Die Symptome traten auf, wenn sie auf einer Windows Server 2012 R2-VM ausgeführt wurden, jedoch nicht auf Windows 10- oder Windows Server 2016-VMs.

ImplementationAssemblyreferenziert System.Collections.Immutable1.1.37 und enthielt Implementierungen einer IMyInterface<T1,T2>Schnittstelle, die in einem separaten definiert wurde DefinitionAssembly. DefinitionAssemblyreferenziert System.Collections.Immutable1.1.36.

Die Methoden, von IMyInterface<T1,T2>denen "nicht implementiert" wurden, hatten Parameter vom Typ IImmutableDictionary<TKey, TRow>, der in definiert istSystem.Collections.Immutable .

Die tatsächliche Kopie von System.Collections.Immutableim Programmverzeichnis gefunden wurde Version 1.1.37. Auf meiner Windows Server 2012 R2-VM enthielt der GAC eine Kopie von System.Collections.Immutable1.1.36. Unter Windows 10 und Windows Server 2016 enthielt der GAC eine Kopie vonSystem.Collections.Immutable 1.1.37. Der Ladefehler trat nur auf, wenn der GAC die ältere Version der DLL enthielt.

Die Hauptursache für den Fehler beim Laden der Baugruppe waren also die nicht übereinstimmenden Verweise auf System.Collections.Immutable. Die Schnittstellendefinition und -implementierung hatte identisch aussehende Methodensignaturen, hing jedoch tatsächlich von verschiedenen Versionen von abSystem.Collections.Immutable , was bedeutete, dass die Laufzeit die Implementierungsklasse nicht als mit der Schnittstellendefinition übereinstimmend betrachtete.

Das Hinzufügen der folgenden Bindungsumleitung zu meiner Anwendungskonfigurationsdatei hat das Problem behoben:

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

Ich habe dies mit einer "rautenförmigen" Projektabhängigkeit erhalten:

• Projekt A verwendet Projekt B und Projekt D.
• Projekt B verwendet Projekt D.

Ich habe Projekt A neu kompiliert, aber nicht Projekt B, wodurch Projekt B die alte Version der Project D-DLL "einfügen" konnte

Dies trat auf, als ich ein Projekt (und den Assemblynamen) umbenannte, von dem ein ASP.NET-Projekt abhing. Typen im Webprojekt implementierten Schnittstellen in der abhängigen Assembly. Trotz der Ausführung von Clean Solution über das Menü "Erstellen" blieb die Assembly mit dem vorherigen Namen im binOrdner und bei der Ausführung meines Webprojekts

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

Die obige Ausnahme wurde ausgelöst und es wurde beanstandet, dass Schnittstellenmethoden in den implementierenden Webtypen nicht tatsächlich implementiert wurden. Durch manuelles Löschen der Assembly im binOrdner des Webprojekts wurde das Problem behoben.

Ich habe diesen Fehler auch erhalten, als ich zuvor die Codeabdeckung während des Komponententests für eine der Baugruppen aktiviert hatte. Aus irgendeinem Grund "pufferte" Visual Studio die alte Version dieser bestimmten DLL, obwohl ich sie aktualisiert hatte, um eine neue Version der Schnittstelle zu implementieren. Durch Deaktivieren der Codeabdeckung wurde der Fehler behoben.

Dieser Fehler kann auch verursacht werden, wenn eine Assembly mit Assembly.LoadFrom (String) geladen wird und auf eine Assembly verweist, die bereits mit Assembly.Load (Byte []) geladen wurde.

Beispielsweise haben Sie die Assemblys, auf die in der Hauptanwendung verwiesen wird, als Ressourcen eingebettet, aber Ihre App lädt Plug-Ins aus einem bestimmten Ordner.

Anstelle von LoadFrom sollten Sie Load verwenden. Der folgende Code erledigt den Job:

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

Eine weitere Erklärung für diese Art von Problem mit verwaltetem C ++.

Wenn Sie versuchen, eine Schnittstelle zu stubben, die in einer Assembly definiert ist, die mit verwaltetem C ++ erstellt wurde und eine spezielle Signatur hat, wird beim Erstellen des Stubs die Ausnahme angezeigt.

Dies gilt für Rhino Mocks und wahrscheinlich für jedes spöttische Framework, das verwendet wird System.Reflection.Emit.

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

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

Die Schnittstellendefinition erhält die folgende Signatur:

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

Beachten Sie, dass die C ++ Typ longzuordnet System.Int32(oder einfach intin C #). Es ist das etwas Dunkle, dasmodopt das Problem verursacht, wie es von Ayende Rahien auf der Mailingliste von Rhino Mocks angegeben wurde .

Ich habe gerade eine Lösung von MVC3 auf MVC5 aktualisiert und die gleiche Ausnahme von meinem Unit-Test-Projekt erhalten.

Überprüfte alle Referenzen auf alte Dateien und stellte schließlich fest, dass ich in meinem Unit-Test-Projekt einige BindingRedirects für Mvc ausführen musste.

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

In meinem Fall hat es geholfen, die WinForms Toolbox zurückzusetzen.

Ich habe die Ausnahme beim Öffnen eines Formim Designer bekommen; Das Kompilieren und Ausführen des Codes war jedoch möglich und der Code verhielt sich wie erwartet. Die Ausnahme trat in einem lokalen aufUserControl Implementierung einer Schnittstelle aus einer meiner referenzierten Bibliotheken auf. Der Fehler trat auf, nachdem diese Bibliothek aktualisiert wurde.

Diese UserControl wurde in der WinForms Toolbox aufgeführt. Wahrscheinlich hat Visual Studio einen Verweis auf eine veraltete Version der Bibliothek gespeichert oder irgendwo eine veraltete Version zwischengespeichert.

So habe ich mich von dieser Situation erholt:

1. Klicken Sie mit der rechten Maustaste auf die WinForms Toolbox und klicken Sie Reset Toolboxim Kontextmenü auf. (Dadurch werden benutzerdefinierte Elemente aus der Toolbox entfernt.)
   In meinem Fall wurden die Toolbox-Elemente auf ihren Standardzustand zurückgesetzt. Der Zeigerpfeil fehlte jedoch in der Toolbox.
2. Schließen Sie Visual Studio.
   In meinem Fall wurde Visual Studio mit einer Verstoßausnahme beendet und abgebrochen.
3. Starten Sie Visual Studio neu.
   Jetzt läuft alles reibungslos.

FWIW, ich habe dies erhalten, als es eine Konfigurationsdatei gab, die zu einer nicht vorhandenen Version einer Assembly weitergeleitet wurde, auf die verwiesen wurde. Fusionsprotokolle für den Gewinn!

Ich habe diesen Fehler erhalten, weil ich eine Klasse in einer Assembly 'C' hatte, die sich in Version 4.5 des Frameworks befand, eine Schnittstelle in Assembly 'A' implementierte, die sich in Version 4.5.1 des Frameworks befand und als Basisklasse für Assembly diente 'B' war auch in Version 4.5.1 des Frameworks. Das System hat die Ausnahme ausgelöst, als versucht wurde, die Baugruppe 'B' zu laden. Außerdem hatte ich auf allen drei Assemblys einige Nuget-Pakete installiert, die auf .net 4.5.1 abzielen. Aus irgendeinem Grund wurde die Nuget-Referenz erfolgreich erstellt, obwohl sie in Baugruppe 'B' nicht angezeigt wurde.

Es stellte sich heraus, dass das eigentliche Problem darin bestand, dass die Assemblys auf verschiedene Versionen eines Nuget-Pakets verwiesen, das die Schnittstelle enthielt, und dass sich die Schnittstellensignatur zwischen den Versionen geändert hatte.

In meinem Fall hatte ich zuvor auf ein mylibProjekt in einem Geschwisterordner außerhalb des Repos verwiesen - nennen wir das so v1.0.

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

Später habe ich es richtig gemacht und über ein Git-Submodul verwendet - nennen wir das so v2.0. Ein Projekt wurde consoleAppjedoch nicht ordnungsgemäß aktualisiert. Es bezog sich immer noch auf das alte v1.0Projekt außerhalb meines Git-Projekts.

Verwirrenderweise zeigte die Visual Studio-IDE den Pfad als Projekt , obwohl dies *.csprojeindeutig falsch war und darauf hinwies ! F12 zur Überprüfung der Schnittstelle und Klasse ging an diev1.0v2.0v2.0 Version.

Die Assembly, die vom Compiler in den Ordner bin gelegt wurde, war die v1.0 Version, daher die Kopfschmerzen.

Die Tatsache, dass die IDE mich angelogen hat, machte es besonders schwierig, den Fehler zu erkennen.

Lösung : Projektreferenzen aus gelöscht ConsoleAppund erneut gelesen.

Allgemeiner Tipp: Kompilieren Sie alle Assemblys von Grund auf neu (wenn möglich natürlich nicht für Nuget-Pakete) und überprüfen Sie die Datums- / Uhrzeitstempel im bin\debugOrdner. Alle alten datierten Baugruppen sind Ihr Problem.

Ich hatte fast das gleiche Problem. Ich habe mir am Kopf gekratzt, was diesen Fehler verursacht. Ich habe überprüft, alle Methoden wurden implementiert.

Beim Googeln habe ich unter anderem diesen Link bekommen. Basierend auf dem Kommentar von @Paul McLink wurde das Problem durch diese beiden Schritte behoben.

1. Starten Sie Visual Studio neu
2. Reinigen, bauen (neu bauen)

und der Fehler weg .

Starten Sie das VS Plugin neu

Danke Paul :)

Hoffe das hilft jemandem, der auf diesen Fehler stößt :)

Ich bin auch auf dieses Problem gestoßen, als ich meine Unittests ausgeführt habe. Die Anwendung lief einwandfrei und fehlerfrei. Die Ursache des Problems in meinem Fall war, dass ich den Aufbau der Testprojekte abgeschaltet hatte. Das erneute Aktivieren des Aufbaus meiner Testprojekte löste die Probleme.

Ich habe dies in Visual Studio Pro 2008 gesehen, als zwei Projekte Assemblys mit demselben Namen erstellten, eines eine Klasse lib SDF.dll und eines, das auf die lib mit dem Assemblynamen sdf.exe verwies. Als ich den Namen der referenzierenden Assembly änderte, verschwand die Ausnahme

Dies bedeutet einfach, dass das Implementierungsprojekt in meinen Fällen veraltet ist. Die DLL mit der Schnittstelle wurde neu erstellt, aber die Implementierungs-DLL war veraltet.

Hier ist meine Einstellung zu diesem Fehler.

Eine externMethode wurde hinzugefügt , aber meine Paste war fehlerhaft. Der DllImportAttributewurde in eine auskommentierte Zeile gesetzt.

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

Das Problem wurde behoben, indem sichergestellt wurde, dass das Attribut tatsächlich in der Quelle enthalten war.

Ich habe dies in einem WCF-Dienst erhalten, weil ein x86-Build-Typ ausgewählt wurde, wodurch die Bins unter bin \ x86 anstelle von bin leben. Durch Auswahl einer beliebigen CPU wurden die neu kompilierten DLLs an die richtigen Speicherorte verschoben (ich werde nicht näher darauf eingehen, wie dies überhaupt geschehen ist).

Ich hatte das gleiche Problem. Ich habe herausgefunden, dass meine Assembly, die vom Hauptprogramm geladen wird, einige Referenzen mit "Copy Local" auf true gesetzt hat. Diese lokalen Kopien von Referenzen suchten nach anderen Referenzen in demselben Ordner, die nicht vorhanden waren, da "Lokal kopieren" anderer Referenzen auf false gesetzt war. Nach dem Löschen der "versehentlich" kopierten Referenzen war der Fehler behoben, da das Hauptprogramm so eingestellt war, dass nach korrekten Referenzpositionen gesucht wurde. Anscheinend haben die lokalen Kopien der Referenzen die Reihenfolge der Aufrufe verkorkst, da diese lokalen Kopien anstelle der im Hauptprogramm vorhandenen Originalkopien verwendet wurden.

Die Meldung zum Mitnehmen lautet, dass dieser Fehler aufgrund des fehlenden Links zum Laden der erforderlichen Baugruppe angezeigt wird.

In meinem Fall habe ich versucht TypeBuilder, einen Typ zu erstellen. TypeBuilder.CreateTypewarf diese Ausnahme. Schließlich wurde mir klar, dass ich MethodAttributes.Virtualdie Attribute ergänzen musste , wenn ich TypeBuilder.DefineMethodeine Methode aufrief, die bei der Implementierung einer Schnittstelle hilft. Dies liegt daran, dass die Methode ohne dieses Flag nicht die Schnittstelle implementiert, sondern stattdessen eine neue Methode mit derselben Signatur (auch ohne Angabe MethodAttributes.NewSlot).

Als Ergänzung: Dies kann auch auftreten, wenn Sie ein Nuget-Paket aktualisieren, mit dem eine gefälschte Assembly generiert wurde. Angenommen, Sie installieren V1.0 eines Nuget-Pakets und erstellen eine Fakes-Assembly "fakeLibrary.1.0.0.0.Fakes". Als Nächstes aktualisieren Sie auf die neueste Version des Nuget-Pakets, z. B. v1.1, mit der einer Schnittstelle eine neue Methode hinzugefügt wurde. Die Fakes-Bibliothek sucht noch nach Version 1.0 der Bibliothek. Entfernen Sie einfach die gefälschte Baugruppe und regenerieren Sie sie. Wenn dies das Problem war, wird es wahrscheinlich behoben.

Ich habe diesen Fehler nach einem kürzlich durchgeführten Windows-Update erhalten. Ich hatte eine Serviceklasse festgelegt, die von einer Schnittstelle geerbt werden sollte. Die Schnittstelle enthielt eine Signatur, die ein ValueTuple zurückgab, eine ziemlich neue Funktion in C #.

Alles, was ich vermuten kann, ist, dass das Windows-Update ein neues installiert hat, aber sogar explizit darauf verweist, Bindungsumleitungen aktualisiert usw. Das Endergebnis war nur die Änderung der Signatur der Methode in etwas "Standard", könnte man sagen.