visual-studio-2010 - tag - visual studio code path intellisense
Error de enlace de ensamblaje infame (9)
Realmente necesito ayuda con esto porque perdí la esperanza de corregir el problema.
Estoy usando 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 compila sin errores con estas referencias, pero en tiempo de ejecución recibo el error:
No se pudo cargar el archivo o ensamblado ''Microsoft.Rtc.Internal.Media'' o una 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 ensamblaje.
=== 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.
En mi caso, recibí este problema porque estaba ejecutando un proyecto web compilado para x64 usando IISExpress. Solucioné el problema al verificar la siguiente configuración en Visual Studio:
Herramientas | Opciones | Proyectos y soluciones | Proyectos web | Utilice la versión de 64 bits de IIS Express
Espero que esto ayude a cualquier otra persona con este mismo escenario y problema
En mi caso, revisé mi sitio y reemplacé el nombre del sitio con un nuevo nombre. 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 ensamblado con el nombre antiguo; solo tenía la intención de cambiar el nombre del sitio donde aparecía 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í.
En mi caso, tuve algo de mierda en mi web.config, específicamente un medio comentario httpHandler que una vez que lo limpié, mi problema de enlace desapareció.
Intenta configurar Copy Local en el explorador de soluciones para esos ensamblajes y asegúrate de que se eliminen en la carpeta especificada en el registro de enlace.
Además, probablemente fueron construidos usando el V2 CLR. Si lo fueran, tendrás que habilitar el enlace del modo mixto añadiéndolo a tu configuración web / de la aplicación
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
Me estaba dando 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ó.
Para resolver esto, me aseguré de que todos mis proyectos usaran la misma versión ejecutando el siguiente comando y verificando los resultados:
update-package Newtonsoft.Json -reinstall
Y, finalmente, eliminé 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>
Reemplazó las versiones de 64 bits de los tres dlls con sus versiones de 32 bits, limpió la carpeta temporal de archivos ASP.NET y compiló nuevamente. Ahora funciona sin problemas. Gracias por la ayuda.
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 estoy haciendo 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 un entorno de 64 bits y suplantando una cuenta de dominio, agregué el usuario de la cuenta del servicio de dominio a mi C: /Windows/Microsoft.NET/Framework64/v4.0.30319/archivos temporales de ASP.NET locales. carpeta con acceso de escritura (y modificación - para una buena medida).
En pocas palabras: asegúrese de que su carpeta de archivos Temp otorgue acceso de escritura al usuario con el que se ejecuta su aplicació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 seleccionar la versión .Net correcta.
También configuré el ISAPI de 64 bits como permitido bajo "Restricciones de ISAPI y CGI", pero no estoy seguro si eso ayudó.