referencia newtonsoft manifiesto ensamblado definición con coincide .net nunit ncover

.net - newtonsoft - HRESULT: 0x80131040: la definición del manifiesto del ensamblaje ubicado no coincide con la referencia de ensamblaje



la definición del manifiesto del ensamblado no coincide con la referencia al ensamblado (13)

La definición del manifiesto del ensamblaje ubicado no coincide con la referencia de ensamblaje

obteniendo esto cuando ejecuta nunit a través de ncover. ¿Alguna idea?

¡Solo borré el archivo settings.lic del proyecto y empiezo a trabajar!

En mi caso para un proyecto de servicios de descanso de wcf, tuve que agregar en la web.config una sección de tiempo de ejecución donde estaba el dll solicitado, luego agregué:

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

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.

En mi situación particular, obtuve esto como resultado de un CreateObject hecho en VBScript. La causa en mi caso era una versión de la asamblea que residía en el GAC, que era más antigua que la que había compilado. (tratando de resolver un problema anterior, instalé el ensamblado en el GAC).

Por lo tanto, si está trabajando con clases COM visibles, asegúrese de quitar versiones anteriores de su ensamblaje del GAC, antes de registrar su nuevo ensamblaje con RegASM.

Esto es una falta de coincidencia entre los ensamblados: una DLL a la que se hace referencia desde un ensamblado no tiene una firma de método esperada.

Limpia la solución, reconstruye todo e intenta de nuevo.

Además, tenga cuidado si esto es 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.

Esto generalmente ocurre cuando la versión de uno de los archivos DLL del entorno de prueba no coincide con el entorno de desarrollo.

Limpia y crea tu solución y lleva todos tus archivos DLL al entorno donde está ocurriendo el error que debería arreglarlo

Hace poco tuve este problema y ejecuté ''depends.exe'' en el dll en cuestión. Me mostró que el dll se compiló en x86 mientras que algunas de las dependencias se compilaron en x64.

Si todavía tiene problemas, le recomendaría usar depends.exe.

Me encontré con este problema en un proyecto de API web.

El proyecto Api estaba usando un paquete nuget de una biblioteca con la versión 3. Y uno de los ensamblajes a los que se hace referencia dice que X estaba usando una versión anterior del mismo paquete nuget con la versión 2.

Siempre que se construya ensamblado referenciado o se reconstruya cualquier otro proyecto que haga referencia a X, los ensamblados del proyecto api se actualizarán con la versión más baja. Y obtuve este error de referencia de ensamblaje.

Rebuild funciona, pero en mi caso quería una solución a largo plazo.

Hice que las asambleas hicieran referencia a la misma versión del paquete nuget.

Me encontré con problemas similares al acceder a los archivos del proyecto desde diferentes computadoras 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.

Mis problemas resueltos eliminando 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>

Si tiene este error al intentar agregar un componente a Visual Studio, - Microsoft.VisualStudio.TemplateWizardInterface - (después de intentar instalar herramientas de desarrollo extrañas)

considere esta solución (cortesía de larocha (gracias, quienquiera que sea)):

  1. Abra C: / Archivos de programa / Microsoft Visual Studio 9.0 / Common7 / IDE / devenv.exe.config en un editor de texto
  2. Encuentre esta cadena: " Microsoft.VisualStudio.TemplateWizardInterfac e"
  3. Comenta el elemento para que se vea así:

<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

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 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 de error:

Se detectó BindingFailure Mensaje: El ensamblado con el nombre para mostrar MyProjectName.XmlSerializers ''no se pudo cargar en el contexto de enlace'' LoadFrom ''del AppDomain con ID 1. La causa del error fue: System.IO.FileLoadException: No se pudo cargar el archivo o ensamblado MyProjectName.XmlSerializers, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null ''o una de sus dependencias. La definición del manifiesto del ensamblaje ubicado no coincide con la referencia de ensamblaje. (Excepción de HRESULT: 0x80131040)

Dado que algunas respuestas aquí sugerían una incompatibilidad de plataformas, noté que 3 proyectos y la solución tenían la configuración de "plataformas mixtas" seleccionada, y 3 proyectos fueron compilados para x86 en lugar de AnyCPU. No tengo un código específico de la plataforma (aunque algunos archivos DLL provistos por proveedores dependen de algunas bibliotecas x86). Reemplacé todas las ocurrencias de x86 en AnyCPU con esto:

for a in $( egrep ''(x86|AnyCPU)'' */*.csproj *.sln -l ) ; do echo $a ; sed -i ''s/x86/AnyCPU/'' $a ; done

Luego, el proyecto se compilaría, pero todas las opciones para ejecutar o depurar código se atenuarían. Reiniciar VS no ayudaría.

Revertí con git las referencias a la biblioteca x86, por las dudas, pero guardé AnyCPU para todo el código que compilaba.

¿Después de F5 o el botón Iniciar depuración está atenuado para la aplicación Winform? Descargué y volví a cargar el proyecto inicial (también fue en el que apareció el problema inicial).

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 / jerga / html / I / incantation.html y enlaces allí.

Tuve el problema donde no encontraría el ensamblado de PayPal y fue porque había nombrado mi solución PayPal. Estoy seguro de que esta no será la respuesta para nadie, pero pensé que la compartiría de todos modos: C # ASP.NET MVC PayPal no encuentra el ensamblaje