.net - net - se encontraron conflictos entre diferentes versiones de microsoft.csharp que no se pudieron resolver

Advertencia: Se encontraron conflictos entre diferentes versiones del mismo ensamblaje dependiente (15)

Abra el "Explorador de soluciones".
Haga clic en "Mostrar todos los archivos"
Expandir "Referencias"
Verá una (o más) referencia (s) con un icono ligeramente diferente al resto. Por lo general, es con un cuadro amarillo que sugiere tomar nota de ello. Sólo quítalo.
Agregue la referencia de nuevo y compile su código.
Eso es todo.

En mi caso, hubo un problema con la referencia de MySQL. De alguna manera, podría enumerar tres versiones de la misma en la lista de todas las referencias disponibles; para .net 2.0, .net 4.0 y .net 4.5. Seguí el proceso 1 al 6 anterior y funcionó para mí.

Actualmente estoy desarrollando una aplicación .NET, que consta de 20 proyectos. Algunos de esos proyectos se compilan utilizando .NET 3.5, otros siguen siendo proyectos .NET 2.0 (hasta ahora no hay problema).

El problema es que si incluyo un componente externo siempre recibo la siguiente advertencia:

"Found conflicts between different versions of the same dependent assembly".

¿Qué significa exactamente esta advertencia y es posible que exista la posibilidad de excluir esta advertencia (como usar #pragma disable en los archivos de código fuente)?

=> comprobar que habrá alguna instancia de aplicación instalada parcialmente.

=> en primer lugar, desinstale esa instancia de la aplicación de desinstalación.

=> entonces, limpia, reconstruye, e intenta desplegar.

Esto solucionó mi problema. Espero que también te ayude. Atentamente.

Acabo de recibir este mensaje de advertencia, limpié la solución y la volví a compilar (Crear -> Solución limpia) y desapareció.

Básicamente, esto sucede cuando los ensamblajes a los que hace referencia tienen la opción "Copia local" establecida en "Verdadero", lo que significa que una copia de la DLL se coloca en la carpeta bin junto con su archivo exe.

Como Visual Studio también copiará todas las dependencias de un ensamblado al que se hace referencia, es posible terminar con dos compilaciones diferentes del mismo ensamblaje al que se hace referencia. Esto es más probable que suceda si sus proyectos están en soluciones separadas y, por lo tanto, se pueden compilar por separado.

La forma en que lo he logrado es establecer Copiar local en Falso para referencias en proyectos de ensamblaje. Solo hágalo para ejecutables / aplicaciones web donde necesite el ensamblaje para ejecutar el producto terminado.

Espero que tenga sentido!

En Visual Studio, si hace clic con el botón derecho en la solución y Administra paquetes nuget, hay una pestaña "Consolidar" que establece todos los paquetes con la misma versión.

Esta advertencia significa que dos proyectos hacen referencia al mismo ensamblaje (por ejemplo, System.Windows.Forms ) pero los dos proyectos requieren versiones diferentes. Tienes pocas opciones:

Recompile todos los proyectos para usar las mismas versiones (por ejemplo, mueva todos a .Net 3.5). Esta es la opción preferida porque todo el código se ejecuta con las versiones de las dependencias con las que se compilaron.
Añadir una redirección de enlace . Esto suprimirá la advertencia. Sin embargo, sus proyectos .Net 2.0 estarán vinculados (en tiempo de ejecución) a las versiones .Net 3.5 de ensamblajes dependientes, como System.Windows.Forms . Puede agregar rápidamente una redirección de enlace haciendo doble clic en el error en Visual Studio.
Utilice CopyLocal=true . No estoy seguro de si esto suprimirá la advertencia. Como la opción 2 anterior, significará que todos los proyectos usarán la versión .Net 3.5 de System.Windows.Forms.

Aquí hay un par de maneras para identificar las referencias ofensivas:

Puede usar una utilidad como la que se encuentra en https://gist.github.com/1553265
Otro método simple es configurar el nivel de detalle de los resultados de compilación (Herramientas, Opciones, Proyectos y Soluciones, Crear y Ejecutar, Nivel de detalle de los resultados de compilación del proyecto MSBuild, Detallado) y, después de crear, buscar la advertencia en la ventana de resultados y mirar el texto justo arriba. . (Punta de sombrero a pauloya que sugirió esto en los comentarios sobre esta respuesta) .

Esto me pasó a mí también. Se hizo referencia a una dll dos veces: una vez directamente (en referencias) y una indirectamente (referenciada por otro proyecto referenciado). Quité la referencia directa, limpié y reconstruí la solución. Problema fijo.

Esto realmente depende de su componente externo. Cuando hace referencia a un componente externo en una aplicación .NET, genera un GUID para identificar ese componente. Este error se produce cuando el componente externo al que hace referencia uno de sus proyectos tiene el mismo nombre y una versión diferente a la de otro componente similar en otro conjunto.

Esto sucede a veces cuando usa "Examinar" para buscar referencias y agregar la versión incorrecta del ensamblaje, o tiene una versión diferente del componente en su repositorio de códigos como la que instaló en la máquina local.

Intente encontrar qué proyectos tienen estos conflictos, elimine los componentes de la lista de referencia y luego vuelva a agregarlos asegurándose de que apunta al mismo archivo.

Otra cosa que debe considerar y verificar es, asegúrese de no tener ningún servicio en ejecución que esté usando esa carpeta bin. Si es así, detén el servicio y reconstruye la solución.

Parece que hay un problema en Mac Visual Studio al editar archivos .resx. Realmente no sé qué sucedió, pero tuve este problema tan pronto como edité algunos archivos .resx en mi Mac. Abrí el proyecto en Windows, abrí los archivos y eran como si no hubieran sido editados. Así que los edité, guardé y todo comenzó a funcionar de nuevo en Mac también.

Quería publicar la solución de pauloya que proporcionaron en los comentarios anteriores. Creo que es la mejor solución para encontrar las referencias ofensivas.

La forma más sencilla de encontrar cuáles son las "referencias ofensivas" es establecer el nivel de detalle de los resultados de compilación (Herramientas, Opciones, Proyectos y Soluciones, Crear y Ejecutar, Proyecto detallado de MSBuild, detallado) y después de crear, busque la ventana de resultados por la advertencia Ver el texto justo encima de él.

Por ejemplo, cuando busca "conflicto" en el panel de salida, puede encontrar algo como esto:

3> There was a conflict between "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089". 3> "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it was primary and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was not.

Como puede ver, existe un conflicto entre las versiones 5 y 6 de EF.

También tuve este problema, en mi caso fue causado por tener la propiedad "Versión específica" en un número de referencias establecido en verdadero. Cambiar esto a falso en esas referencias resolvió el problema.

Tengo otra forma de hacerlo si está utilizando Nuget para administrar sus dependencias. He descubierto que a veces VS y Nuget no coinciden y Nuget no puede reconocer que sus proyectos no están sincronizados. Los paquetes.config dirán una cosa, pero la ruta que se muestra en Referencias - Propiedades indicará otra cosa.

Si está dispuesto a actualizar sus dependencias, haga lo siguiente:

Desde el Explorador de soluciones, haga clic con el botón derecho en el Proyecto y haga clic en ''Administrar paquetes Nuget''
Seleccione la pestaña ''Paquetes instalados'' en el panel izquierdo Registre sus paquetes instalados Es posible que desee copiar sus paquetes.config a su escritorio primero si tiene mucho, para poder verificarlo con Google para ver qué paquetes de Nuget están instalados
Desinstala tus paquetes. Está bien, vamos a añadirlos de vuelta.
Inmediatamente instale los paquetes que necesita. Lo que hará Nuget es no solo obtener la última versión, sino que también alterará sus referencias y también agregará las redirecciones de enlace para usted.
Haz esto para todos tus proyectos.
En el nivel de la solución, haga un Limpiar y Reconstruir.

Es posible que desee comenzar con los proyectos inferiores y trabajar para llegar a los de nivel superior, y reconstruir cada proyecto a medida que avanza.

Si no desea actualizar sus dependencias, puede usar la consola del administrador de paquetes y usar la sintaxis Update-Package -ProjectName [yourProjectName] [packageName] -Version [versionNumber]

Tuve el mismo problema con uno de mis proyectos, sin embargo, ninguno de los anteriores me ayudó a resolver la advertencia. Revisé el archivo de registro de compilación detallado, usé AsmSpy para verificar que usé las versiones correctas para cada proyecto en la solución afectada, verifiqué las entradas reales en cada archivo de proyecto, nada ayudó.

Finalmente, resultó que el problema era una dependencia anidada de una de las referencias que tenía en un proyecto. Esta referencia (A) a su vez requería una versión diferente de (B) a la que se hacía referencia directamente de todos los otros proyectos en mi solución. Se solucionó la actualización de la referencia en el proyecto de referencia.

Solution A +--Project A +--Reference A (version 1.1.0.0) +--Reference B +--Project B +--Reference A (version 1.1.0.0) +--Reference B +--Reference C +--Project C +--Reference X (this indirectly references Reference A, but with e.g. version 1.1.1.0) Solution B +--Project A +--Reference A (version 1.1.1.0)

Espero que lo anterior muestre lo que quiero decir, tardé un par de horas en averiguarlo, así que espero que alguien más también se beneficie.

Tuve el mismo problema y lo resolví cambiando lo siguiente en web.config.

Me sucedió porque estoy ejecutando la aplicación usando Newtonsoft.Json 4.0

Desde:

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