c# - dynamically - No se pudo cargar el archivo o el ensamblaje ''Microsoft.Practices.Unity''

c# load assembly at runtime

Question

Estoy tratando de actualizar Unity a la versión (2.1.505.2), pero cuando ejecuto la aplicación obtengo la siguiente FileLoadException

No se pudo cargar el archivo o el ensamblaje ''Microsoft.Practices.Unity, Version = 2.0.414.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35'' o una de sus dependencias.

Estamos actualizando de Unity 2.0.414.0 a 2.1.505.2.

• Todas las referencias de proyectos en la solución que se refieren a Unity se refieren a la versión correcta de la DLL.
• No hay un dll Unity referenciado en el Gac. (doble verificación comprobando gacutil -l )

• Eliminé todos los archivos DLL de Unity del archivo. Doble control con PowerShell

  PS C:/> ls -rec -inc Microsoft.Practices.Unity.dll | foreach-object { "{0}`t{1}" -f $_.FullName, [System.Diagnostics.FileVersionInfo]::GetVersionInfo($_).FileVersion }

¿Cómo puedo saber qué / quién todavía se refiere a la Unidad 2.0.414.0?

FusionLogVw no me dice qué DLL está causando el problema.

¡Cualquier ayuda es muy apreciada!

Answer 1

Debe agregar redireccionar al ensamblaje adecuado:

Pero ¡ OBSERVE que la versión 2.1.505.0 debe usarse en la redirección!

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

No puede establecer 2.1.505.2 debido a la siguiente razón:

Unity assembly 2.1.505.2 contiene diferentes versiones para AssemblyFileVersion y AssemblyVersion.

CLR no se preocupa por AssemblyFileVersion, así que solo se usa AssemblyVersion. ¡Y AssemblyFileVersion es usado solo por nuget!

Answer 2

Debido a que su nueva pregunta es sobre cómo encontrar dependencias existentes en un ensamblaje, puede referirse a esta pregunta:

¿Cómo encontrar lo que depende de una versión específica de una dependencia específica?

Lo que se refiere al uso de Fuslogvw.exe

Answer 3

El problema fue otro dll de Microsoft que se refiere a la versión antigua de unity. Descubrí que esto podría ser un accidente, revisando los espacios de nombres de cada dll referenciado, y encontré otro dll que contenía espacios de nombres con "unidad".

Actualizando:

• Microsoft.Practices.EnterpriseLibrary.Common
• Microsoft.Practices.EnterpriseLibrary.Validation

A las últimas versiones publicadas se solucionó el problema.

Espero haber salvado el día a un alma perdida que también se está echando el pelo sobre este tema ... :)

Answer 4

No pude corregirlo utilizando la actualización de EnterpriseLibrary en la solución aceptada. Terminé simplemente anulando la versión de ensamblaje dependiente en app.config , podría hacer algo similar para forzar a cualquier biblioteca que se queje de la versión a usar otra versión.

App.config:

  <dependentAssembly>
    <assemblyIdentity name="Unity.Container" publicKeyToken="489B6ACCFAF20EF0" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-5.8.11.0" newVersion="5.8.11.0"/>
  </dependentAssembly>

Answer 5

Si tiene resharper, puede eliminar la referencia del problema, compilar, ir a la clase donde se usa (hay un error) y obtener resharper para que lo arregle por usted.

Se ahorra el faffing alrededor, pero aprecio que no todos tengan que compartir: D

Answer 6

Verifique su app.config / web.config y, por supuesto, las referencias de su proyecto.

Answer 7

Visión general: este era el código de alguien que tenía que corregir un error en el código, por lo que me proporcionaron un archivo zip de la aplicación.

No tenía idea de lo que estaba sucediendo y por qué siempre, por primera vez, mi código se estaba ejecutando y, después de reiniciar la aplicación (publicar cualquier cambio), comienza a lanzar Excepción. Hay muchas soluciones posibles proporcionadas en los foros y estaba culpando a mi código y base de datos y luego comencé a deshacer cada paso que hice. Pero eso no ayuda.

Solución: Como la solución de problemas múltiples no puede solucionar este problema, pero cuando reinicié, investigué cada n de cada cosa desde la búsqueda para encontrar la razón real que está causando la excepción, encontré que

Para cada nueva compilación, la carpeta bin de mi aplicación borra las dlls

entonces la solución es pegar estos archivos DLL en la carpeta bin de aplicaciones y reconstruir el código (consulte la captura de pantalla)

resultado : todos los sh * t se han ido.