Error de enlace de ensamblaje infame

Realmente necesito ayuda sobre esto porque perdí la esperanza de corregir el problema.Error de enlace de ensamblaje infame

Estoy utilizando las bibliotecas de Office Communications Server de 64 bits. Hay 3 dlls que uso en el proyecto, Microsoft.Rtc.Collaboration.dll, Microsoft.Rtc.Internal.Media.dll y SIPEPS.dll. No estoy seguro acerca de Microsoft.Rtc.Collaboration, pero Internal.Media y SIPEPS son ambos x64. En la lista de ensamblado del GAC, Rtc.Colaboración muestra MSIL en arquitectura de procesador y los demás muestran AMD64.

Mi proyecto se compila sin errores con estas referencias, pero en tiempo de ejecución que recibe el error:

No se pudo cargar el archivo o ensamblado 'Microsoft.Rtc.Internal.Media' o uno de sus dependencias. Se intentó cargar un programa con un formato incorrecto.

Intenté compilar el proyecto con la CPU configurada en Cualquier CPU pero nada cambia. Con ambas configuraciones x64 y x86 recibo este error.

Cualquier ayuda es apreciada.

ACTUALIZACIÓN: A continuación se muestra el registro de enlace de montaje.

=== Pre-bind state information === 
LOG: User = CONTOSO\elodie 
LOG: DisplayName = Microsoft.Rtc.Internal.Media 
(Partial) 
WRN: Partial binding information was supplied for an assembly: 
WRN: Assembly Name: Microsoft.Rtc.Internal.Media | Domain ID: 9 
WRN: A partial bind occurs when only part of the assembly display name is provided. 
WRN: This might result in the binder loading an incorrect assembly. 
WRN: It is recommended to provide a fully specified textual identity for the assembly, 
WRN: that consists of the simple name, version, culture, and public key token. 
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue. 
LOG: Appbase = file:///C:/Users/elodie/Documents/Visual Studio 2010/Projects/TFS/proto/Main/Source/WebBot.Web/ 
LOG: Initial PrivatePath = C:\Users\elodie\Documents\Visual Studio 2010\Projects\TFS\proto\Main\Source\WebBot.Web\bin 
Calling assembly : (Unknown). 
=== 
LOG: This bind starts in default load context. 
LOG: Using application configuration file: C:\Users\elodie\Documents\Visual Studio 2010\Projects\TFS\proto\Main\Source\WebBot.Web\web.config 
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config. 
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). 
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/e3d82f59/764fa8c3/Microsoft.Rtc.Internal.Media.DLL. 
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/e3d82f59/764fa8c3/Microsoft.Rtc.Internal.Media/Microsoft.Rtc.Internal.Media.DLL. 
LOG: Attempting download of new URL file:///C:/Users/elodie/Documents/Visual Studio 2010/Projects/TFS/proto/Main/Source/WebBot.Web/bin/Microsoft.Rtc.Internal.Media.DLL. 
ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing terminated.

Fuente

2010-09-19 Élodie Petit

reemplazó a la versión de 64 bits de todos los tres archivos DLL con sus versiones de 32 bits, archivos temporales de ASP.NET limpiadas carpeta y compilada de nuevo. Ahora funciona sin problemas. Gracias por la ayuda.

Fuente

2010-09-19 13:19:19

Tuve el problema con las DLL de Microsoft.Dynamics.GP.eConnect. Resultó que mi entorno dev estaba cargando la DLL de 64 bits del GAC, pero la carpeta lib del proyecto tenía la DLL de 32 bits. La versión de 32 bits se estaba implementando. En VS2010, compruebe de dónde se extrae el archivo DLL en la ventana Salida con Mostrar salida desde establecer en Depurar –

intente configurar copia local en el explorador de soluciones para esos montajes y asegurarse de que se dejó caer en la carpeta del especificado en el registro de unión.

Además, probablemente se construyeron con el V2 CLR. Si lo fueran, que tendrá que activar el modo mixto de unión añadiendo esto a su configuración web/aplicación

<configuration> 
    <startup useLegacyV2RuntimeActivationPolicy="true"> 
     <supportedRuntime version="v4.0"/> 
    </startup> 
</configuration>

Fuente

2010-09-19 12:32:47

Gracias Jaimal. Copy Local se establece en verdadero para los tres. Y useLegacyV2RuntimeActivationPolicy ya está agregado en web.config. ¿Alguna otra opción? –

Tuve este problema con ASP.NET IIS y después de probar todo, habilité 32 bits para mi grupo de aplicaciones y reinicié los grupos de aplicaciones. Entonces funcionó.

En el Administrador de IIS7: Grupos de aplicaciones -> DefaultAppPool -> Configuración avanzada -> Establezca "Habilitar aplicaciones de 32 bits" en verdadero.

También asegúrese de que esté seleccionada la versión .Net correcta.

También configuré el ISAPI 64bit como permitido bajo "Restricciones de ISAPI y CGI", pero no estoy seguro de si eso ayudó.

Fuente

2012-03-29 19:20:28 Aligned

Muchas gracias por esta solución instantánea y sencilla. Me molestó por horas. – Hong

Me pregunto si falta un paso en su acción. Esto es lo que hice (tenga en cuenta la DefaultAppPool adicional) Grupos de aplicaciones -> DefaultAppPool> Configuración avanzada -> establezca "Habilitar aplicaciones de 32 bits" en verdadero.DefaultAppPool es el utilizado para la aplicación con el problema. – Hong

@Hong suena bien. Haré la edición en mi respuesta. – Aligned

Recibí el error al intentar ejecutar la aplicación web desde Visual Studio, pero en mi caso la respuesta fue simple. Cuando leí la excepción con cuidado, pude ver que el ensamblaje en cuestión ya no era utilizado por la aplicación, pero todavía había una copia en la carpeta bin. Después de que se quitó la asamblea ofensiva, el error desapareció.

Fuente

2014-06-30 11:15:24 hillstuk

Para resolver esto, aseguró que todos mis proyectos utilizan la misma versión ejecutando el siguiente comando y control de los resultados:

update-package Newtonsoft.Json -reinstall

Y, por último, me quita lo siguiente de mi web.config:

<dependentAssembly> 
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" /> 
    <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" /> 
    </dependentAssembly>

Fuente

2014-11-12 16:34:21 user1477388

En mi caso recibí este problema porque estaba ejecutando un proyecto web compilado para x64 utilizando IISExpress. Solucioné el problema marcando la siguiente configuración en Visual Studio:

Herramientas | Opciones | Proyectos y soluciones | Proyectos web | Utilice la versión de 64 bits de IIS expreso

Espero que esto ayude a nadie más con este mismo escenario y el tema

Fuente

2014-12-04 23:50:39 KabanaSoft

¿Qué versión de VS usas? No tengo esa opción en VS 2012, pero tengo dos de estos. 1. Use IIS Express para nuevos sitios web y proyectos basados en archivos. 2. Avisar antes de ejecutar aplicaciones web cuando hay errores en la lista de errores. –

Respuesta magnífica y concisa. ¡Gracias! – Mutmatt

Ese fue mi caso también. Saludos por ayuda. – Mariusz

En mi caso me había pasado por mi sitio y se sustituye el nombre del sitio con un nombre nuevo. Inadvertidamente reemplacé el 'PreviousWebSiteName' con el 'NewWebSiteName' en Web.config donde se especificaba el nombre del ensamblado.

<pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true" controlRenderingCompatibilityVersion="4.0" clientIDMode="AutoID"> 
    <controls> 
    <add assembly="NewWebSiteName" namespace="App_Code.Controls" tagPrefix="blog" /> 
    </controls> 
</pages>

El sitio todavía estaba construyendo un conjunto con el antiguo nombre - sólo la intención de cambiar el nombre del sitio donde fue apareciendo en las páginas del sitio; No necesité cambiar nada internamente. Restaurar la entrada Web.config como estaba antes de mi cambio de nombre (lo que dio como resultado una entrada que coincidía con el nombre del ensamblado construido) resolvió el error por mí.

Fuente

2015-04-24 09:40:54 StackOverflowUser

En mi caso tuve algo de mierda en mi web.config, específicamente un httpHandler medio comentado que una vez que lo limpie, mi problema de enlace desapareció.

Fuente

2015-06-24 14:58:36 woodge

Sé que esta es una pregunta antigua, pero aún parece ser un resultado popular al buscar una solución con respecto a un error de enlace parcial en Visual Studio. Había experimentado un problema muy similar al del póster original, pero con EntityFramework.dll y Visual Studio 2015 (proyecto .ASP Web Forms), sin embargo, la solución que encontré se relaciona con un problema amplio. Como no encontré ninguna respuesta similar a mi solución, pensé que sería útil contribuir con lo que encontré, y espero que ayude a alguien.

En mi web.config me hago pasar por un usuario de dominio que es una cuenta de servicio. Esta cuenta de servicio no tenía acceso a mi carpeta Archivos temporales, por lo tanto, al depurar, no podía copiar los dlls y, por lo tanto, no podía cargarlos.

Lo que finalmente nos avisó fue ir y buscar físicamente en la carpeta temporal mencionada en el mensaje de error. En la pregunta original anterior, verá las líneas "Intentando descargar el nuevo archivo URL: /// C: /Windows/Microsoft.NET/Framework/v4.0.30319/Archivos ASP.NET temporales ..." Cuando miré en esa carpeta, mis archivos DLL no estaban allí.

La solución para mí fue esta: ya que estaba usando el entorno de 64 bits y suplantando una cuenta de dominio, agregué el usuario de la cuenta del servicio de dominio a mi C local: /Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary Carpeta de archivos ASP.NET con acceso de escritura (y modificación, para una buena medida).

Conclusión: asegúrese de que la carpeta de archivos Temp otorga acceso de escritura al usuario con el que se está ejecutando su aplicación.

Fuente

2017-02-06 17:24:18 LBW

¡Eres un salvavidas! Gracias por escribir esta explicación detallada. –

Error de enlace de ensamblaje infame

Respuesta

Cuestiones relacionadas