TypeLoadException dice 'sin implementación', pero está implementado

Tengo un error muy extraño en nuestra máquina de prueba. El error es:

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

Simplemente no puedo entender por qué. SetShortestá allí en la DummyItemclase, e incluso he compilado una versión con escrituras en el registro de eventos solo para asegurarme de que no sea un problema de implementación / control de versiones. Lo extraño es que el código de llamada ni siquiera llama al SetShortmétodo.

NOTA : Si esta respuesta no lo ayuda, tómese el tiempo para desplazarse hacia abajo a través de las otras respuestas que la gente ha agregado desde entonces.

Respuesta corta

Esto puede suceder si agrega un método a una interfaz en un ensamblaje y luego a una clase de implementación en otro ensamblaje, pero reconstruye el ensamblaje de implementación sin hacer referencia a la nueva versión del ensamblaje de interfaz.

En este caso, DummyItem implementa una interfaz desde otro ensamblado. El método SetShort se agregó recientemente a la interfaz y al DummyItem, pero el ensamblado que contiene DummyItem se reconstruyó haciendo referencia a la versión anterior del ensamblaje de la interfaz. Entonces, el método SetShort está efectivamente allí, pero sin la salsa mágica que lo vincula al método equivalente en la interfaz.

Respuesta larga

Si quieres intentar reproducir esto, prueba lo siguiente:

1. Cree un proyecto de biblioteca de clases: InterfaceDef, agregue solo una clase y cree:

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

2. Cree un proyecto de biblioteca de segunda clase: implementación (con una solución separada), copie InterfaceDef.dll en el directorio del proyecto y agregue como referencia de archivo, agregue solo una clase y compile:

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

3. Cree un tercer proyecto de consola: ClientCode, copie los dos dlls en el directorio del proyecto, agregue referencias de archivo y agregue el siguiente código al método Main:

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

4. Ejecute el código una vez, la consola dice "hola mundo"

5. Elimine el comentario del código en los dos proyectos dll y reconstruya: copie los dos dlls nuevamente en el proyecto ClientCode, reconstruya e intente ejecutar nuevamente. TypeLoadException se produce al intentar crear una instancia de ImplementingClass.

Además de lo que ya dijo la respuesta del autor de la pregunta, vale la pena señalar lo siguiente. La razón por la que esto sucede es porque es posible que una clase tenga un método con la misma firma que un método de interfaz sin implementar ese método. El siguiente código ilustra que:

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

Obtuve esto cuando mi aplicación no tenía una referencia a otro ensamblaje que definía una clase que utilizaba el método en el mensaje de error. La ejecución de PEVerify dio un error más útil: "El sistema no puede encontrar el archivo especificado".

Me encontré con el mismo mensaje y esto es lo que hemos encontrado: utilizamos dlls de terceros en nuestro proyecto. Después de la publicación de una nueva versión, cambiamos nuestro proyecto para señalar el nuevo conjunto de dlls y compilamos con éxito.

La excepción se produjo cuando intenté instaurar una de sus clases interconectadas durante el tiempo de ejecución. Nos aseguramos de que todas las demás referencias estuvieran actualizadas, pero aún así no hubo suerte. Necesitamos un tiempo para detectar (usando el Explorador de objetos) que el tipo de retorno del método en el mensaje de error era un tipo completamente nuevo de un nuevo ensamblaje sin referencia.

Agregamos una referencia al ensamblado y el error desapareció.

• El mensaje de error fue bastante engañoso, pero apuntó más o menos a la dirección correcta (método correcto, mensaje incorrecto).
• La excepción ocurrió a pesar de que no usamos el método en cuestión.
• Lo que me lleva a la pregunta: si esta excepción se produce en cualquier caso, ¿por qué el compilador no la recoge?

Recibí este error en el siguiente escenario.

• Ambos ensamblados A y B hicieron referencia a System.Web.Mvc Versión 3.0.0.0
• El conjunto A hacía referencia al conjunto B y tenía clases que implementaban interfaces desde el conjunto B con métodos que devolvían clases desde System.Web.Mvc.
• Ensamblado A actualizado a System.Web.Mvc Versión 4.0.0.0
• La Asamblea C ejecutó el siguiente código (FertPin.Classes.Contact estaba contenido en la Asamblea A):

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

La solución para mí fue actualizar la referencia System.Web.Mvc en la Asamblea B a 4.0.0.0. Parece obvio ahora!

Gracias al póster original!

La otra vez que puede obtener este error es si tiene una versión incorrecta de un ensamblado firmado. No es el síntoma normal de esta causa, pero aquí estaba el escenario donde lo obtuve

• un proyecto asp.net contiene el ensamblaje A y el ensamblaje B, B recibe un fuerte nombre

• el ensamblaje A usa Activator.CreateInstance para cargar el ensamblaje C (es decir, no hay referencia a C, que se construye por separado)

• C se creó haciendo referencia a una versión anterior del ensamblado B que está actualmente presente

Espero que eso ayude a alguien. Me tomó años resolver esto.

También tuve este error, fue causado por un ejecutable Any CPU que hacía referencia a ensamblajes de CPU que a su vez hacían referencia a un ensamblaje x86.

La excepción se quejó de un método en una clase en MyApp.Implementations (Any CPU), que derivaba MyApp.Interfaces (Any CPU), pero en fuslogvw.exe encontré una excepción oculta de "intento de cargar el programa con un formato incorrecto" de MyApp .CommonTypes (x86) que usan ambos.

Sigo volviendo a esto ... Muchas de las respuestas aquí hacen un gran trabajo al explicar cuál es el problema, pero no cómo solucionarlo.

La solución a esto es eliminar manualmente los archivos bin en el directorio publicado de sus proyectos. Limpiará todas las referencias y forzará al proyecto a usar las últimas DLL.

No sugiero usar la función Eliminar de las herramientas de publicación porque esto tiende a descartar IIS.

Tengo otra solución esotérica para este mensaje de error. Actualicé mi framework de destino de .Net 4.0 a 4.6, y mi proyecto de prueba de unidad me estaba dando el error "System.TypeLoadException ... no tiene una implementación" cuando intenté compilar. También dio un segundo mensaje de error sobre el mismo método supuestamente no implementado que decía "La tarea 'BuildShadowTask' falló inesperadamente". Ninguno de los consejos aquí pareció ayudar, así que busqué "BuildShadowTask", y encontré una publicación en MSDN que me llevó a usar un editor de texto para eliminar estas líneas del archivo csproj del proyecto de prueba de unidad.

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

Después de eso, ambos errores desaparecieron y el proyecto se construyó.

Encontré este error en un contexto en el que estaba usando Autofac y mucha carga de ensamblaje dinámico.

Al realizar una operación de resolución de Autofac, el tiempo de ejecución no podría cargar uno de los ensamblajes. El mensaje de error se quejó de eso Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. Los síntomas ocurrieron cuando se ejecutaba en una VM de Windows Server 2012 R2, pero no ocurría en las de Windows 10 o Windows Server 2016.

ImplementationAssemblyreferenciado System.Collections.Immutable1.1.37, y contenía implementaciones de una IMyInterface<T1,T2>interfaz, que se definió en un separado DefinitionAssembly. DefinitionAssemblyreferenciadoSystem.Collections.Immutable 1.1.36.

Los métodos a partir de los IMyInterface<T1,T2>cuales "no se implementaron" tenían parámetros de tipo IImmutableDictionary<TKey, TRow>, que se definen enSystem.Collections.Immutable .

La copia real de System.Collections.Immutableencontrado en el directorio del programa fue la versión 1.1.37. En mi VM Windows Server 2012 R2, el GAC contenía una copia de System.Collections.Immutable1.1.36. En Windows 10 y Windows Server 2016, el GAC contenía una copia de System.Collections.Immutable1.1.37. El error de carga solo se produjo cuando el GAC contenía la versión anterior de la DLL.

Entonces, la causa raíz de la falla de carga del ensamblaje fueron las referencias que no coinciden System.Collections.Immutable. La definición y la implementación de la interfaz tenían firmas de métodos de aspecto idéntico, pero en realidad dependían de diferentes versiones System.Collections.Immutable, lo que significaba que el tiempo de ejecución no consideraba que la clase de implementación coincidiera con la definición de la interfaz.

Agregar el siguiente enlace de redireccionamiento al archivo de configuración de mi aplicación solucionó el 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>

Obtuve esto con una dependencia de proyecto en forma de "diamante":

• El Proyecto A usa el Proyecto B y el Proyecto D
• El proyecto B usa el proyecto D

Recopilé el proyecto A pero no el Proyecto B, lo que permitió que el Proyecto B "inyectara" la versión anterior del Proyecto Dll

Encontré esto cuando cambié el nombre de un proyecto (y el nombre del ensamblado), del que dependía un proyecto ASP.NET. Los tipos en el proyecto web implementaron interfaces en el ensamblado dependiente. A pesar de ejecutar Clean Solution desde el menú Build, el ensamblaje con el nombre anterior permaneció en la bincarpeta y cuando se ejecutó mi proyecto web

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

se lanzó la excepción anterior, quejándose de que los métodos de interfaz en los tipos web de implementación no se implementaron realmente. La eliminación manual del ensamblaje en la bincarpeta del proyecto web resolvió el problema.

También recibí este error cuando previamente había habilitado la Cobertura de código durante las pruebas unitarias para uno de los ensamblajes. Por alguna razón, Visual Studio "almacenó en búfer" la versión anterior de esta DLL en particular, aunque la actualicé para implementar una nueva versión de la interfaz. La desactivación de la cobertura del código eliminó el error.

Este error también puede ser causado si un ensamblado se carga usando Assembly.LoadFrom (String) y hace referencia a un ensamblaje que ya se cargó usando Assembly.Load (Byte []).

Por ejemplo, ha incrustado los ensamblados referenciados de la aplicación principal como recursos, pero su aplicación carga complementos desde una carpeta específica.

En lugar de usar LoadFrom, debe usar Load. El siguiente código hará el trabajo:

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

Otra explicación para este tipo de problema que involucra C ++ administrado.

Si intenta crear una interfaz definida en un ensamblaje creado usando C ++ administrado que tiene una firma especial, obtendrá la excepción cuando se cree el código auxiliar.

Esto es cierto para Rhino Mocks y probablemente para cualquier marco de imitación que use System.Reflection.Emit.

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

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

La definición de interfaz obtiene la siguiente firma:

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

Tenga en cuenta que el tipo de C ++ se longasigna a System.Int32(o simplemente inten C #). Es algo oscuro lo modoptque está causando el problema según lo declarado por Ayende Rahien en la lista de correo de Rhino Mocks .

Acabo de actualizar una solución de MVC3 a MVC5, y comencé a recibir la misma excepción del proyecto de prueba de mi Unidad.

Revisé todas las referencias en busca de archivos antiguos, eventualmente descubrí que necesitaba hacer algunos enlaces vinculantes para Mvc, en mi proyecto de prueba de unidad.

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

En mi caso, ayudó a restablecer el WinForms Toolbox.

Obtuve la excepción al abrir un Formen el diseñador; sin embargo, fue posible compilar y ejecutar el código y el código se comportó como se esperaba. La excepción ocurrió en un local que UserControlimplementó una interfaz desde una de mis bibliotecas referenciadas. El error surgió después de actualizar esta biblioteca.

Esto UserControlfiguraba en el cuadro de herramientas de WinForms. Probablemente Visual Studio mantuvo una referencia en una versión desactualizada de la biblioteca o estaba almacenando una versión desactualizada en alguna parte.

Así es como me recuperé de esta situación:

1. Haga clic derecho en WinForms Toolbox y haga clic en Reset Toolboxen el menú contextual. (Esto elimina elementos personalizados de la Caja de herramientas).
   En mi caso, los elementos de Toolbox se restauraron a su estado predeterminado; sin embargo, faltaba la flecha del puntero en la caja de herramientas.
2. Cierra Visual Studio.
   En mi caso, Visual Studio finalizó con una excepción de violación y se anuló.
3. Reinicie Visual Studio.
   Ahora todo funciona sin problemas.

FWIW, obtuve esto cuando había un archivo de configuración que redirige a una versión inexistente de un ensamblado referenciado. ¡Fusion registra la victoria!

Recibí este error porque tenía una clase en un ensamblado 'C' que estaba en la versión 4.5 del marco, implementando una interfaz en el ensamblaje 'A' que estaba en la versión 4.5.1 del marco y que servía como la clase base para el ensamblaje 'B' que también estaba en la versión 4.5.1 del framework. El sistema arrojó la excepción al intentar cargar el ensamblado 'B'. Además, instalé algunos paquetes nuget dirigidos a .net 4.5.1 en los tres ensamblajes. Por alguna razón, aunque las referencias nuget no se mostraban en el ensamblado 'B', se estaba construyendo con éxito.

Resultó que el problema real era que los ensamblajes hacían referencia a diferentes versiones de un paquete nuget que contenía la interfaz y la firma de la interfaz había cambiado entre versiones.

En mi caso, anteriormente había hecho referencia a un mylibproyecto en una carpeta hermana fuera del repositorio, llamemos a eso v1.0.

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

Más tarde lo hice correctamente y lo usé a través de un submódulo git: llamemos a eso v2.0. consoleAppSin embargo, un proyecto no se actualizó correctamente. Todavía hacía referencia al antiguo v1.0proyecto fuera de mi proyecto git.

Confusamente , a pesar de que *.csprojestaba claramente equivocado y apuntando v1.0, ¡el IDE de Visual Studio mostró el camino como el v2.0proyecto! F12 para inspeccionar la interfaz y la clase también fue a la v2.0versión.

El ensamblaje colocado en la carpeta bin por el compilador era la v1.0versión, de ahí el dolor de cabeza.

El hecho de que el IDE me estuviera mintiendo hizo que fuera más difícil darse cuenta del error.

Solución : se ConsoleAppeliminaron referencias de proyectos y se leyeron.

Consejo general: recompile todos los ensamblajes desde cero (cuando sea posible, por supuesto, no se pueden obtener paquetes nuget) y verifique los sellos de fecha y hora en la bin\debugcarpeta. Cualquier ensamblaje antiguo con fecha es su problema.

Me enfrenté a casi el mismo problema. Me estaba rascando la cabeza lo que está causando este error. Hice una verificación cruzada, todos los métodos fueron implementados.

En Google obtuve este enlace entre otros. Según el comentario de @Paul McLink, estos dos pasos resolvieron el problema.

1. Reiniciar Visual Studio
2. Limpiar, construir (reconstruir)

y el error desapareció .

Reiniciar VS Plugin

Gracias Paul :)

Espero que esto ayude a alguien que se encuentre con este error :)

También me encontré con este problema mientras ejecutaba mis pruebas unitarias. La aplicación funcionó bien y sin errores. La causa del problema en mi caso fue que había apagado la construcción de los proyectos de prueba. Volver a habilitar la construcción de mis proyectos de prueba resolvió los problemas.

Vi esto en Visual Studio Pro 2008 cuando dos proyectos construyeron ensamblados con el mismo nombre, uno de clase lib SDF.dll y otro que hacía referencia a lib con el nombre de ensamblado sdf.exe. Cuando cambié el nombre del ensamblaje de referencia, la excepción desapareció

Esto simplemente significa que el proyecto de implementación está desactualizado en mis casos. La DLL que contiene la interfaz fue reconstruida pero la dll de implementación estaba obsoleta.

Aquí está mi opinión sobre este error.

Agregué un externmétodo, pero mi pegado estaba defectuoso. Lo DllImportAttributepusieron en una línea comentada.

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

Asegurarse de que el atributo se incluyera en la fuente solucionó el problema.

Obtuve esto en un servicio WCF debido a que tengo un tipo de compilación x86 seleccionado, lo que hace que los contenedores vivan debajo de bin \ x86 en lugar de bin. Al seleccionar Cualquier CPU, las DLL recompiladas iban a las ubicaciones correctas (no entraré en detalles sobre cómo sucedió esto en primer lugar).

Yo tuve el mismo problema. Descubrí que mi ensamblado, que es cargado por el programa principal, tenía algunas referencias con "Copiar local" establecido en verdadero. Estas copias locales de referencias buscaban otras referencias en la misma carpeta, que no existían porque la "Copia local" de otras referencias estaba configurada como falsa. Después de la eliminación de las referencias copiadas "accidentalmente", el error desapareció porque el programa principal estaba configurado para buscar las ubicaciones correctas de las referencias. Aparentemente, las copias locales de las referencias arruinaron la secuencia de llamadas porque se usaron estas copias locales en lugar de las originales presentes en el programa principal.

El mensaje para llevar a casa es que este error aparece debido al enlace faltante para cargar el ensamblaje requerido.

En mi caso, intentaba usar TypeBuilderpara crear un tipo. TypeBuilder.CreateTypeLanzó esta excepción. Finalmente me di cuenta de que necesitaba agregar MethodAttributes.Virtuala los atributos al llamar TypeBuilder.DefineMethoda un método que ayuda a implementar una interfaz. Esto se debe a que sin este indicador, el método no implementa la interfaz, sino un nuevo método con la misma firma (incluso sin especificar MethodAttributes.NewSlot).

Como un apéndice: esto también puede ocurrir si actualiza un paquete nuget que se utilizó para generar un ensamblaje falso. Supongamos que instala V1.0 de un paquete nuget y crea un ensamblaje falso "fakeLibrary.1.0.0.0.Fakes". A continuación, actualiza a la versión más reciente del paquete nuget, digamos v1.1 que agregó un nuevo método a una interfaz. La biblioteca Fakes todavía está buscando v1.0 de la biblioteca. Simplemente retire el ensamblaje falso y regenere. Si ese era el problema, esto probablemente lo solucionará.

Recibí este error después de una actualización reciente de Windows. Tenía una clase de servicio establecida para heredar de una interfaz. La interfaz contenía una firma que devolvía un ValueTuple, una característica bastante nueva en C #.

Todo lo que puedo adivinar es que la actualización de Windows instaló una nueva, pero incluso haciendo referencia explícita a ella, actualizando redireccionamientos vinculantes, etc. El resultado final fue simplemente cambiar la firma del método a algo "estándar", supongo que se podría decir.