No se pudo cargar el archivo o ensamblado o una de sus dependencias

Tengo otro de estos problemas "No se pudo cargar el archivo o el ensamblado o una de sus dependencias".

Información adicional: No se pudo cargar el archivo o ensamblado 'Microsoft.Practices.Unity, Version = 1.2.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35' o una de sus dependencias. La definición de manifiesto del ensamblado ubicado no coincide con la referencia del ensamblado. (Excepción de HRESULT: 0x80131040)

No tengo idea de qué está causando esto o cómo podría depurarlo para encontrar la causa.

He realizado una búsqueda en mis catálogos de soluciones .csproj, y en todos los lugares donde tengo Unity tengo:

Referencia Incluir = "Microsoft.Practices.Unity, Version = 2.0.414.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL"

No puedo encontrar ninguna referencia en ningún lugar que vaya en contra de 1.2.0.0 en ninguno de mis proyectos.

¿Alguna idea de cómo debo resolver esto?

También agradecería consejos sobre cómo depurar problemas como este en general.

1. Compruebe si está haciendo referencia a un ensamblado que a su vez hace referencia a una versión anterior de la unidad. Por ejemplo, supongamos que tiene un ensamblado llamado ServiceLocator.dllque necesita una versión anterior del ensamblado de Unity, ahora cuando hace referencia al ServiceLocatordebe proporcionarle la versión anterior de Unity, y eso causa el problema.

2. Puede ser la carpeta de salida donde todos los proyectos compilan sus ensamblados, tiene una versión antigua de la unidad.

Puede usar FusLogVw para averiguar quién está cargando los ensamblajes antiguos, simplemente defina una ruta para el registro y ejecute su solución, luego verifique (en FusLogvw) la primera línea donde se carga el ensamblaje de Unity, haga doble clic y vea la llamada asamblea, y aquí tienes.

Abra el administrador de IIS

Seleccionar grupos de aplicaciones

luego seleccione el grupo que está utilizando

ir a la configuración avanzada (en el lado derecho)

Cambie el indicador de Habilitar aplicación de 32 bits falso a verdadero.

Para mí, ninguna de las otras soluciones funcionó (incluida la estrategia de limpieza / reconstrucción). Encontré otra solución alternativa que es cerrar y volver a abrir Visual Studio .

Supongo que esto obliga a Visual Studio a volver a cargar la solución y todos los proyectos, volviendo a verificar las dependencias en el proceso.

Intente limpiar las carpetas Debug and Release en su solución. Luego quite y agregue la unidad nuevamente.

¡Al 99%, el problema No se pudo cargar el archivo o el ensamblaje o una de sus dependencias es causada por dependencias! Te sugiero que sigas estos pasos:

1. Descargue Dependency Walker de http://www.dependencywalker.com/

2. Inicie Dependency Walker y abra el dll (en mi caso NativeInterfaces.dll)

3. Puede ver una o más dll con el error en rojo Error al abrir el archivo ...

   

4. Significa que este dll falta en su sistema; en mi caso el nombre dll esMSVCR71.DLL

5. Puede descargar dll faltantes de google y copiar en la ruta correcta (en mi caso c:\windows\system32)

6. En este punto, debe registrar la nueva dll en el GAC (Global Assembly Cache): abra una terminal DOS y escriba:

   cd \Windows\System32
   regsvr32 /i msvcr71.dll

7. ¡Reinicia tu aplicación!

Microsoft Enterprise Library (referenciado por .NetTiers) fue nuestro problema, que a su vez hacía referencia a una versión anterior de Unity. Para resolver el problema, utilizamos la siguiente redirección de enlace en web.config:

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity.Configuration" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

Alternativamente, es posible que desee actualizar la Biblioteca Enterprise a la última versión.

Lo siguiente funcionó para mí.

• Eliminar archivos temporales C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Archivos temporales ASP.NET
• Cerrar VSTS y abrir de nuevo
• Eliminar y agregar las mismas DLL (Nota: agrega las mismas versiones coincidentes)

Verifique el archivo Web.config / App.config en su proyecto. Vea si los números de versión son correctos.

<bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />

Esto funcionó para mí.

A pesar de que la pregunta original se publicó hace cinco años, el problema aún persiste y es bastante molesto.

La solución general es un análisis exhaustivo de todos los ensambles a los que se hace referencia para comprender qué está sucediendo mal. Para facilitar esta tarea me hizo una herramienta (una extensión de Visual Studio) que permite la selección de un ensamblaje .NET (una .dllo .exearchivo) para obtener una gráfica de todos los ensamblados de referencia además de destacar en conflicto o que falten referencias.

La herramienta está disponible en Visual Studio Gallery: https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734

Ejemplo de salida:

En el explorador de soluciones, haga clic con el botón derecho en el proyecto (no en la solución), en la pestaña de compilación, seleccione Objetivo de plataforma: "Cualquier CPU".

La respuesta de Juntos es correcta, pero también debe considerar:

Para la unidad v2.1.505.2 se especifican diferentes atributos AssemblyVersion y AssemblyFileVersion :

AssemblyFileVersion es utilizado por NuGet, pero a CLR no le importa. ¡CLR usará solo AssemblyVersion !

Por lo tanto, sus redireccionamientos deben aplicarse a una versión que se especifique en el atributo AssemblyVersion . Entonces 2.1.505.0 debería ser usado

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>

Consulte también: ¿Cuáles son las diferencias entre AssemblyVersion, AssemblyFileVersion y AssemblyInformationalVersion?

También recibí este terrible error y encontré una solución para esto ...

1. Haga clic derecho en el nombre de la solución
2. Haga clic en Solución limpia
3. Reiniciar Visual Studio
4. Ir a proyecto Propiedades >> Construir
5. Cambiar configuración para liberar
6. Iniciar depuración (F5)

1), 2)

4), 5)

Espero que esto te ayude también.

• Ir a: Solución -> Paquete
• Haga clic en la pestaña Avanzado (Buscar debajo de la página)
• Agregue su dll a ensamblajes adicionales (de esta manera podemos agregar dlls externos en sharepoint).

No estoy seguro si esto podría ayudar.

Compruebe que el nombre del ensamblado y el espacio de nombres predeterminado en las propiedades de sus conjuntos coinciden. Esto resolvió mi problema que produjo el mismo error.

En mi caso, en la carpeta bin había un dll sin referencia llamado Unity.MVC3, intenté buscar cualquier referencia a esto en Visual Studio sin éxito, por lo que mi solución fue tan fácil como eliminar ese dll de la carpeta bin.

Gracias Riddhi M. Siguiendo trabajó para mí.

Eliminar archivos temporales C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Archivos temporales de ASP.NET Cerrar VSTS y abrir de nuevo Eliminar y agregar las mismas DLL (Nota: agrega las mismas versiones coincidentes)

Dices que tienes muchos proyectos en tu solución ... bueno, comienza con uno cerca de la parte superior del orden de compilación. Obtenga ese para construir y una vez que lo descubra, puede aplicar la misma solución al resto de ellos.

Honestamente, probablemente solo necesite actualizar su referencia. Parece que actualizaste tu versión y no actualizaste las referencias, o es un problema relativo de ruta si mantienes tu solución en control de código fuente. Simplemente verifique sus suposiciones y vuelva a agregar la referencia.

Lo siguiente funcionó para mí.

• Eliminar archivos temporales C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Archivos temporales ASP.NET
  • luego haga clic derecho en Archivos temporales de Asp.net> propiedades> seguridad y otorgue acceso de control total a IIS y a todos los usuarios que ejecutan mi proyecto

Este problema me ocurrió cuando una de mis bibliotecas dependientes estaba compilando una DLL con "Cualquier CPU" cuando la biblioteca principal esperaba una compilación de "x64".

Tuve el mismo problema que lo resolví a través de las siguientes instrucciones:

1. abrir el menú de herramientas y seleccionar la opción
2. en opciones, ventana vaya a Proyectos y soluciones / Proyectos web
3. cheque use the 64bit version of IIS ...

Tiene que eliminar su archivo appname.dll de su carpeta de salida. Limpieza de depuración y liberación de carpetas. Reconstruir y copiar en el archivo dll regenerado de la carpeta de salida.

I "Establecer como proyecto de inicio" la biblioteca / proyecto descargado / no encontrado.

Luego lo desplegó.

¡Funcionó!

Creo que no pudo encontrar el .dll porque al principio no estaba en el ensamblado.

Otra posible causa: asegúrese de no haber dado accidentalmente a ambos proyectos el mismo nombre de ensamblaje en las propiedades del proyecto.

Mi solución para .NET 4.0, usando Enterprise Library 5, fue agregar una referencia a:

Microsoft.Practices.Unity.Interception.dll

Esté atento a las referencias en conflicto. Incluso después de una limpieza y reconstrucción, las referencias en conflicto seguirán causando un problema. Mi problema fue entre AForge y Accord. Eliminé ambas referencias y volví a agregar las referencias, volviendo a elegir la referencia particular (particular para mi caso, solo Accord).

Para mí, la reconstrucción del juego de la unidad sin Unity C # Proects Checkmark funcionó.

En mi caso, ninguna de las respuestas propuestas funcionó.

Esto es lo que funcionó para mí:

1. Eliminar la referencia
2. Cambiar el nombre de la DLL
3. Importar la referencia nuevamente

El segundo paso fue aparentemente importante ya que no funcionó sin él.

Intente comprobar si la propiedad "Copiar a local" para la referencia está establecida en verdadero y la versión específica está establecida en verdadero. Esto es relevante para aplicaciones en Visual Studio.

Tuve esto hoy, y en mi caso el problema fue muy extraño:

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0" newVersion="3.1.0.0" />
  </dependentAssembly>0.

Tenga en cuenta los caracteres extraviados al final del XML: de alguna manera, se han movido del número de versión al final de este bloque de XML.

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0.0" newVersion="3.1.0.0" />
  </dependentAssembly>

Cambiado a lo anterior y listo! Todo funcionó de nuevo.

Si recibe este mensaje de error al abrir una aplicación en Windows XP, significa que primero ha instalado esa aplicación debido a que no funciona sin Net Framework 4 y Service Pack 3. instaló ambos y nuevamente está recibiendo este error, por lo que debe reinstalar esa aplicación nuevamente pero primero desinstalarla de Agregar y quitar

Si esto no funciona, por favor no abuses de mí. yo también soy un junior