TypeLoadException siger ‘nej gennemførelse”, men det er gennemført

Jeg har fået en meget underlig bug på vores testmaskine. Fejlen er:

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

Jeg kan bare ikke forstå hvorfor. SetShort er der i DummyItem klasse, og jeg har selv genoversat en version med skriver til hændelsesloggen, bare for at gøre sikker på, at det ikke er en implementering/versionering spørgsmål. Det underlige er, at den kaldende kode ikke selv kalde SetShort metode.

Jeg elsker, hvordan dine delte din oplevelse med lokalsamfundet for at hjælpe os alle, og selv opfordrede os til at læse de andre svar, også, tak. Desværre, ingen af forslagene virkede for mig. Ønsker du at vide, hvad der gjorde, at ender med at arbejde for mig? Genstart Af Visual Studio. Hvorfor har jeg ikke prøve det først?
Tak Paulus, efter at have læst din kommentar, jeg har prøvet, at man først. Arbejdede som en charme 🙂
tak Paul, spar mig nogle timer uafbrudt skrabe mit hoved som en abe…
Også, efter at VS 2017 15.7 opdatering, VS fortæller dig om at genstarte. Du kan ikke have gjort, at du (ligesom mig, på grund af møder, som jeg har glemt). Jeg fik craploads af erros som disse…
Bare for at tilføje min 2p – jeg fik dette problem, når du kører unit tests i MsTest. De klasser, der under test var en underskrevet forsamling. En anden version af denne montage er sket for at være i GAC. MsTest var picking up GAC ville forsamling i stedet for at bruge den fra mappen bin, og forsøger at køre tests mod det, som tydeligvis ikke fungerer. Løsningen var at fjerne GAC ville montage

OriginalForfatteren Benjol | 2009-06-04

30 svar

  1. 226

    BEMÆRK – Hvis dette svar ikke hjælpe dig, bedes du venligst tage dig tid til at rulle ned gennem de andre svar, som folk har tilføjet siden.

    Korte svar

    Dette kan ske, hvis du tilføjer en metode til en grænseflade i en forsamling, og derefter til at gennemføre en klasse i en anden forsamling, men du genopbygge gennemførelse af forsamlingen uden at referere til den nye version af interface forsamling.

    I dette tilfælde, DummyItem implementerer et interface, anden samling. Den SetShort metode for nylig blev føjet til både interface og DummyItem – men den samling, der indeholder DummyItem blev genopbygget og referere til den tidligere version af interface forsamling. Så SetShort metode er faktisk der, men uden det magiske sauce, der forbinder det til den tilsvarende metode i grænsefladen.

    Lange svar

    Hvis du ønsker at prøve at gengive denne, kan du prøve følgende:

    1. Oprette en klasse bibliotek projekt: InterfaceDef, lige tilføje en klasse, og bygge videre på:

      public interface IInterface
      {
          string GetString(string key);
          //short GetShort(string key);
      }
    2. Skabe en anden klasse bibliotek projekt: Implementering (med separat løsning), kopi InterfaceDef.dll i projektet biblioteket som fil reference, lige tilføje en klasse, og bygge videre på:

      public class ImplementingClass : IInterface
      {
          #region IInterface Members
          public string GetString(string key)
          {
              return "hello world";
          }
      
          //public short GetShort(string key)
          //{
          //   return 1;
          //}
          #endregion
      }
    3. Skabe en tredje, konsol projekt: ClientCode, kopi af de to dll ‘ er i dette projekt mappe, tilføj fil referencer, og tilføj følgende kode i Main-metoden:

       IInterface test = new ImplementingClass();
       string s = test.GetString("dummykey");
       Console.WriteLine(s);
       Console.ReadKey();
    4. Køre den kode, når konsollen siger “hello world”

    5. Udkommenter kode i de to dll-projekter og genopbygge – kopi af de to dll ‘ er tilbage i ClientCode projekt, genopbygge og prøve at køre igen. TypeLoadException opstår, når de forsøger at instantiere ImplementingClass.

    Du måske nødt til at tilføje, at Konsollen app ‘ en skal blive genopbygget med nye Dll-filer som reference. Blot kopierer DLL vil ikke arbejde, og det kunne være på grund af version mismatch (jeg.e når du kompilere kilde DLL version vil ændre sig). Er det retfærdigt at forstå?
    god pointe – for mig ‘i gang igen’ stiltiende F5. Jeg har opdateret svar. Selvfølgelig er alt dette ville ikke være sket med en anstændig source control værktøj, men må ikke få mig startet på dette emne…
    Hmm, det ser ud som om Microsoft ‘ s fejlmeddelelse, der er en fejl i det – det er at sige, at en metode til klasse “DummyItem” ikke har en implementering, som er åbenlyst falsk…. virkelig, problemet er, at en metode til grænsefladen, er ikke implementeret AF DummyItem.
    enhver god endelige løsning om det ? Hvad er løsningen var Microsoft anbefalede ?
    Løsningen er at slette bin filer manuelt. De offentliggør ikke se dem som ændret sig, så er du nødt til at tvinge den til at have det nyeste. Dette er virkelig bemærkes i den øverste bedømt svar!

    OriginalForfatteren Benjol

  2. 32

    I tillæg til, hvad asker ‘ s egne svar, der allerede er nævnt, kan det være værd at bemærke følgende. Grunden til at dette sker er, fordi det er muligt for en klasse at have en metode med samme signatur som et interface metode uden gennemførelse af denne metode. Følgende kode viser, at:

    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
    Dette løste det for mig, med den ekstra niveau af formørkelse, at den Metode, den hævdede, at der manglede blev erklæret i et interface, der gennemføres af en overordnet klasse, og erklærede igen i underklasse. Fjernelse af dubletter fra underklasse lavet den fejl at gå væk.

    OriginalForfatteren Timwi

  3. 21

    Jeg fik dette, når min ansøgning ikke har en reference til en anden assembly, der definerer en klasse som den metode, der i den fejlmeddelelse, der anvendes. Køre PEVerify gav mere brugbar fejlmeddelelse: “systemet kan ikke finde den angivne fil.”

    OriginalForfatteren silent tone

  4. 18

    Jeg kom på tværs af den samme besked, og her er hvad vi har fundet:
    Vi bruge tredjeparts-dll ‘ er i vores projekt. Efter en ny frigivelse af dem, der var ude, vi har ændret vores projekt til at pege på det nye sæt af dll-filer og samlet korrekt.

    Undtagelse var kastet, når jeg forsøgte at instatiate en af deres grænseflader klasser under kørslen.
    Vi sørgede for at alle de andre henvisninger er op til dato, men stadig uden held.
    Vi havde brug for en samtidig spot (ved hjælp af Object Browser) at returnere type af metode i den fejlmeddelelse, var en helt ny type fra en ny, unreferenced forsamling.

    Vi tilføjet en henvisning til samling og fejlen er forsvundet.

    • Fejlmeddelelsen var ret misvisende, men pegede mere eller mindre til den rigtige retning (højre metode, forkert signal).
    • Undtagelse opstod, selv om vi ikke bruger metoden i spørgsmålet.
    • Hvilket fører mig frem til spørgsmålet: Hvis denne undtagelse er smidt i alle tilfælde, hvorfor oversætteren ikke samle det op?

    OriginalForfatteren Ben

  5. 16

    Jeg modtog denne fejlmeddelelse i følgende scenario.

    • Begge Forsamlinger A og B der refereres til Systemet.Web.Mvc Version 3.0.0.0
    • Forsamling En refereres Samling B og havde klasser, som har gennemført grænseflader fra Forsamlingen B med metoder, der vendte tilbage klasser fra Systemet.Web.Mvc.
    • Forsamling, Et opgraderet til Systemet.Web.Mvc Version 4.0.0.0
    • Forsamling C løb koden nedenfor (FertPin.Klasser.Der var kontakt, der er indeholdt i En Forsamling):

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

    Fix for mig var, at opgradere Systemet.Web.Mvc reference i Forsamlingen B for at 4.0.0.0. Synes indlysende nu!

    Tak til den oprindelige plakat!

    Jeg havde noget lignende, men den anden vej rundt med versioner. En metode, målretning .NET 2, returneres en type fra v2 af Systemet.Windows.Former. Dens tilsidesættes gennemførelse i en .NETTO 4-målrettet forsamlingen vendte tilbage samme type, men fra v4 af Systemet.Windows.Former. Det er udarbejdet fint, men ReflectionOnlyLoadFrom ikke kan lide det.
    Jeg havde et lignende problem, der er forårsaget af loading typer, der er målrettet .NET2 i en ReflectionOnly forbindelse med en .NET4 ansøgning. Jeg arbejdede rundt om problemet ved at omdirigere alle forsamling anmodninger .NET2 centrale forsamlinger til deres .NET4 kolleger i AppDomain.ReflectionOnlyAssemblyResolve begivenhed.
    Dette var mit spørgsmål 🙂 Tak!

    OriginalForfatteren Damien Sawyer

  6. 13

    Den anden gang du kan få denne fejlmeddelelse, hvis du har en forkert version af en underskrevet forsamling. Det er ikke et normalt symptom for denne sag, men her var det scenarie, hvor jeg fik det

    • en asp.net projektet indeholder En forsamling og montage B, B er stærkt navngivne

    • forsamling En bruger Aktivator.CreateInstance at indlæse forsamling C (dvs der er ingen reference til C, som er bygget separat)

    • C blev bygget henvisning til en ældre version af forsamlingen B, end det er i øjeblikket til stede

    håber det hjælper nogen – det tog mig lang tid at finde ud af dette.

    OriginalForfatteren Tim

  7. 9

    Jeg havde denne fejl også, at det var forårsaget af en hvilken som Helst CPU exe refererer du til Enhver CPU forsamlinger, der igen refereres til en x86-forsamling.

    Undtagelse klagede over, om en metode på et klasse i min app.Implementeringer (CPU), som er afledt Mitprogram.Grænseflader (En CPU), men i fuslogvw.exe jeg fandt et skjult ‘forsøg på at indlæse program med et forkert format” undtagelse fra min app.CommonTypes (x86), som bruges af både.

    OriginalForfatteren Richard Dingwall

  8. 6

    Jeg har endnu en esoterisk løsning til denne fejlmeddelelse. Jeg opgraderet mit mål ramme fra .Net 4,0 4,6, og min unit-test-projektet var at give mig ” – System.TypeLoadException…ikke har en gennemførelse” fejl når jeg forsøgte at opbygge. Det gav også en anden fejlmeddelelse om den samme angiveligt ikke-implementerede metode, der sagde “De ” BuildShadowTask’ opgaven ikke uventet.” Ingen af de råd, der her syntes at hjælpe, så jeg søgte efter “BuildShadowTask”, og fandt et indlæg på MSDN, som ledede mig til at bruge en tekst editor til at slette disse linjer fra unit test projektets csproj fil.

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

    Efter, at både fejl gik derfra, og projektet er bygget.

    Dette var svaret til mig. Jeg løb ind i denne fejlmeddelelse, efter at jeg har opgraderet fra .NET 4.5 4.6.

    OriginalForfatteren Tony Pulokas

  9. 6

    Jeg er stødt på denne fejl i en situation, hvor jeg var ved hjælp af Autofac og en masse dynamisk samling ilægning.

    Mens de udfører en Autofac beslutning drift, runtime ville undlade at indlæse en af de forsamlinger. Den fejlmeddelelse, klagede over, at Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. Symptomerne opstod, når du kører på en Windows Server 2012 R2 VM, men gjorde ikke opstår på Windows 10 eller Windows Server 2016 Fos.

    ImplementationAssembly refereres System.Collections.Immutable 1.1.37, og indeholdt implementeringer af en IMyInterface<T1,T2> grænseflade, som blev defineret i en separat DefinitionAssembly. DefinitionAssembly refereres System.Collections.Immutable 1.1.36.

    Metoder fra IMyInterface<T1,T2>, som var “ikke implementeret” havde parametre af typen IImmutableDictionary<TKey, TRow>, som er defineret i System.Collections.Immutable.

    Den faktiske kopi af System.Collections.Immutable fundet i program-mappen blev version 1.1.37. På min Windows Server 2012 R2 VM, GAC indeholdt en kopi af System.Collections.Immutable 1.1.36. På Windows-10 og Windows Server 2016, GAC indeholdt en kopi af System.Collections.Immutable 1.1.37. Lastning fejl kun sted, når de GAC indeholdt ældre version af DLL.

    Så, den egentlige årsag til forsamlingen belastning fiasko var misforholdet henvisninger til System.Collections.Immutable. Interface definition og gennemførelse havde identiske udseende metode signaturer, men faktisk afhang af forskellige versioner af System.Collections.Immutable, hvilket betød, at runtime ikke overveje gennemførelsen klassen til at matche interface definition.

    At tilføje følgende bindende omdirigere til min ansøgning config-fil fast spørgsmålet:

    <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>
    Kan jeg spørge dig, hvordan du fundet det? Gjorde du bruger en ikke-standard debugging teknik? Jeg får den samme fejl, men jeg tror, at det er forårsaget af en anden dll, som jeg allerede har en bindende omdirigere til immutables.
    Hmm. Det var et stykke tid siden. Jeg tror, det vigtigste fingerpeg om, var, at de “ikke-udnyttede” – metoden, parametre, der bruges typer fra System.Collections.Immutable. I mit tilfælde, at der ikke var mange andre kandidat-parameter eller vende tilbage typer i de berørte metode. Jeg kan også huske at bruge ILSpy til at inspicere afhængighed af metadata i de indsamlede “DefinitionAssembly” og “ImplementationAssembly” Dll ‘ er, der specifikt ser på de versioner af referencer.
    Tak så meget! 😉 Jeg har installeret ILSpy extension til Visual Studio og kiggede på Referencer gren, der var en for System.Net.Http pakke, jeg har tilføjet den dependentAssembly element for det og kopieret info fra ILSpy og det virker nu, fejlen er væk!
    Jeg regnede ud, som var den dårlige GAC montering ved at sætte dette i koden og sætte et breakpoint lige efter det for at se på de værdier, og se, to versioner af Systemet.Netto.Http blev indlæst: var loadedAssemblies = fra en i AppDomain.CurrentDomain.GetAssemblies() orderby en.FullName vælg (en.FullName, a);

    OriginalForfatteren Hydrargyrum

  10. 5

    Jeg fik denne med en “diamant” – formet projektet afhængighed:

    • Projektet En bruger Projekt B og Projekt D
    • Projekt B Projekt bruger D

    Jeg genoversat projekt A, men ikke til Projekt B, som tillod Projekt B for at “tilføre” den gamle version af Projektet D dll

    Ja, jeg kan godt lide at tænke på, at som Renault problem
    Jeg tror, jeg havde en lignende version af dette problem, men kun mellem to projekter. Jeg har samlet den nye manuelt. Efter at det fungerede uden problemer.

    OriginalForfatteren Serge Desmedt

  11. 5

    Jeg er stødt på, når jeg omdøbt til et projekt (og samling navn), som blev afhang af en ASP.NET -projektet. Typer i web-projektet gennemføres grænseflader i den afhængige forsamling. Til trods for udførelse af Ren-Løsning fra menuen Build, samling med det tidligere navn forblev i bin mappe, og når min web-projekt udført

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

    ovenstående undtagelse blev kastet, klager over, at interface-metoder i gennemførelsen af web-typer var faktisk ikke gennemført. Manuelt at slette den samling i web-projektet er bin mappe løst problemet.

    OriginalForfatteren G-Wiz

  12. 5

    Jeg holde kommer tilbage til dette…
    Mange af svarene her gør et stort stykke arbejde for at forklare, hvad problemet er, men ikke hvordan man kan løse det.

    Løsningen på dette er at du manuelt slette bin filer i dine projekter offentliggjort bibliotek. Det vil rydde op i alle de referencer og tvinge projektet til at bruge den nyeste Dll-filer.

    Jeg ikke foreslår at bruge offentliggøre værktøjer Slette funktion, fordi det har en tendens til at smide ud, IIS.

    Jeg har fundet dette at være tilfældet i en fælles web-projektet, for jeg var der afspejler en forsamling i en anden (brug LoadFile), rense og genopbygge virkede ikke – sletning af alle filer fra mappen bin, af begge projekter, der gjorde arbejdet. Cheers for forslaget!
    Jeg var nødt til at gøre en IIS-reset så godt, fordi netop dette projekt er at bruge IIS lokalt (desværre).

    OriginalForfatteren DJ.

  13. 4

    Jeg fik også denne fejl når jeg tidligere havde aktiveret Kode Dækning under unit testing til en af de forsamlinger. For nogle grund til Visual Studio “buffer” den gamle version af denne bestemt DLL, selv om jeg havde opdateret det at gennemføre en ny version af interfacet. Deaktivering af kodedækning sluppet af fejl.

    OriginalForfatteren Kyberias

  14. 3

    En anden forklaring på denne type problem med managed C++.

    Hvis du forsøger at stub et interface, der er defineret i en forsamling, der er oprettet ved hjælp managed C++, der har en særlig signatur, du vil få den undtagelse, når stub er oprettet.

    Dette er sandt for Rhino Mocks og sandsynligvis enhver mocking framework, der bruger System.Reflection.Emit.

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

    Interface definition får følgende signatur:

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

    Bemærk, at C++ type long kort til System.Int32 (eller blot int i C#). Det er noget uklar modopt, der er årsag til problemet som det fremgår af Ayende Rahien på Rhino Mocks mailing liste .

    Jeg havde denne fejl, når jeg brugte den datatype System::Byte. Jeg har ændret signatur til at acceptere en unsigned short og himlen blev blå igen.

    OriginalForfatteren Martin Liversage

  15. 3

    Denne fejl kan også opstå, hvis en forsamling, der er lagt i ved brug Forsamling.LoadFrom(String), og der er henvisning til en forsamling, som allerede var indlæst ved hjælp af Forsamlingen.Indlæsning(Byte[]).

    For eksempel, at du har integreret den vigtigste anvendelse er refereres forsamlinger som ressourcer, men din app masser plugins fra en bestemt mappe.

    I stedet for at bruge LoadFrom du skal bruge Belastning. Følgende kode vil gøre jobbet:

    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;
    }
    enhver fuld source kode prøve ?

    OriginalForfatteren FrankCoder

  16. 3

    Jeg har lige opgraderet en løsning fra MVC3 at MVC5, og begyndte at modtage de samme bortset fra min Unit test projekt.

    Tjekket alle henvisninger på udkig efter gamle filer, senerer opdagede, at jeg havde brug for at gøre nogle bindingRedirects for Mvc, i min enhed test projekt.

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

    OriginalForfatteren shenku

  17. 3

    I mit tilfælde hjalp det at nulstille WinForms Værktøjskasse.

    Jeg fik undtagelse, når du åbner en Form i designer; men, kompilering og kører koden var muligt og kode opførte sig som forventet. Undtagelsen opstod i en lokal UserControl at implementere et interface, en af mine henvises til biblioteker. Fejlen opstod efter dette bibliotek blev opdateret.

    Dette UserControl blev opført i WinForms Værktøjskasse. Sandsynligvis Visual Studio holdt en henvisning til en forældet version af biblioteket, eller var caching en forældet version eller andet sted.

    Her er hvordan jeg genvundet fra denne situation:

    1. Højre klik på WinForms Værktøjskasse, og klik på Reset Toolbox i den sammenhængsafhængige menu. (Dette fjerner brugerdefinerede elementer fra Værktøjskassen).

      I mit tilfælde Værktøjskassen punkter blev restaureret til deres oprindelige tilstand; men de Pointer-pil manglede i Værktøjskassen.
    2. Tæt Visual Studio.

      I mit tilfælde Visual Studio afsluttes med en krænkelse undtagelse og afbrudt.
    3. Genstarte Visual Studio.

      Nu alt kører problemfrit.

    OriginalForfatteren Olivier Jacot-Descombes

  18. 3

    FWIW, fik jeg dette, når der var en config-fil, der omdirigeret til en ikke-eksisterende version af en refereres samling. Fusion logs for the win!

    OriginalForfatteren Tilman

  19. 3

    Jeg fik denne fejl, fordi jeg havde en klasse i en forsamling, ‘C’, der var på version 4.5 af den ramme, implementere et interface i assembly ‘En” som var på version 4.5.1 af de rammer, og der tjener som base klasse til forsamlingen, “B”, som også var på version 4.5.1 af rammen. Systemet kastede den undtagelse, mens du forsøger at indlæse forsamling ‘B’. Derudover, havde jeg installeret nogle nuget pakker rettet mod .net 4.5.1 på alle tre samlinger. For nogle grund, selv om den nuget referencer var ikke vises i forsamlingen ‘B’, det var ved at bygge med succes.

    Det viste sig, at det virkelige problem var, at de forsamlinger, var refererer til forskellige versioner af en nuget pakke, der indeholdt interface og interface underskrift havde ændret sig mellem versioner.

    OriginalForfatteren Tolu

  20. 3

    I mit tilfælde havde jeg tidligere har henvist til en mylib projekt i en søskende mappe uden for repo – lad os kalde det v1.0.

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

    Senere gjorde jeg det korrekt og anvendes til det via et git submodule – lad os kalde det v2.0.
    Et projekt consoleApp dog ikke blev opdateret korrekt. Det var stadig referere til den gamle v1.0 projekt uden for min git-projekt.

    Forvirrende, selvom *.csproj var helt forkert, og peger på v1.0, Visual Studio IDE viste den vej, som v2.0 projekt!
    F12 for at inspicere interface og klasse gik til v2.0 version også.

    Samling placeres i mappen bin, som compileren var v1.0 version, og dermed hovedpine.

    Det faktum, at den IDE var at lyve for mig gjorde det ekstra svært at indse fejlen.

    Løsning: Slettet projekt referencer fra ConsoleApp og readded dem.

    Generelle Tip: Genkompilere alle samlinger fra bunden (hvis det er muligt, kan ikke for nuget pakker selvfølgelig) og ind datetime frimærker i bin\debug mappe. Alle gamle dateret forsamlinger er dit problem.

    OriginalForfatteren fiat

  21. 3

    Jeg havde næsten samme problem. Jeg blev skrabe mit hoved, hvad der er årsag til denne fejl.
    Jeg krydser markeret, vil alle de metoder, der blev gennemført.

    På Googling fik jeg dette link, blandt andre. Baseret på @Paul McLink kommentar, Denne to skridt løst problemet.

    1. Genstarte Visual Studio
    2. Ren, Byg (Genopbyg)

    og fejl gået.

    Genstart VS Plugin

    Tak Paul 🙂

    Håber, at dette hjælper en person, der kommer på tværs af denne fejl 🙂

    OriginalForfatteren Kgn-web

  22. 2

    Jeg løb også ind i dette problem, mens du kører mine unittests. Programmet kørte fint og uden fejl.
    Årsagen til problemet, i mit tilfælde var, at jeg havde slukket for opbygning af test-projekter.
    Genaktivere bygningen af min testprojects løst de problemer.

    OriginalForfatteren Wesley

  23. 2

    Jeg så det i Visual Studio Pro 2008, hvor to projekter, som er bygget samlinger med samme navn, den ene en klasse lib SDF.dll og en, der refereres til lib-med samling navn sdf.exe.
    Når jeg har ændret navn refererer til montering, undtagen gik væk

    OriginalForfatteren N romaai

  24. 2

    Her er min tage på dette fejl.

    Tilføjet en extern metode, men min indsætte var defekt. Den DllImportAttribute fik sat på en kommenteret ud linje.

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

    Sikre den attribut, der var medtaget i kilde løst problemet.

    OriginalForfatteren Will

  25. 1

    Jeg fik denne i en WCF service, på grund af at have en x86-byg valgte type, der forårsager bisn at leve under bin\x86 det i stedet for bakke. At vælge en CPU forårsaget genoversat Dll ‘ er til at gå til de korrekte placeringer (jeg vil ikke gå i detaljer med, hvordan det skete i første omgang).

    OriginalForfatteren Ruben Bartelink

  26. 1

    Det betyder blot, at gennemførelse projektet er forældet i mit tilfælde. DLL-filen, der indeholder grænsefladen blev genopbygget, men gennemførelsen dll blev forslidt.

    OriginalForfatteren TrustyCoder

  27. 1

    Jeg havde det samme problem. Jeg regnede ud, at min samling, som er fyldt af main-programmet, havde nogle henvisninger med “Kopi Lokale” sæt til true. Disse lokale kopier af referencer var på udkig efter andre referencer i samme mappe, som ikke eksisterer, fordi den “Lokale Kopi” af andre henvisninger blev sat til false. Efter sletning af “uheld” kopieret referencer fejlen var væk, fordi det vigtigste program blev sat til at kigge efter korrekt placering af referencer. Tilsyneladende de lokale kopier af referencer skruet op sekvens af kald, fordi disse lokale kopier, der blev anvendt i stedet for de originale er til stede i main-programmet.

    Tage hjem budskab er, at denne fejl opstår på grund af det manglende link til at indlæse de nødvendige forsamling.

    OriginalForfatteren Almis

  28. 1

    I min sag, var jeg forsøger at bruge TypeBuilder til at skabe en type. TypeBuilder.CreateType kastede denne undtagelse. Jeg har efterhånden indset, at jeg havde brug for at tilføje MethodAttributes.Virtual til de attributter, når du ringer TypeBuilder.DefineMethod for en metode, der hjælper med at implementerer et interface. Dette skyldes, uden at dette flag, metode ikke implementere interfacet, men snarere en ny metode med samme signatur i stedet (selv uden at angive MethodAttributes.NewSlot).

    OriginalForfatteren James

  29. 1

    Som et tillæg: denne kan også opstå, hvis du opdaterer en nuget pakke, der blev brugt til at generere en forfalskninger forsamling. Sige, at du installere V1.0 af en nuget pakke og skabe en forfalskninger forsamling “fakeLibrary.1.0.0.0.Forfalskninger”. Næste, skal du opdatere til den nyeste version af nuget pakke, sige v1.1 der tilføjet en ny metode til en grænseflade. De Forfalskninger bibliotek er stadig på udkig efter v1.0 ud af biblioteket. Du skal blot fjerne den falske forsamling og regenerere det. Hvis der var spørgsmål, dette vil sandsynligvis løse det.

    OriginalForfatteren Chris Peterson

  30. 1

    Modtog jeg denne fejl efter en nylig windows update. Jeg havde en service klasse sæt til at arve fra et interface. Interface indeholdt en signatur, der returneres en ValueTuple, en forholdsvis ny funktion i C#.

    Alt, hvad jeg kan gætte på, er, at windows update er installeret en ny, men selv eksplicit at referere til det, opdatering bindende omdirigeringer, osv…slutresultatet var bare at ændre underskrift af metoden til noget “standard” jeg gætte, du kunne sige.

    OriginalForfatteren Mike_G

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *