c# - puede - No se pudo cargar archivo o ensamblaje o alguna de sus dependencias.

no se puede cargar mysql data (30)

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

Información adicional: No se pudo cargar el archivo o conjunto ''Microsoft.Practices.Unity, Version = 1.2.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35'' o una de sus dependencias. La definición del manifiesto del ensamblaje localizado no coincide con la referencia del ensamblaje. (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 los archivos .csproj de mis catálogos de soluciones y en todos los lugares donde tengo Unity tengo:

La referencia incluye = "Microsoft.Practices.Unity, versión = 2.0.414.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL"

No puedo encontrar ninguna referencia en cualquier lugar que vaya contra 1.2.0.0 en cualquiera de mis proyectos.

¿Alguna idea de cómo debo ir resolviendo esto?

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

Compruebe si está haciendo referencia a un conjunto que, a su vez, hace referencia a una versión antigua de unity. Por ejemplo, supongamos que tiene un conjunto llamado ServiceLocator.dll que necesita una versión anterior del conjunto de Unity, ahora, cuando hace referencia al ServiceLocator , debe proporcionarle la versión anterior de Unity, y eso constituye el problema.
Puede ser la carpeta de salida donde todos los proyectos construyen sus ensamblajes, 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 en él y vea la llamada Asamblea, y aquí tienes.

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

La solución general es un análisis exhaustivo de todos los ensamblajes a los que se hace referencia para entender qué está mal. Para facilitar esta tarea, hice una herramienta (una extensión de Visual Studio) que permite seleccionar un ensamblado .Net (archivo .ddl o .exe) y obtener un gráfico de todos los ensamblajes referenciados con referencias en conflicto o perdidas.

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

Ejemplo de salida:

Al 99%, el problema No se pudo cargar el archivo o el ensamblado o uno de sus dependencias se debe a las dependencias. Te sugiero que sigas estos pasos:

Descargue Dependency Walker desde http://www.dependencywalker.com/
Inicie Dependency Walker y abra la dll (en mi caso NativeInterfaces.dll )
Puede ver una o más dll con el error en rojo Error al abrir el archivo ...
Significa que esta dll falta en su sistema; en mi caso el nombre dll es MSVCR71.DLL
Puede descargar dll missings de google y copiar en la ruta correcta (en mi caso c:/windows/system32 )
En este punto, debe registrar la nueva dll en la GAC (Global Assembly Cache): abra un terminal DOS y escriba:
cd /Windows/System32 regsvr32 /i msvcr71.dll
Reinicie su aplicación!

Bueno, esto puede sonar muy estúpido, pero aquí es cómo resolví el problema después de probar todas las otras soluciones y pasar una noche en esta cosa estúpida.

Estaba recibiendo el mismo error con algunos archivos DLL que faltan en la carpeta Bin. Intenté eliminar, recuperar todo desde Team Foundation Server pero no funcionó. Obtuve una copia de la carpeta Bin de mi máquina local-matelocal, y la reemplacé. Tampoco funcionó. Por fin, el servidor FTPed manualmente, obtuve la copia de DLL que estaba faltando, y luego comenzó a mostrar que falta el siguiente archivo en la secuencia de la lista de archivos.

Así que instalé el servidor. Conseguí todas las carpetas de la papelera, reemplacé manualmente cada archivo uno por uno. (No Ctrl + Todos y reemplazar .. Lo intenté: no funcionó). Y de alguna manera funcionó ...

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

Debe eliminar el archivo appname.dll de la carpeta de salida. Limpie las carpetas de depuración y lanzamiento. Reconstruir y copiar en la carpeta de salida del archivo dll regenerado.

Dice que tiene muchos proyectos en su solución ... bueno, comience con uno cerca de la parte superior del orden de compilación. Haz que se construya y, una vez que lo descubras, puedes aplicar la misma solución al resto de ellos.

Honestamente, probablemente solo necesites actualizar tu referencia. Parece que usted actualizó su versión y no actualizó las referencias, o es un problema de ruta relativa si mantiene su solución en control de código fuente. Solo verifique sus suposiciones y vuelva a agregar la referencia.

En mi caso, en la carpeta bin había una dll sin referencia llamada 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 esa dll de la carpeta bin.

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

Esto es lo que funcionó para mí:

Quitar la referencia
Renombrar la DLL
Importar la referencia de nuevo

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

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

Gracias Riddhi M. Siguiendo trabajó 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)

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

Luego lo desplegó.

¡Funcionó!

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

Intenta limpiar las carpetas Debug y Release en tu solución. Luego retire y agregue la unidad de nuevo.

Intente verificar si la propiedad "Copiar en 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.

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

Microsoft.Practices.Unity.Interception.dll

Microsoft Enterprise Library (referenciado por .NetTiers) era 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:

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

No estoy seguro de si esto podría ayudar.

Verifique que el nombre del ensamblaje y el espacio de nombres predeterminado en las propiedades de sus ensamblajes coincidan. Esto resolvió mi problema que produjo el mismo error.

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

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

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.

Si recibe este mensaje de error abriendo una aplicación en Windows XP, significa que primero instaló 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 volver a instalar esa aplicación nuevamente, pero primero desinstale desde agregar y quitar

Si esto no funciona, por favor no me maltraten. yo también soy un junior

Siguiendo trabajó 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)

Siguiendo trabajó para mí.

Eliminar archivos temporales C: / Windows / Microsoft.NET / Framework / v4.0.30319 / Archivos temporales ASP.NET
- luego haga clic con el botón 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

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

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

1), 2)

4), 5)

Espero que esto te ayude también.

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, ¡esos se han movido desde el número de versión al final de este bloque de XML!

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

Tuve un problema similar. ** La respuesta de Juntos es correcta ** pero debes tener en cuenta un consejo importante.

Para unity 2.1.505.2 se especifican diferentes AssemblyVersion y AssemblyFileVersion :

AssemblyFileVersion es utilizado por nuget pero a CLR no le importa! ¡CLR va a utilizar solo AssemblyVersion !

Por lo tanto, los redireccionamientos deben aplicarse a una versión especificada en AssemblyVersion: 2.1.505.0

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

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

Verifique el archivo Web.config / App.config en su proyecto. Ver 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í.

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, elija Destino de plataforma: "Cualquier CPU".

Abra el Administrador de IIS

Seleccionar grupos de aplicaciones

a continuación, 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 de falso a verdadero.

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