TypeLoadException dice "sin implementación", pero está implementada

https://stackoverflow.com/questions/948785

09-09-2019
|

Pregunta

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é. SetShort hay en el DummyItem clase, e incluso he vuelto a compilar una versión con escrituras en el registro de eventos solo para asegurarme de que no sea un problema de implementación/versiones.Lo extraño es que el código de llamada ni siquiera llama al SetShort método.

Solución

NOTA - Si esta respuesta no le ayuda, tómese el tiempo para desplazarse hacia abajo por las otras respuestas que las personas han agregado desde entonces.

Respuesta corta

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

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

Respuesta larga

Si desea intentar reproducir esto, intente lo siguiente:

Cree un proyecto de biblioteca de clases:InterfaceDef, agrega solo una clase y construye:

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

Cree un proyecto de biblioteca de segunda clase:Implementación (con solución separada), copie InterfaceDef.dll en el directorio del proyecto y agréguelo como referencia de archivo, agregue solo una clase y construya:

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

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

Cree un tercer proyecto de consola:ClientCode, copie los dos dlls en el directorio del proyecto, agregue referencias de archivos y agregue el siguiente código al método principal:
```
 IInterface test = new ImplementingClass();
 string s = test.GetString("dummykey");
 Console.WriteLine(s);
 Console.ReadKey();
```
Ejecute el código una vez, la consola dice "hola mundo"
Descomente el código en los dos proyectos dll y reconstruya: copie los dos dll nuevamente en el proyecto ClientCode, reconstruya e intente ejecutar nuevamente.TypeLoadException ocurre al intentar crear una instancia de ImplementingClass.

Otros consejos

Además de lo que la propia respuesta de la autor de la pregunta ya se ha dicho, puede ser vale la pena destacar lo siguiente. La razón por la que esto sucede es porque es posible que una clase tiene un método con la misma firma como un método de interfaz y sin la aplicación de dicho método. El código siguiente 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

Tengo esto cuando mi solicitud no tiene una referencia a otro ensamblado que define una clase que el método en el mensaje de error utilizado. Correr PEVerify dio el error más útiles: "El sistema no puede encontrar el archivo especificado"

Me encontré con el mismo mensaje y esto es lo que hemos encontrado: Utilizamos DLL de terceros en nuestro proyecto. Después de una nueva versión de los estaba fuera cambiamos nuestro proyecto para que apunte al nuevo conjunto de archivos DLL y compilado correctamente.

La excepción fue lanzado cuando traté de instatiate una de las clases de sus interconectados durante el tiempo de ejecución. Nos aseguramos de que todas las otras referencias estaban al día, pero aún ninguna suerte. Necesitábamos un tiempo para detectar (utilizando el Examinador de objetos) que el tipo de retorno del método en el mensaje de error era un tipo completamente nuevo de una nueva asamblea, sin referencias.

Hemos añadido una referencia al ensamblado y desapareció el error.

El mensaje de error era bastante engañoso, pero señaló más o menos a la dirección derecha (método correcto, el mensaje incorrecto).
La excepción ocurrio a pesar de que no usamos el método en cuestión.
Lo que me lleva a la pregunta: Si esta excepción en todo caso, ¿por qué el compilador no recogerlo

He recibido este error en el siguiente escenario.

los dos conjuntos A y B hace referencia a la versión 3.0.0.0 System.Web.Mvc
Una Asamblea referenciado Asamblea B y tenía clases que implementan las interfaces de Asamblea B con métodos que devuelven clases de System.Web.Mvc.
Una Asamblea actualizado a la versión 4.0.0.0 System.Web.Mvc
Asamblea C corrió el código de abajo (FertPin.Classes.Contact estaba contenida en Asamblea A):

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

La corrección para mí estaba mejorando la referencia System.Web.Mvc en Asamblea B a 4.0.0.0. Parece obvio ahora!

Gracias a su creador original!

La otra vez se puede obtener este error es si usted tiene una versión incorrecta de un montaje firmado. No es el síntoma normal para esta causa, pero en este caso fue el escenario en el que lo tengo

un proyecto asp.net contiene conjunto A y el conjunto B, B está fuertemente denomina
conjunto A utiliza Activator.CreateInstance a cargar el ensamblado de C (es decir, no hay ninguna referencia a C que se construye por separado)
C fue construido referencia a una versión más antigua del conjunto B que se encuentra actualmente presente

esperanza de que ayude a alguien - me tomó años para resolver esto

tuve este error también, que fue causado por un exe Cualquier CPU referencia a cualquier conjunto de CPU que a su vez hace referencia una asamblea x86.

La excepción se quejó de un método en una clase en MyApp.Implementations (Cualquier CPU), que deriva MyApp.Interfaces (Cualquier CPU), pero en Fuslogvw.exe I encontró un 'intento de cargar programa con un formato incorrecto' oculto excepción de MyApp.CommonTypes (x86) que se utiliza por ambos.

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

La solución a esto es que eliminar manualmente los archivos del compartimiento en sus proyectos de directorios publicados. Se va a limpiar todas las referencias y forzar el proyecto para utilizar las últimas DLL.

No sugiero el uso de las herramientas de publicar función de borrado porque esto tiende a deshacerse de IIS.

Tengo una solución más esotérica de este mensaje de error. He actualizado mi marco de destino desde .Net 4.0 a 4.6, y mi proyecto de prueba unitaria me estaba dando el "System.TypeLoadException ... no tiene una implementación" error cuando traté de construir. También dio un segundo mensaje de error sobre el mismo método supuestamente no implementado que decía "La tarea 'BuildShadowTask' error inesperado." Ninguno de los consejos que aquí parecía ayudar, así que buscó "BuildShadowTask", y se encontró un puesto en MSDN que me llevó a usar un editor de texto para eliminar estas líneas del archivo csproj del proyecto de prueba unitaria.

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

Después de eso, los dos errores fueron y construyeron el proyecto.

Me encontré con este error en un contexto en el que estaba usando Autofac y una gran cantidad de carga ensamblado dinámico.

Durante la realización de una operación de resolución Autofac, el tiempo de ejecución dejaría de cargar uno de los conjuntos. El mensaje de error se quejó de que Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. Los síntomas se produjeron cuando se ejecuta en un servidor Windows 2012 R2 VM, pero hicieron no producirse en Windows 10 o Windows Server 2016 máquinas virtuales.

ImplementationAssembly referencia System.Collections.Immutable 1.1.37, y contenía implementaciones de una interfaz IMyInterface<T1,T2>, que se definió en una DefinitionAssembly separada. DefinitionAssembly referencia System.Collections.Immutable 1.1.36.

Los métodos de IMyInterface<T1,T2> que fueron "no implementado" tenían parámetros de tipo IImmutableDictionary<TKey, TRow>, que se define en System.Collections.Immutable.

La copia real de System.Collections.Immutable que se encuentra en el directorio del programa fue la versión 1.1.37. En mi Windows Server 2012 R2 VM, el GAC contenía una copia de System.Collections.Immutable 1.1.36. En Windows 10 y Windows Server 2016, el GAC contenía una copia de System.Collections.Immutable 1.1.37. El error de carga sólo se produjo cuando el GAC contenía la versión más antigua de la DLL.

Por lo tanto, la causa raíz del fallo de la carga asamblea fue las referencias a desalineamientos System.Collections.Immutable. La definición de la interfaz y la implementación de aspecto tenían idénticas firmas de método, sino que dependían de las diferentes versiones de System.Collections.Immutable, lo que significa que el tiempo de ejecución no tuvo en cuenta la clase de implementación para que coincida con la definición de interfaz.

La adición de la siguiente redirección de unión a mi fichero de configuración de aplicaciones ha solucionado 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>

Tengo esto con un "diamante" dependencia del proyecto en forma de:

Proyecto A Proyecto B y usa Proyecto D
Proyecto B utiliza Proyecto D

Me recompilado proyecto A pero no el proyecto B, lo que permitió el proyecto B "inyectar" la versión antigua de la DLL Proyecto D

Encontré esto cuando cambié el nombre de un proyecto (y el nombre del ensamblado), del cual 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 el bin carpeta, y cuando mi proyecto web se ejecutó

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 en realidad no se implementaron.Eliminar manualmente el ensamblaje en el proyecto web bin La carpeta resolvió el problema.

También tengo este error cuando antes me había permitido cobertura de código durante las pruebas unitarias para una de las asambleas. Por alguna razón Visual Studio "buffer" de la versión antigua de esta DLL particular, a pesar de que me había puesto al día para poner en práctica una nueva versión de la interfaz. Desactivación de cobertura de código se deshizo del error.

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

Si intenta stub una interfaz definida en un montaje creado usando C ++ administrado que tiene una firma especial obtendrá la excepción cuando se crea el trozo.

Esto es cierto para burla de Rhino y probablemente cualquier marco de burla que utiliza 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 recibe la firma siguiente:

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

Tenga en cuenta que los mapas de tipo long C ++ para System.Int32 (o simplemente int en C #). Es la modopt algo oscura que está causando el problema según lo declarado por el Ayende Rahien la lista de correo de burla de Rhino .

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

Por ejemplo se han incrustado ensamblados de referencia de la aplicación principal como recursos pero sus complementos carga la aplicación de una carpeta específica.

En lugar de utilizar LoadFrom se debe utilizar de carga. 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;
}

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

comprobado todas las referencias en busca de archivos viejos, eventualy descubrí que tenía que hacer algunos bindingRedirects para MVC, en mi proyecto de prueba unitaria.

<?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 caja de herramientas.

Tengo la excepción al abrir un Form en el diseñador; Sin embargo, compilar y ejecutar el código era posible y el código se comportaron como se esperaba. La excepción se produjo en un UserControl local de la implementación de una interfaz de uno de mis bibliotecas de referencia. surgió el error después de esta biblioteca se actualiza.

Esta UserControl fue incluido en la caja de herramientas de Windows Forms. Probablemente Visual Studio mantiene una referencia en una versión obsoleta de la biblioteca o el almacenamiento en caché fue una versión obsoleta en alguna parte.

Así es como me he recuperado de esta situación:

Haga clic en el cuadro de herramientas de Windows Forms y haga clic en Reset Toolbox en el menú contextual. (Esto elimina los elementos personalizados de la Caja de Herramientas).
En mi caso los elementos del cuadro de herramientas fueron restaurados a su estado predeterminado; sin embargo, el puntero de flecha faltaba en la caja de herramientas.
Cierre Visual Studio.
En mi caso Visual Studio terminado con una excepción de violación y abortó.
Reiniciar Visual Studio.
Ahora todo está funcionando sin problemas.

Fwiw, tengo esto cuando había un archivo de configuración que redirigido a una versión no-existente de un ensamblaje de referencia. troncos de fusión para la victoria!

I conseguido este error porque tenía una clase en un conjunto de 'C', que estaba en la versión 4.5 del marco, la implementación de una interfaz en el montaje 'A', que estaba en la versión 4.5.1 del marco y que sirve como la base clase de reunión 'B', que estaba también en la versión 4.5.1 del marco. El sistema arrojó la excepción al intentar cargar el ensamblado de 'B'. Además, había instalado algunos paquetes dirigidos NuGet .NET 4.5.1 en las tres asambleas. Por alguna razón, a pesar de que las referencias NuGet no se muestran en el montaje 'B', fue la construcción de éxito.

Resultó que el verdadero problema era que las asambleas se hacen referencia a diferentes versiones de un paquete Nuget que contenían la interfaz y la interfaz de la firma habían cambiado entre versiones.

En mi caso me había referido previamente un proyecto mylib en una carpeta de hermanos fuera de la repo - vamos a llamar a que v1.0.

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

Más tarde lo hice correctamente y utilizado a través de un submódulo GIT - Deja llamada que v2.0. Una consoleApp proyecto, sin embargo no se ha actualizado correctamente. Todavía hacía referencia al proyecto v1.0 de edad fuera de mi proyecto Git.

confusamente , a pesar de que la *.csproj estaban simplemente equivocadas y apuntando a v1.0, el IDE de Visual Studio mostró el camino que el proyecto v2.0! F12 para inspeccionar la interfaz y la clase fue a la versión v2.0 también.

El conjunto se coloca en la carpeta bin por el compilador fue la versión v1.0, por lo tanto el dolor de cabeza.

El hecho de que el IDE me estaba mintiendo hizo extremadamente difícil darse cuenta del error.

Solución . Suprimido las referencias del proyecto de ConsoleApp y Readded ellos

General Consejo: recompilar todos los conjuntos a partir de cero (cuando sea posible, no puede paquetes NuGet por supuesto) y comprobar sellos de fecha y hora en la carpeta bin\debug. Cualquier viejas asambleas fechadas son su problema.

Me enfrenté a casi el mismo problema. Me estaba rascando la cabeza lo que está causando este error. Me cotejaron, se llevaron a cabo todos los métodos.

En googlear Tengo este vínculo entre otros. Sobre la base de comentario @ Pablo McLink, Estos dos pasos resolvieron el problema.

Reinicio de Visual Studio
Limpio, Construir (Reconstruir)

y se ha ido al error .

Reiniciar VS Plugin

Gracias Paul:)

Espero que esto ayude a alguien que venir a través de este error:)

También encontré con este problema durante la ejecución de mis unittests. La aplicación funcionó muy bien y sin errores. La causa del problema en mi caso era que había desactivado la construcción de los proyectos de prueba. Reenabling el edificio de mis testprojects resuelto los problemas.

vi esto en Visual Studio Pro 2008, cuando dos proyectos conjuntos con el mismo nombre, uno de una clase SDF.dll lib, y uno que hace referencia a la lib con el nombre de ensamblado sdf.exe construidos. Cuando cambié el nombre del conjunto de referencia, la excepción se fue

Esto simplemente significa que el proyecto de implementación no está actualizado en mis casos. El DLL que contiene la interfaz fue reconstruida pero la DLL de aplicación estaba duro.

Esta es mi opinión sobre este error.

Se ha añadido un método extern, pero mi pasta era defectuoso. El DllImportAttribute dieron poner 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);

Asegurar el atributo se incluye en realidad fuente fija el problema.

Tengo esto en un servicio WCF debido a tener un tipo de construcción x86 seleccionado, haciendo que los contenedores de vivir bajo bin \ x86 en lugar de bin. La selección de cualquier CPU causado la DLL de volver a compilar para ir a los lugares correctos (no voy a entrar en detalles en cuanto a cómo esto ocurrió en el primer lugar).

Yo tenía el mismo problema. Me di cuenta de que mi montaje, que se carga por el programa principal, tenía algunas referencias con "Copia local" establecida en true. Estas copias locales de las referencias estaban buscando otras referencias en la misma carpeta, que no existían porque la "copia local" de otras referencias se establece en false. Después de la eliminación de las referencias "accidentalmente" copiados se había ido el error debido a que el programa principal se estableció para buscar ubicaciones correctas de referencias. Al parecer, las copias locales de las referencias fastidiaron con la secuencia de llamar porque estas copias locales fueron utilizados en lugar de los originales presentes en el programa principal.

El mensaje principal es que este error aparece debido al eslabón que falta para cargar la necesidad de ensamblaje.

En mi caso, yo estaba tratando de utilizar TypeBuilder para crear un tipo. TypeBuilder.CreateType lanzó esta excepción. finalmente me di cuenta que tenía que añadir a los atributos MethodAttributes.Virtual al llamar TypeBuilder.DefineMethod por un método que ayuda implementa una interfaz. Esto es porque sin este indicador, el método no implementa la interfaz, sino más bien un nuevo método con la misma firma en su lugar (aun sin especificar MethodAttributes.NewSlot).

Como una adición: esto también puede ocurrir si se actualiza un paquete Nuget que se utilizó para generar un conjunto de falsificaciones. Digamos que instalar V1.0 de un paquete Nuget y crear un montaje falsificaciones "fakeLibrary.1.0.0.0.Fakes". A continuación, se actualiza a la versión más reciente del paquete Nuget, v1.1 decir que añadió un nuevo método a una interfaz. La biblioteca falsificaciones sigue buscando v1.0 de la biblioteca. Basta con retirar el conjunto de falso y regenerarlo. Si ese fuera el problema, esto probablemente va a solucionarlo.

He recibido este error después de una actualización de las ventanas reciente. Tenía un conjunto de clases de servicio a heredar de una interfaz. La interfaz contiene una firma que ha devuelto un ValueTuple, bastante una nueva característica de C #.

Todo lo que puedo adivinar es que la actualización de las ventanas instalado una nueva, pero incluso explícitamente referencia a ella, la actualización de las redirecciones de unión, etc ... El resultado final fue simplemente cambiando la firma del método a algo "estándar" Te supongo podría decir.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow