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

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

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

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

Stack trace: 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 de LoadingContext)

en System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadAssemblyFromCache (Assembly assembly, Boolean loadReferencedAssemblies, Dictionary 2 knownAssemblies, Dictionary 2 & typesInLoading, List`1 & errors)

en System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache (ObjectItemCollection objectItemCollection, Assembly assembly, Boolean loadReferencedAssemblies)

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

en System.Data.Metadata.Edm.MetadataWorkspace.LoadAssemblyForType (Tipo de tipo, Assembly callingAssembly)

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

Entity Framework parece tener problemas, ¿alguna pista sobre cómo solucionarlo?

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

Este error no tiene verdadera respuesta mágica. La clave es tener toda la información para comprender el problema. Lo más probable es que un ensamblaje cargado dinámicamente carezca de un ensamblaje al que se hace referencia. Ese ensamblaje 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. } 

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

Dos posibles soluciones:

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

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

Para saber exactamente qué ensamblaje te falta, conecta tu depurador, establece un punto de interrupción y cuando veas el objeto de excepción, ve a la propiedad ‘LoaderExceptions’. El ensamblaje que falta debe estar allí.

¡Espero eso ayude!

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 implemente en el servidor ( Windows Server 2008 R2 SP1), funcionará hasta que se agote el tiempo de espera de la sesión. Así que desplegaríamos la aplicación y todo se veía bien y luego lo dejaríamos por más de 20 minutos de tiempo de espera de sesión y luego se lanzaría este error.

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

Para mi situación, el 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.

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

Si está utilizando EntityDataSource en su proyecto, la solución está en Fix: Errores de “No se pueden cargar uno o más de los tipos solicitados” . Debe establecer ContextTypeName = “ProjectNameNameSpace.EntityContainerName” ‘

Esto resolvió mis problemas …

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

! dumpheap -stat -type Exception / D

Luego examiné 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 hipervinculados, así que haga clic en el enlace en el resumen de FileNotFoundException. Eso mostrará una lista de las excepciones. Luego haga clic en el enlace para una de las excepciones. ¡Eso! Dumpobject esas excepciones. Entonces debería simplemente hacer clic en el enlace para Mensaje en el objeto de excepción, y verá el texto.

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

  1. Agregue este código al proyecto:

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

  3. Construye y ejecuta.

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

Ingrese la descripción de la imagen aquí

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

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 desplegué una segunda aplicación dentro de la carpeta de mi primera aplicación en IIS . Ambos definían la cadena de conexión con el mismo nombre, lo que provocaba que la aplicación hija tuviera un conflicto y, a su vez, generaba este (para mí) mensaje de error no obvio. Fue resuelto agregando:

  

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

     

Una pregunta de referencia sobre el desbordamiento de la stack que me ayudó una vez que determiné qué estaba sucediendo fue ¿Una aplicación hija heredará de su sitio web principal web.config? .

Esto funcionó para mí. Añádalo a su web.config

   

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

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

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

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íquelas.

Otras sugerencias son todas buenas En mi caso, el problema era que el cuadro de 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 implementó 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.

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

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

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 defectuoso. Necesitará System.Data.Entity.Migrations para usar DbMigrator.

Establezca un punto de interrupción en su aplicación y ejecútelo. La excepción debe ser detectada por Visual Studio (a menos que tenga establecido ese tipo de excepción 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.

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

Lo resolví haciendo que ambos proyectos tuvieran el mismo conjunto de referencia.

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

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

Cuando tuve este problema, resultó que mi servicio de Windows se había creado para una plataforma x64 y estaba ejecutando inadvertidamente la versión de 32 bits de InstallUtil.exe. Por lo tanto, asegúrese de estar utilizando la versión correcta de InstallUtil para la plataforma que creó.

Establezca el modo IIS de 32 bits en true, el modo de depuración en true en el archivo de configuración, elimine el directorio temp y restablezca IIS soluciona el problema temporalmente y vuelve después de un tiempo.

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

Similar al motivo de William Edmondson para este problema, cambié mi configuración de Configuration Manager de “Depurar” “Cualquier CPU” a “Depurar” “.NET”. El problema era que la versión “.NET” NO estaba configurada para comstackr 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 de limpiar los directorios \ bin y \ obj. Sin embargo, tan pronto como realice más cambios en los proyectos que no comstackn, todo volverá a fallar.

También tengo este problema cuando creo 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.

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 del reinicio y todos los proyectos se crearon.

Tengo una pregunta para MSBuild, porque en ensambles de proyectos vinculados como proyectos y cada ensamblaje está marcado como “Copiar local”, pero no desde el GAC.

Tuve el mismo mensaje de error informado al comstackr un paquete de Visual Studio (VSPackage). La solución completa se comstack y el error se produce cuando CreatePkgDef crea el paquete. Habiendo dicho eso, está claro que no puedo ver LoaderExceptions ya que no es mi aplicación la que lo lanza, sino la propia herramienta de Microsoft. (Aunque soy responsable de la confusión de CreatePkgDef).

En mi caso, la causa principal fue que mi solución crea un MyDll.dll que ya se ha registrado en el GAC (y son diferentes), por lo que CreatePgkDef confundió cuál utilizar y decidió lanzar un error que no es Muy ú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 comstackr su proyecto, asegúrese de utilizar un número de versión diferente del que utilizó en la versión anterior ubicada en el GAC. Asegúrese de que los siguientes atributos sean correctos:
      • [assembly: AssemblyVersion (“1.0.0.1”)] // Suponiendo que el archivo DLL anterior tenía la versión 1.0.0.0
      • [assembly: AssemblyFileVersion (“1.0.0.1”)] // Suponiendo que el archivo DLL anterior fue versionado 1.0.0.0
    2. Si es necesario, especifique el nombre completo del ensamblado (por ejemplo, “MyDll.dll, Version = 1.0.0.1, Culture = neutral, PublicKeyToken = 1234567890abcdef”) cuando lo referencia en sus otros proyectos.
  2. Si lo anterior falló: Puede desinstalar el antiguo MyDll.dll del GAC
    1. Cómo desinstalar una Asamblea del GAC
    2. Desinstale la aplicación que incluye MyDll.dll

Cambiar la AssemblyVersion fue lo suficientemente bueno para mí. 🙂

Espero que esto haya sido útil.

Puedo solucionar este problema marcando “Copiar local = Verdadero” en todos los archivos DLL de referencia en el proyecto, reconstruyendo e implementando en un servidor de prueba.

Tuve un problema con automap. En la carpeta bin , el archivo automap.4net.dll estaba allí, pero por alguna razón el automap.xml y el automap.dll no. Copiarlos en el directorio bin resolvió el problema.

Estaba actualizando un sitio web a través de FTP. Supongo que el sitio web estaba en uso y al intentar actualizar la carpeta bin, algunos de los archivos DLL deben haberse bloqueado y no se actualizaron.

Allí vi la página de error 500 y al configurar el modo CustomErrors para que fuera Off, vi el mensaje de error mencionado por el OP.

El problema fue que no vi las fallas enumeradas en el progtwig FTP. Reintenté esos fallos fallidos y subieron. El último archivo DLL actualizado. Entonces el sitio funcionó.