Advertencia: conflictos encontrados entre diferentes versiones del mismo ensamblado dependiente

320

Actualmente estoy desarrollando una aplicación .NET, que consta de 20 proyectos. Algunos de esos proyectos se compilan usando .NET 3.5, otros aún son 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 existe la posibilidad de excluir esta advertencia (como usar #pragma disable en los archivos de código fuente)?

olifante
fuente

Respuestas:

410

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:

  1. Vuelva a compilar todos los proyectos para usar las mismas versiones (por ejemplo, mover todos a .Net 3.5). Esta es la opción preferida porque todo el código se está ejecutando con las versiones de las dependencias con las que se compilaron.

  2. Agregar una redirección vinculante . Esto suprimirá la advertencia. Sin embargo, sus proyectos .Net 2.0 estarán (en tiempo de ejecución) vinculados 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 error en Visual Studio.

  3. Uso CopyLocal=true. No estoy seguro de si esto suprimirá la advertencia. Al igual que la opción 2 anterior, significará que todos los proyectos utilizarán la versión .Net 3.5 de System.Windows.Forms.

Aquí hay un par de formas de identificar las referencias ofensivas:

  • Puede usar una utilidad como la que se encuentra en https://gist.github.com/1553265
  • Otro método simple es establecer la verbosidad de salida de Build (Herramientas, Opciones, Proyectos y Soluciones, Build and Run, Verbosity de salida de construcción de proyecto de MSBuild, Detallado) y después de construir, buscar la advertencia en la ventana de salida y ver el texto que se encuentra justo encima de ella. . (Sombrero para pauloya, quien sugirió esto en los comentarios sobre esta respuesta) .
Brian Low
fuente
99
Solo para una forma rápida de encontrarlo sin la utilidad: si agrega la redirección de enlace (como opción 2), mostrará las referencias involucradas; si lo desea, puede usar uno de los otros métodos para manejarlo y eliminar los redireccionamientos vinculantes de su archivo de configuración.
Brisbe
222
La forma más sencilla de encontrar cuáles son las "referencias ofensivas" es establecer la verbosidad de salida de Build (Herramientas, Opciones, Proyectos y Soluciones, Build and Run, Verbosity de salida de construcción del proyecto MSBuild, Detallado) y después de construir, buscar en la ventana de salida para la advertencia Vea el texto justo arriba.
pauloya
77
La redirección de enlace haciendo doble clic en la advertencia (paso 2) no elimina mi advertencia. Veo app.config agregado con el ensamblado que sospecho es la causa, pero la advertencia sigue ahí después de una limpieza / reconstrucción. También probé el paso 3 además, sin suerte. ¿Algunas ideas?
angularsen
99
¿Qué pasa si no son referencias de tus propios proyectos? Por ejemplo, hice referencia a un proyecto, que tiene dependencia de Newtonsoft.Json, Versión = 6.0.0.0, y hice referencia a otro proyecto, que tiene dependencia de Newtonsoft.Json, Versión = 4.5.0.0
Edward Ned Harvey
3
@ brian-low, ¿puedo sugerir agregar la configuración de verbosidad de salida de Build (como se sugiere en el comentario de @pauloya) como una opción en su respuesta junto con la utilidad vinculada? (Descargo de responsabilidad, en realidad intenté editar la respuesta para hacer eso, pero fue rechazada en la revisión :))
Rick Riensche
44

Básicamente, esto sucede cuando los ensamblados a los que hace referencia tienen "Copiar local" establecido en "Verdadero", lo que significa que se coloca una copia de la DLL en la carpeta bin junto con su exe.

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

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

Espero que tenga sentido!

Matt Hamilton
fuente
31

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 la verbosidad de salida de Build (Herramientas, Opciones, Proyectos y Soluciones, Build and Run, Verbosity de salida de construcción del proyecto MSBuild, Detallado) y después de construir, buscar en la ventana de salida para la advertencia Vea el texto justo arriba.

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 EF versiones 5 y 6.

usuario1477388
fuente
3
Pero ahora que tengo esta información, ¿cómo elimino el error? Puedo ver cuál es el conflicto, pero no puedo encontrar dónde hace referencia el proyecto a la versión en conflicto
Bassie
Hola @Bassie, lo primero que debe hacer es verificar el archivo del paquete nuget y determinar si necesita actualizar todos los archivos a la misma versión del paquete. Puede hacer esto ejecutando un comando similar a update-package [your package name] -version 6.0.0 -reinstallmi respuesta aquí stackoverflow.com/questions/22685530/…
user1477388
@Bassie, puedes hacer lo que sugiere la advertencia y agregar la redirección de enlace al archivo app.config. (si la actualización no es una opción, es decir.)
BrainSlugs83
@Bassie ve mi respuesta, donde te muestro que tienes cómo obtener diferentes ensamblados / .dlls que están causando problemas de desajuste.
newprint
22

Tuve el mismo problema con uno de mis proyectos, sin embargo, ninguno de los anteriores 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é dos veces 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 hizo referencia directamente desde todos los demás proyectos en mi solución. La actualización de la referencia en el proyecto referenciado lo resolvió.

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, me tomó un par de horas descubrirlo, así que espero que alguien más se beneficie también.

Gorgsenegger
fuente
1
El mismo problema aqui. Sin embargo, no tengo oportunidad de actualizar la referencia a una versión más nueva. Intenté usar un App.config: mientras funciona para la aplicación, Visual Studio 2010 parece ignorarlo durante la compilación.
Thomas Weller
1
wow, he tenido estos problemas durante dos meses y no pude identificarlo y resolverlo. Por alguna razón, se bloqueará solo durante la depuración y, en algunos casos, reemplazará manualmente el molesto .dll con el real en la carpeta bin cuando eso suceda. La depuración fue un verdadero dolor. Cuando leí tu respuesta, me di cuenta de que esto era exactamente lo que me estaba pasando y lo arreglé en 5 minutos :)
Dennis Puzak
19

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

Tiago Gouvêa
fuente
Gracias por el consejo. Esta vez no me ayudó, pero es bueno saber que está ahí.
BrainSlugs83
8

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

MoMo
fuente
99
Sin embargo
Lucas
Esto me salva! He intentado otra solución desde ayer, pero esta resolvió mi problema. Incluyendo el comentario sobre esto ^. ¡Gracias!
vnpnlz
6

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

De:

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

A:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>
Phil50
fuente
Esta fue la solución para mí. Tuve una redirección vinculante a la versión superior, y solo funcionó una vez que me mudé a la versión inferior.
mrwaim
1
¿por qué? Muy extraño para mi. No uso EF, pero pensé que siempre queremos pasar a la última versión.
Hoàng Long
1
@ HoàngLong porque la versión a la que hace referencia es la versión anterior, pero la versión que está incluyendo es la más nueva.
BrainSlugs83
3

Tengo otra forma de hacerlo si está utilizando Nuget para administrar sus dependencias. Descubrí 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:

  1. Desde el Explorador de soluciones, haga clic con el botón derecho en el Proyecto y haga clic en 'Administrar paquetes Nuget'

  2. 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 que pueda verificarlo con Google para ver qué paquetes de Nuget están instalados

  3. Desinstala tus paquetes. Está bien, los agregaremos de vuelta.

  4. Instale inmediatamente los paquetes que necesita. Lo que hará Nuget no solo es obtener la última versión, sino que alterará sus referencias y también agregará los redireccionamientos vinculantes para usted.

  5. Haz esto para todos tus proyectos.

  6. En el nivel de solución, haga una limpieza y reconstrucción.

Es posible que desee comenzar con los proyectos inferiores y avanzar hasta 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]

Cuenta
fuente
2

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 ocurre cuando el componente externo al que hace referencia uno de sus proyectos tiene el mismo nombre y una versión diferente que otro componente en otro ensamblaje.

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

Intente encontrar qué proyectos tienen estos conflictos, elimine los componentes de la lista de referencia, luego agréguelos nuevamente asegurándose de que está apuntando al mismo archivo.

Jon Limjap
fuente
2

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

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

=> luego, limpie, reconstruya e intente implementar.

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

Neelam Prajapati
fuente
1

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

Tristan Lewis
fuente
1

Si usaba NuGet, todo lo que tenía que hacer era:

  1. haga clic con el botón derecho en proyecto y haga clic en Administrar paquetes NuGet.

  2. haga clic en la rueda dentada en la parte superior derecha

  3. haga clic en la pestaña General en NuGet Package Manager arriba de Fuentes de paquetes

  4. marque "Omitir la aplicación de redireccionamientos de enlace" en Redireccionamientos de enlace

  5. Limpia y reconstruye y la advertencia se ha ido

Pan comido

0tombo0
fuente
1

Acabo de pasar algún tiempo depurando el mismo problema. Tenga en cuenta que ese problema podría no ser entre diferentes proyectos, sino entre varias referencias en un proyecto que dependen de diferentes versiones del mismo dll / ensamblado. En mi caso, el problema era que las FastMember.dllversiones de referencia no coinciden y que provienen de dos paquetes NuGet diferentes en un solo proyecto. Cuando me dieron un proyecto, no se compiló porque faltaban los paquetes NuGet y VS se negó a restaurar los paquetes faltantes. A través del menú NuGet, actualizo manualmente todos los NuGets a la última versión, que es cuando apareció la advertencia.

En Visual Studio, Tools > Options > Build and Run > MSBuld Project build output verbosity: (set to) Diagnostics.busque las líneas There was a conflict betweenen la Outputventana. A continuación se muestra la parte de la salida que obtuve:

1>  There was a conflict between "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null". (TaskId:19)
1>      "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" was chosen because it was primary and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" was not. (TaskId:19)
1>      References which depend on "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" [C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll]. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll". (TaskId:19)
1>              FastMember, Version=1.5.0.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)
1>      References which depend on "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" []. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll". (TaskId:19)
1>              ClosedXML, Version=0.94.2.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)

Darse cuenta de Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll"

ClosedXML.dllproviene de ClosedXMLNuGet y depende de FastMember.dll 1.3.0.0. Además, también hay FastMemberNuget en el proyecto, y lo ha hecho FastMember.dll 1.5.0.0. Discordancia !

He desinstalado ClosedXML& FastMemberNuGets, porque tuve un redireccionamiento vinculante e instalé la última versión de ¡ ClosedXMLEso solucionó el problema!

nueva impresión
fuente
0

Esto me pasó a mí también. Una dll fue referenciada dos veces: una directamente (en referencias) y otra indirectamente (referenciada por otro proyecto referenciado). Eliminé la solución de referencia directa, limpia y reconstruida. Problema fijo.

Igor Gorjanc
fuente
0
  1. Abra el "Explorador de soluciones".
  2. Haga clic en "Mostrar todos los archivos"
  3. Expandir "Referencias"
  4. Verá una (o más) referencia (s) con un icono ligeramente diferente al resto. Por lo general, es con un cuadro amarillo que le sugiere que tome nota de ello. Solo quítalo.
  5. Agregue la referencia nuevamente y compile su código.
  6. Eso es todo.

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

Sukhi
fuente
0

Otra cosa a considerar y verificar es, asegúrese de que no tiene ningún servicio en ejecución que esté usando esa carpeta bin. si es detener el servicio y reconstruir la solución

Telwa Gangnam
fuente
0

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

Dpedrinha
fuente
0

Tuve ese problema cuando mi proyecto tenía referencia a NETStandardLibrary y uno de los ensambles referenciados fue publicado para netcore. Acabo de publicarlo como netstandard y el problema desapareció

Jacek Plesnar
fuente
0

Aquí está la solución, estilo .NET Core 3.0: https://github.com/HTD/ref-check

Cuando encuentre qué conflictos, tal vez pueda resolverlos. Si las referencias en conflicto provienen de otros paquetes, no tienes suerte o necesitas usar fuentes en su lugar.

En mi caso, los paquetes en conflicto son a menudo propios, por lo que puedo solucionar problemas de dependencia y volver a publicarlos.

Harry
fuente