.net - sitio - registro hklm software microsoft fusion enablelog dword como 1

¿Por qué la redirección de enlace de ensamblado no funciona en mi sitio web?

Question

Tengo un proyecto de sitio web que ejecuto desde Visual Studio utilizando el servidor web de desarrollo incorporado. La ruta virtual del sitio web se establece en /

El web.config contiene un elemento de tiempo de ejecución con

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="CMS.Controls" publicKeyToken="834b12a258f213f9" culture="neutral" />
<bindingRedirect oldVersion="4.1.3518.21577" newVersion="4.1.3561.21846" />
</dependentAssembly>
</assemblyBinding>
</runtime>

Ya xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0" atributo xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0" del elemento de configuration raíz.

Aquí está el error:

No se pudo cargar el archivo o el ensamblaje ''CMS.Controls, Versión = 4.1.3518.21577, Cultura = neutral, PublicKeyToken = 834b12a258f213f9'' o una de sus dependencias. La definición del manifiesto del ensamblaje ubicado no coincide con la referencia del ensamblaje. (Excepción de HRESULT: 0x80131040)

Aquí está el registro del enlace:

The operation failed.
Bind result: hr = 0x80131040. No description available.
...
LOG: DisplayName = CMS.Controls, Version=4.1.3518.21577, Culture=neutral, PublicKeyToken=834b12a258f213f9
(Fully-specified)
...
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:/Project/WebSite/web.config
LOG: Using machine configuration file from C:/Windows/Microsoft.NET/Framework/v2.0.50727/config/machine.config.
LOG: Post-policy reference: CMS.Controls, Version=4.1.3518.21577, Culture=neutral, PublicKeyToken=834b12a258f213f9
...
LOG: Assembly Name is: CMS.Controls, Version=4.1.3561.21846, Culture=neutral, PublicKeyToken=834b12a258f213f9
WRN: Comparing the assembly name resulted in the mismatch: Revision Number

Me parece que está ignorando mi redirección. Lo he estado mirando durante una hora, ¿tengo un error tipográfico o algo?

Answer 1

¿Es este un problema de 64bit / 32bit dll, a veces hay diferentes versiones de un dll para diferentes sistemas? Incluso si está ejecutando una versión de Windows de 64 bits, el servidor web de desarrollo funciona como una aplicación de 32 bits.

Puede cambiar a un servidor de desarrollo de 64 bits si cambia a CassinDev Server. Funciona igual de igual.

Answer 2

¿Ha intentado usar el FUSLOGVW.exe encuentra en la carpeta bin del SDK para su instalación de Visual Studio? Esto proporciona una salida más detallada para los fallos de enlace de ensamblaje.

El manifiesto que no coincide con la referencia del ensamblaje básicamente significa que se encontró el ensamblaje incorrecto, ya que el manifiesto es el metadato que describe el ensamblaje y su contenido. Encontré que esta serie de artículos me explicaron mucho sobre cómo funcionan los enlaces de ensamblaje; Preguntas frecuentes sobre el ensamblaje de .NET - Parte 1

Answer 3

Hace poco tuve un problema similar con el uso de dos versiones, así que limpié la solución y Rebuild nuevamente funcionó algunas veces. Además, si limpia no borró los archivos de la carpeta bin, borré los archivos manualmente y los construí nuevamente. Dependiendo de la versión de framework, necesitamos borrar los archivos, para .net 4 aquí está la carpeta para encontrar los archivos temporales donde la versión anterior está retrocediendo C: / WINDOWS / Microsoft.NET / Framework / v4.0.30319 / Temporary ASP.NET Archivos

Answer 4

La única razón por la que se puede explicar un error como este es que la nueva versión no se implementa en la GAC (en la carpeta de ensamblaje de Windows).

Importante: No implementado se aplica también si la clave pública no coincide entre las versiones, por ejemplo, la versión 1 la clave pública era abcd pero la nueva versión usa efgh . Asegúrese de que las coincidencias públicas y de que la versión está en el GAC.

Answer 5

Sé que ha pasado un tiempo, pero quizás esto pueda ayudar a alguien en algún momento ...

Obtuvimos exactamente el mismo problema en algún proyecto, era una aplicación web y no un sitio web, pero como el problema concierne a los ensamblajes a los que se hace referencia, no creo que la diferencia de tipo de proyecto sea relevante (puedo estar equivocado)

Digamos que tenemos los siguientes ensamblajes:

• WebApplicationAssembly

  1. CMSControlAssembly
  2. UserManagementAssembly

WebApplicationAssembly hace referencia a CMSControlAssembly y UserManagementAssembly.

Así que tratamos de hacer un ensamblaje en CMSControlAssembly, con tanto éxito como usted.

Después de un poco de excavación se encendieron las luces:

La cosa es que usamos los controles web dentro de CMSControlAssembly directamente dentro de nuestra aplicación web. (El ensamblaje se estableció con esto en mente)

Sin embargo, también fue referenciado a CMSControlAssembly por UserManagementAssembly, y esta fue la causa de nuestro problema.

UserManagementAssembly se compiló con una versión inferior de CMSControlAssembly que la utilizada por la aplicación web.

Esta versión inferior del ensamblaje no fue encontrada en ninguna parte por la aplicación web, ya que la única versión provista fue la dirigida por el ensamblaje.

Entonces, en realidad, el error no muestra un enlace de ensamblado no funcional, pero falta el ensamblado para UserManagementAssembly.