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

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

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

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

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.

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!

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

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.

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.

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.

Si está utilizando EntityDataSource en su proyecto, la solución está en Arreglo: 'No se pueden cargar uno o más de los tipos de errores solicitados' . Debe establecer ContextTypeName = "ProjectNameNameSpace.EntityContainerName" '

Esto resolvió mis problemas ...

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.

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.

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.

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 .

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

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

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

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

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

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.

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

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
   2. 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
   3. 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.