Mensaje de error 'No se puede cargar uno o más de los tipos solicitados. Recupere la propiedad LoaderExceptions para obtener más información '.


347

Desarrollé una aplicación usando Entity Framework , SQL Server 2000, Visual Studio 2008 y Enterprise Library.

Funciona absolutamente bien localmente, pero cuando implemento el proyecto en nuestro entorno de prueba, recibo el siguiente error:

No se puede cargar uno o más de los tipos solicitados. Recupere la propiedad LoaderExceptions para obtener más información.

Seguimiento de pila: en System.Reflection.Module._GetTypesInternal (StackCrawlMark y stackMark)

en System.Reflection.Assembly.GetTypes ()

en System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadTypesFromAssembly (contexto de LoadingContext)

en System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.InternalLoadAssemblyFromCache (contexto LoadingContext)

en System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadAssemblyFromCache (ensamblaje de ensamblaje, carga booleanaReferencedAssemblies, Dictionary 2 knownAssemblies, Dictionary2 y typesInLoading, List`1 y errores)

en System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache (ObjectItemCollection objectItemCollection, ensamblaje de ensamblaje, carga booleanaReferencedAssemblies)

en System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyForType (tipo de tipo)

en System.Data.Metadata.Edm.MetadataWorkspace.LoadAssemblyForType (Tipo de tipo, Asamblea llamando a Ensamblaje)

en System.Data.Objects.ObjectContext.CreateQuery [T] (String queryString, ObjectParameter [] parámetros)

Entity Framework parece tener problemas, ¿alguna idea de cómo solucionarlo?


No hay una bala mágica para resolver este problema, pero esta respuesta lo ayudará a conocer la razón exacta stackoverflow.com/a/8824250/185022
AZ_

Respuestas:


105

Resolví este problema estableciendo el atributo Copiar local de las referencias de mi proyecto en verdadero.


33
Cuando seguimos profundizando en las excepciones internas hasta que vemos la excepción del tipo ReflectionTypeLoadException y tiene una propiedad "LoaderExceptions" que proporciona la información sobre la información DLL que falta o no coincide. Entonces podemos ocuparnos de las acciones apropiadas desde allí.
Sai

19
bueno, eso está bien cuando estás depurando desde Visual Studio. Pero, ¿qué tal si su aplicación web solo arroja este error en el servidor de producción? incluso después de establecer el atributo Copiar local en verdadero.
Yousi

2
Esta es una solución para el problema en un servidor de producción, no en un Visual Studio local. Copiar Local copia la DLL a la que se hace referencia en el momento de la compilación y la DLL se busca primero en la misma carpeta que la aplicación en ejecución. El problema podría persistir si no copiara la DLL que se copió en el momento de la compilación a la carpeta correcta en el servidor de producción.
Mentoliptus

En mi caso, también tuve que agregar una referencia nuget a Microsoft.AspNetCore.Mvc.ViewFeatures
MFedatto

530

Este error no tiene una verdadera respuesta de bala mágica. La clave es tener toda la información para comprender el problema. Lo más probable es que a un ensamblaje cargado dinámicamente le falte un ensamblaje referenciado. Ese ensamblado debe estar en el directorio bin de su aplicación.

Use este código para determinar lo que falta.

using System.IO;
using System.Reflection;
using System.Text;

try
{
    //The code that causes the error goes here.
}
catch (ReflectionTypeLoadException ex)
{
    StringBuilder sb = new StringBuilder();
    foreach (Exception exSub in ex.LoaderExceptions)
    {
        sb.AppendLine(exSub.Message);
        FileNotFoundException exFileNotFound = exSub as FileNotFoundException;
        if (exFileNotFound != null)
        {                
            if(!string.IsNullOrEmpty(exFileNotFound.FusionLog))
            {
                sb.AppendLine("Fusion Log:");
                sb.AppendLine(exFileNotFound.FusionLog);
            }
        }
        sb.AppendLine();
    }
    string errorMessage = sb.ToString();
    //Display or log the error based on your application.
}

44
¡Gracias! Esto debería ser parte de cualquier configuración de registro en sistemas que usan MEF.
Bogi lenvig

44
Si pudiera votar cada vez que vuelvo a esta respuesta, tendría unos 5 votos más ... y contando
sǝɯɐſ

2
Me salvaste la vida. Muchas gracias. NUNCA habría encontrado el problema. Era un viejo dll que ya no estaba usando, acechando profundamente en la estructura de mi proyecto y causando este problema.
Richard

44
solo para descubrir rápidamente lo que falta, usar throw new Exception(errorMessage);, la esperanza ayuda a alguien.
shaijut

2
Sin ningún código adicional, en Visual Studio, vaya a Configuración de excepción y coloque en el cuadro de búsqueda TypeLoadException y luego active las casillas de verificación de dos hits. También es posible que deba deshabilitar las opciones en la sección de depuración "Solo mi código" para que pueda detectar la excepción cuando ocurra en una dependencia que no escribió.
David Burg

56

Una solución que funcionó para mí fue eliminar las carpetas bin / y obj / y reconstruir la solución.


Tuve que reconstruir el proyecto de prueba en sí mismo, no estoy seguro de si te estás refiriendo al proyecto de prueba aquí o al proyecto que estás probando.
Jason Axelson

44
Otro nuevo comentario: haga clic con el botón derecho en el nodo Solución en el "Explorador de soluciones" y haga clic en "Limpiar solución", luego haga clic en "Reconstruir solución". (Si hay una nueva adición en su proyecto fuente - otros proyectos en su solución - parte (s), esto hace que los cambios se reflejen en la carpeta dll de su proyecto y resuelva este problema)
Emre Guldogan

Estaba teniendo este problema. Como sugerí, cerré Visual Studio, la carpeta bin eliminada, volví a abrir el proyecto y lo reconstruí y fue exitoso.
Sagar S.

Esto sucedía cuando cambiaba entre ramas con cambios significativos. Eliminar la papelera funcionó. La limpieza y la reconstrucción NO funcionaban.
JGTaylor

33

Dos posibles soluciones:

  1. Está compilando en modo Release pero está implementando una versión compilada anterior desde su directorio Debug (o viceversa).
  2. No tiene la versión correcta de .NET Framework instalada en su entorno de prueba.

Tuve el mismo problema, el punto 1 fue exacto para mí. Gracias William
Mateo

Tengo el mismo problema ... Revisé ambas sugerencias y sigo recibiendo el mismo error :(
David Kiff

También puede suceder si su DLL referenciada está "bloqueada". Haga clic derecho sobre él y seleccione "desbloquear"
Ben

3
También descubrí que esto sucede si uno de los proyectos de DLL se configuró para construir "x64" en lugar de "Cualquier CPU".
DCastenholz

# 1 puede ocurrir si la configuración de la solución es incorrecta - proyecto no seleccionado para la acumulación, por ejemplo después de quitar y añadir de nuevo el proyecto de solución
surfen

13

Como se ha mencionado anteriormente, generalmente es el caso de que una asamblea no esté allí.

Para saber exactamente qué ensamblaje le falta, adjunte su depurador, establezca un punto de interrupción y cuando vea el objeto de excepción, profundice en la propiedad 'LoaderExceptions'. El conjunto faltante debería estar allí.

¡Espero eso ayude!


1
También podemos seguir explorando las excepciones internas hasta que veamos la excepción del tipo ReflectionTypeLoadException y tenga una propiedad "LoaderExceptions" que proporciona información sobre la información de DLL que falta o no coincide.
Sai

2
En una solución con múltiples proyectos, ¿cómo vemos qué proyecto está causando el problema en LoaderExceptions? Veo que System.Web.Mvc no se puede encontrar, pero no sé cuál de los 20 proyectos en esta solución podría estar teniendo problemas.
mrcoulson

9

La solución fue verificar la excepción LoaderException: en mi caso, faltaban algunos de los archivos DLL.

Ingrese la descripción de la imagen aquí


6

Asegúrese de permitir aplicaciones de 32 bits en IIS si lo implementó en IIS. Puede definir esto en la configuración de su grupo de aplicaciones actual.


6

Encontré este error con una aplicación ASP.NET 4 + SQL Server 2008 R2 + Entity Framework 4.

Funcionaría bien en mi máquina de desarrollo (Windows Vista de 64 bits). Luego, cuando se implementa en el servidor ( Windows Server 2008 R2 SP1), funcionaría hasta que se agote el tiempo de espera de la sesión. Entonces implementamos la aplicación y todo se veía bien y luego lo dejamos por más de 20 minutos de tiempo de espera de sesión y luego se generaría este error.

Para resolverlo, usé este código en el blog de Ken Cox para recuperar la propiedad LoaderExceptions.

Para mi situación, la DLL que faltaba era Microsoft.ReportViewer.ProcessingObjectModel(versión 10). Esta DLL debe instalarse en el GAC de la máquina en la que se ejecuta la aplicación. Puede encontrarlo en el Paquete redistribuible de Microsoft Report Viewer 2010 disponible en el sitio de descarga de Microsoft.


5

Inicialmente probé el visor de registro de Fusion, pero eso no ayudó, así que terminé usando WinDbg con la extensión SOS.

! dumpheap -stat -type Excepción / D

Luego examiné las FileNotFoundExceptions. El mensaje en la excepción contenía el nombre de la DLL que no se estaba cargando.

NB, el / D le da resultados con hipervínculos, así que haga clic en el enlace en el resumen de FileNotFoundException. Eso traerá una lista de las excepciones. Luego haga clic en el enlace de una de las excepciones. Eso hará que dumpobject esas excepciones. Entonces debería poder hacer clic en el enlace de Mensaje en el objeto de excepción, y verá el texto.



4

Mi instancia de este problema terminó siendo una referencia faltante. Se hizo referencia a un ensamblado en app.config pero no tenía una referencia en el proyecto.


3

Si está utilizando Entity Framework , intente copiar las siguientes referencias localmente.

  • System.Data.Entity
  • System.Web.Entity

Cambie la propiedad "Copiar local" a "Verdadero" para estas referencias y publíquela.


3

Otra solución para saber por qué exactamente nada funciona (desde Microsoft connect):

  1. Agregue este código al proyecto:

    foreach (var asm in AppDomain.CurrentDomain.GetAssemblies())
    {
        asm.GetTypes();
    }
  2. Apague los ensambles de serialización de generación.

  3. Construye y ejecuta.

2

Tenía una aplicación web .NET 4.0, ASP.NET MVC 2.0, Entity Framework 4.0 desarrollada en Visual Studio 2010. Tenía el mismo problema, que funcionaba en un servidor Windows Server 2008 R2 pero no en otro servidor Windows Server 2008 R2, a pesar de que las versiones de .NET y ASP.NET MVC eran las mismas, arrojando este mismo error que el suyo.

Fui a seguir la sugerencia de miko, así que instalé Windows SDK v7.1 (x64) en el servidor que falla, para poder ejecutar! Dumpheap.

Bueno, resulta que la instalación de Windows SDK v7.1 (x64) resolvió el problema. Cualquier dependencia que faltara debe haberse incluido en el SDK. Se puede descargar desde Microsoft Windows SDK para Windows 7 y .NET Framework 4 .


2

Agregar mi problema / solución específica a esto, ya que este es el primer resultado para este mensaje de error. En mi caso, el error se recibió cuando implementé una segunda aplicación dentro de la carpeta de mi primera aplicación en IIS . Ambos definieron una cadena de conexión con el mismo nombre, lo que provocó que la aplicación secundaria tuviera un conflicto y, a su vez, generara este mensaje de error no obvio (para mí). Se resolvió agregando:

<clear/>

en el bloque de cadena de conexión de la aplicación web secundaria que evitó que heredara las cadenas de conexión de los archivos web.config más arriba en la jerarquía, por lo que se ve así:

<connectionStrings>
  <clear/>
  <add name="DbContext" connectionString="MySERVER" providerName="System.Data.SqlClient" />
</connectionStrings>

Una pregunta de referencia de desbordamiento de pila que ayudó una vez que determiné lo que estaba sucediendo fue ¿Heredará una aplicación secundaria de su web.config principal? .


2

Esto funcionó para mí. Añádelo en tu web.config

<system.web>
  <trust level="Full" />

Recibí este error:It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.

2

Mi problema se resolvió después de eliminar los archivos de ensamblaje redundantes de la bincarpeta.


2

En caso de que ninguna de las otras respuestas lo ayuden:

Cuando tuve este problema, resultó que mi servicio de Windows se creó para una plataforma x64, y sin querer ejecuté la versión de 32 bits de InstallUtil.exe. Así que asegúrese de estar utilizando la versión correcta de InstallUtil para la plataforma para la que creó.


Tuve un problema similar. Algunas de las DLL que utilizaba mi servicio se compilaron para un procesador de 32 bits, se cambiaron a cualquier procesador y ahora funcionan.
Blake Thingstad

1

Otras sugerencias son todas buenas. En mi caso, el problema era que la caja del desarrollador era una máquina de 64 bits que usaba la ubicación x86 de varias API, incluida Silverlight .

Al cambiar la plataforma de destino para que coincida con el servidor de 32 bits donde se estaba implementando la aplicación web, se eliminó la mayoría de los errores relacionados con la imposibilidad de cargar uno o más de los tipos solicitados.


1

Cambié la propiedad de versión específica de las referencias a falso y eso ayudó.


1

Recibí el mismo mensaje de error al compilar un paquete de Visual Studio (VSPackage). La solución completa se compila y el error se genera cuando CreatePkgDef crea el paquete. Dicho esto, está claro que no puedo atrapar las LoaderExceptions, ya que no es mi aplicación la que la arroja, sino la herramienta de Microsoft. (Aunque soy responsable de la confusión de CreatePkgDef).

En mi caso, la causa raíz fue que mi solución crea un MyDll.dll que ya se ha registrado en el GAC (y son diferentes), por lo que CreatePgkDef se confundió cuál usar y decidió lanzar un error que no es Realmente útil. MyDll.dll en el GAC fue registrado por el instalador del mismo producto (obviamente una versión anterior, con / ligeramente / diferente contenido).

Como arreglarlo

  1. Forma preferida: asegúrese de utilizar la versión correcta de MyDll.dll
    1. Al compilar su proyecto, asegúrese de utilizar un número de versión diferente al que utilizó en la versión anterior ubicada en el GAC. Asegúrese de que los siguientes atributos sean correctos:
      • [ensamblaje: AssemblyVersion ("1.0.0.1")] // Suponiendo que el archivo DLL anterior tenía la versión 1.0.0.0
      • [ensamblaje: AssemblyFileVersion ("1.0.0.1")] // Suponiendo que el archivo DLL anterior tenía la versión 1.0.0.0
    2. Si es necesario, especifique el nombre completo del ensamblado (por ejemplo, "MyDll.dll, Versión = 1.0.0.1, Cultura = neutral, PublicKeyToken = 1234567890abcdef") cuando lo haga referencia en sus otros proyectos.
  2. Si lo anterior falla: puede desinstalar el viejo MyDll.dll de GAC
    1. Cómo desinstalar un ensamblaje del GAC
    2. Desinstale la aplicación que incluye MyDll.dll

Cambiar la versión de la Asamblea fue lo suficientemente bueno para mí. :)

Espero que esto haya sido útil.


1

Tuve el mismo problema (pero en mi local) cuando intentaba agregar la migración de Entity Framework con Package Manager Console.

La forma en que lo resolví fue creando una aplicación de consola donde Main () tenía el siguiente código:

 var dbConfig = new Configuration();
 var dbMigrator = new DbMigrator(dbConfig);
 dbMigrator.Update();

Asegúrese de que la clase de configuración sea la configuración de migración de su proyecto anómalo. Necesitará System.Data.Entity.Migrations para usar DbMigrator.

Establezca un punto de interrupción en su aplicación y ejecútelo. Visual Studio debe detectar la excepción (a menos que tenga ese tipo de excepción configurado para no interrumpir la sesión de depuración), y debería poder encontrar la información que está buscando.

La referencia que faltaba en mi caso era EFProviderWrapperToolkit.


1

Recibí este problema cuando instalé un paquete NuGet en uno de los proyectos y olvidé actualizar el otro proyecto.

Resolví esto simplemente haciendo que ambos proyectos tuvieran el mismo ensamblaje de referencia.


Gracias por el enlace! No tenía idea de qué era NuGet.
jebar8

1

A mí también me pasó. Resolví el problema de la siguiente manera: haga clic con el botón derecho en Solución, Administrar paquetes NuGet para la solución ... Consolidar paquetes y actualizar los paquetes para que estén en la misma versión.


0

Establezca el modo IIS de 32 bits en verdadero, el modo de depuración en verdadero en el archivo de configuración, eliminando el tempdirectorio y restableciendo IIS corrige el problema temporalmente y vuelve después de un tiempo.


0

Verifique que cada uno de sus proyectos esté configurado correctamente en Configuration Manager .

Similar a la razón de William Edmondson para este problema, cambié mi configuración del Administrador de configuración de "Depurar" "Cualquier CPU" a "Depurar" ".NET". El problema era que la versión ".NET" NO estaba configurada para compilar TODOS los proyectos, por lo que algunas de mis DLL estaban desactualizadas (mientras que otras estaban actualizadas). Esto causó numerosos problemas al iniciar la aplicación.

La solución temporal fue hacer la sugerencia de Kenny Eliasson para limpiar los directorios \ bin y \ obj. Sin embargo, tan pronto como hice más cambios en los proyectos que no compilan, todo volvería a fallar.


0

También tuve este problema cuando creé un nuevo complemento de Microsoft Word con Visual Studio 2015. El problema es que tengo 2 versiones de MS Office, 2013 y 2016. Desinstalo MS Office 2013 y luego funciona.


0

Construyo algunos proyectos para SharePoint y, por supuesto, los implementé. Una vez sucedió.

Encontré un ensamblaje antiguo en C: \ Windows \ assembly \ temp \ xxx (con FarManager), lo eliminé después de reiniciar y se crearon todos los proyectos.

Tengo una pregunta para MSBuild, porque en los ensamblajes de proyectos se vinculan como proyectos y cada ensamblaje está marcado como "Copiar local", pero no desde el GAC.


0

Puedo solucionar este problema marcando "Copiar local = verdadero" en todos los archivos DLL referenciados en el proyecto, reconstruir e implementar en un servidor de prueba.


0

Tuve un problema con automap. En la bincarpeta, el archivo automap.4net.dll estaba allí, pero por alguna razón no estaban el automap.xml y automap.dll. Copiarlos al bindirectorio resolvió el problema.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.