definición de manifiesto del ensamblado ubicado no coincide con la referencia de ensambladoHRESULT: 0x80131040: definición de manifiesto del ensamblado ubicado no coincide con la referencia de ensamblado
conseguir esto cuando se ejecuta a través nunit NCover. ¿Alguna idea?
Esto no coincide entre los ensamblados: una DLL a la que se hace referencia en un ensamblado no tiene una firma de método esperada.
Limpie la solución, reconstruya todo e intente de nuevo.
Además, tenga cuidado si se trata de una referencia a algo que está en el GAC; podría ser que algo en algún lugar apunta a una versión incorrecta. Asegúrese (a través de las Propiedades de cada referencia) de que se haya elegido la versión correcta o que la Versión específica esté configurada como falsa.
¿Hay alguna manera? para obligar al compilador a verificar este tipo de cosas en el momento de la compilación? Podría jurar que este fue el valor predeterminado en VS2005. – Maslow
(Downvoter: ¿por qué el downvote? Agregue un comentario para que todos podamos aprender y, si es necesario, puedo actualizar el respuesta.) –
Recientemente tuve este problema y ejecuté 'depends.exe' en la dll en cuestión. Me mostró que el dll se compiló en x86 mientras que algunas de las dependencias se compilaron en x64.
Si aún tiene problemas, le recomendaría usar depends.exe.
También hay Depends.Net, http://www.netomatix.com/development/DependsNet.aspx Mi problema era banal, module1 quería cargar module2 versión 5.0.0.0, y module2 era real ly 5.0.8.3760. Depends no marcó esto, y Depends.Net sí lo hizo. – RenniePet
En mi situación particular, obtuve esto como resultado de un CreateObject hecho en VBScript. La causa en mi caso era una versión del ensamblado que residía en el GAC, que era anterior al que yo había compilado. (tratando de resolver un problema anterior, instalé el ensamblado en el GAC).
Por lo tanto, si está trabajando con clases visibles COM, asegúrese de quitar las versiones anteriores de su ensamblaje del GAC, antes de registrar su nuevo ensamblaje con RegASM.
Si tienes este error tratando de agregar un componente de Visual Studio, - Microsoft.VisualStudio.TemplateWizardInterface - (después de tratar de instalar herramientas de desarrollo extraños)
consideran esta solución (cortesía de Larocha (gracias, quienquiera que seas)):
Microsoft.VisualStudio.TemplateWizardInterfac e"<dependentAssembly>
<!-- assemblyIdentity name="Microsoft.VisualStudio.TemplateWizardInterface" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/-->
<bindingRedirect oldVersion="0.0.0.0-8.9.9.9" newVersion="9.0.0.0" />
</dependentAssembly>
fuente: http://webclientguidance.codeplex.com/workitem/15444
Esto sucede generalmente cuando la versión de uno de los archivos DLL del entorno de prueba no coincide con el entorno de desarrollo.
limpia y construir su solución y tomar todos sus archivos DLL en el entorno donde está ocurriendo el error que debe arreglar
En mi caso para un proyecto de servicios de descanso WCF he tenido que añadir en el web.config una sección de ejecución donde había solicitado el archivo DLL, a continuación, añadir i:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" />
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
</dependentAssembly>
.
.
.
<runtime>
me encontré con problemas similares cuando se accede a los archivos de proyecto desde diferentes ordenadores a través de una carpeta compartida.En mi caso clean + reabuild no ayudó. Tuve que eliminar las carpetas bin y objects del directorio de salida.
En mi caso estaba sucediendo debido a WebGrease. Lo actualicé a la última versión (usando NuGet) pero estaba en conflicto con las dependencias. Agregué manualmente el código siguiente en web.config y funcionó como un amuleto.
<dependentAssembly>
<assemblyIdentity name="WebGrease" culture="neutral" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-1.6.5135.21930" newVersion="1.6.5135.21930" />
</dependentAssembly>
Tenga en cuenta que mi solución solo funcionará cuando el error esté relacionado con WebGrease. El código de error seguirá siendo el mismo. Además, debe cambiar la versión en oldVersion y newVersion en consecuencia.
Me encontré con este problema en un proyecto de API web.
proyecto Api estaba usando un paquete Nuget de una biblioteca con la versión 3. Y uno de los ensamblados de referencia decir X estaba usando la versión antigua del mismo paquete Nuget con la versión 2.
Siempre ensamblaje de referencia se construye o cualquier se reconstruye otra referencia de proyecto X, los ensamblados de proyecto de API se actualizan con una versión más baja. Y obtuve este error de referencia de ensamblaje.
La reconstrucción funciona, pero en mi caso quería una solución a largo plazo.
Hice que los ensamblajes hicieran referencia a la misma versión del paquete nuget.
Solo otro caso aquí. Tuve este error desde Managed Debugging Assistant deserializando por primera vez un archivo XML en objetos en VS2010/.NET 4. Se genera un archivo DLL que contiene clases para los objetos en un evento posterior a la creación (cosas habituales de estilo de Microsoft). Trabajó muy bien para varios proyectos en la misma solución, apareció un problema al hacer eso en uno más de los proyectos. Texto del error:
BindingFailure was detected Message: The assembly with display name MyProjectName.XmlSerializers' failed to load in the 'LoadFrom' binding context of the AppDomain with ID 1. The cause of the failure was: System.IO.FileLoadException: Could not load file or assembly MyProjectName.XmlSerializers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Desde aquí algunas respuestas sugieren una falta de coincidencia plataforma, me di cuenta de que los 3 proyectos y la solución tenía la configuración "plataformas mixtas" seleccionado, y 3 proyectos fueron compilados para x86 en lugar de Cualquier CPU. No tengo un código específico de la plataforma (aunque algunos archivos DLL provistos por proveedores dependen de algunas bibliotecas x86). He sustituido todas las apariciones de x86 en Cualquier CPU con esto:
for a in $(egrep '(x86|AnyCPU)' */*.csproj *.sln -l ) ; do echo $a ; sed -i 's/x86/AnyCPU/' $a ; done
A continuación, el proyecto sería construir, pero todas las opciones para ejecutar o depurar código estaría en gris. Reiniciar VS no ayudaría.
He revertido con git las referencias a la biblioteca x86, por las dudas, pero guardo AnyCPU para todo el código que compilo.
Después de F5 or Start Debugging Button is Greyed Out for Winform application? descargué y volví a cargar el proyecto inicial (también era el que tenía el problema inicial en primer lugar).
Después de eso, todo volvió a su lugar: el programa funciona sin el error inicial.
Ver http://www.catb.org/jargon/html/R/rain-dance.html, http://www.catb.org/jargon/html/V/voodoo-programming.html o http://www.catb.org/jargon/html/I/incantation.html y enlaces allí.
Mis problemas resueltos por eliminar toda la parte de tiempo de ejecución
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
tuve el problema por el que no encontraría el conjunto de PayPal y era porque me había llamado mi solución segura.Estoy seguro de que esta no será la respuesta para nadie, pero pensé que lo compartiría de todos modos: C# ASP.NET MVC PayPal not finding assembly
¡Solo eliminé el archivo settings.lic del proyecto y comencé a trabajar!
En mi caso tengo este mensaje durante la depuración:
"Error while calling service <ServiceName> Could not load file or assembly 'RestSharp,
Version=105.2.3.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)"
Causa
En mi proyecto he tenido 2 componentes internos utilizando el RestSharp pero ambos componentes tienen versión diferente de RestSharp (uno con la versión 105.2.3.0 y la otra con la versión 106.2.1.0).
Solución
Cualquiera de actualizar uno de los componentes de nuevo o degradar la otra. En mi caso, era más seguro para mí rebajar de 106.2.1.0 a 105.2.3.0 y actualizar el componente en el administrador de paquetes NuGet. Entonces ambos componentes tienen la misma versión.
Reconstruir y funcionó sin problemas.
Esto me pasó cuando actualicé web.config sin actualizar todas las dlls a las que se hace referencia.
Utilizando el filtro de difusión adecuado (cuidado con el filtro de comparación de directorio predeterminado de Meld ignorando los binarios) se identificó la diferencia, se copiaron los archivos y todo funcionó bien.
Es posible que desee reajustar el título y la pregunta un poco para atraer más ojos. Algo así como "Estoy intentando hacer X y estoy obteniendo este error: {descripción del error} ... etc etc. – Mostlyharmless
Está bien, pude encontrar esta pregunta por el código de error. –
Un hilo antiguo, pero es un problema común. para mí fue que por alguna razón tuve 2 instancias de Visual Studio ejecutando la misma solución. La otra no era visible en la barra de tareas, sino solo en el Administrador de tareas. Cerró ambas, luego se limpió y se reconstruyó. – Sami