Advertencia: conflictos encontrados entre diferentes versiones del mismo ensamblado dependiente

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

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

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!

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.

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.

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.

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

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>

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]

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.

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

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.

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

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!

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.

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

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

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.

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ó

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.