Resolución de MSB3247: conflictos encontrados entre diferentes versiones del mismo ensamblaje dependiente

Una solución .NET 3.5 terminó con esta advertencia al comstackr con msbuild.

A veces, NDepend podría ayudar, pero en este caso no dio más detalles. Al igual que Bob , terminé teniendo que recurrir a abrir cada ensamblaje en ILDASM hasta que encontré el que hacía referencia a una versión anterior del ensamblaje dependiente.

Intenté usar MSBUILD de VS 2010 Beta 2 (como el artículo de Connect indicaba que esto se había solucionado en la próxima versión del CLR) pero eso tampoco proporcionó más detalles (tal vez se solucionó después de Beta 2)

¿Hay un mejor enfoque (más automatizado)?

Cambie la “verbosidad de salida de comstackción del proyecto de MSBuild” a “Detallada” o superior. Para hacer esto, siga estos pasos:

  1. Abra el cuadro de diálogo Opciones ( Herramientas -> Opciones … ).
  2. En el árbol de la izquierda, seleccione el nodo Proyectos y soluciones , y luego seleccione Generar y Ejecutar .
    • Nota: si este nodo no aparece, asegúrese de que la checkbox en la parte inferior del cuadro de diálogo Mostrar todas las configuraciones esté marcada.
  3. En la página de herramientas / opciones que aparece, establezca el nivel de detalle de la salida de comstackción del proyecto de MSBuild en la configuración adecuada según su versión:

    • Diagnósticos cuando están en VS2012, VS2013 o VS2015 (el mensaje en estas versiones dice que debe usar “Detallado”, pero esto es completamente incorrecto, debe usar “Diagnósticos” )
    • Detallado cuando estás en VS2010
    • Normal será suficiente en VS2008 o anterior.
  4. Construya el proyecto y mire en la ventana de salida.

Mira los mensajes de MSBuild. La tarea ResolveAssemblyReferences , que es la tarea a partir de la cual se origina MSB3247, debería ayudarlo a depurar este problema en particular.

Mi caso específico fue una referencia incorrecta a SqlServerCe. Vea abajo. Tenía dos proyectos que hacen referencia a dos versiones diferentes de SqlServerCe. Fui al proyecto con la versión anterior, eliminé la referencia y luego agregué la referencia correcta.

 Target ResolveAssemblyReferences: Consider app.config remapping of assembly "System.Data.SqlServerCe, ..." from Version "3.5.1.0" [H:\...\Debug\System.Data.SqlServerCe.dll] to Version "9.0.242.0" [C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PublicAssemblies\System.Data.SqlServerCe.dll] to solve conflict and get rid of warning. C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : warning MSB3247: Found conflicts between different versions of the same dependent assembly. 

No tiene que abrir cada ensamblaje para determinar las versiones de los ensambles a los que se hace referencia.

  • Puede verificar las Propiedades de cada Referencia.
  • Abra las propiedades del proyecto y verifique las versiones de la sección Referencias.
  • Abra los proyectos con un editor de texto.
  • Use el reflector .Net.

Mike Hadlow ha publicado una pequeña aplicación de consola llamada AsmSpy que enumera muy bien las referencias de cada ensamblaje:

 Reference: System.Net.Http.Formatting 4.0.0.0 by Shared.MessageStack 4.0.0.0 by System.Web.Http Reference: System.Net.Http 2.0.0.0 by Shared.MessageStack 2.0.0.0 by System.Net.Http.Formatting 4.0.0.0 by System.Net.Http.WebRequest 2.0.0.0 by System.Web.Http.Common 2.0.0.0 by System.Web.Http 2.0.0.0 by System.Web.Http.WebHost 

Esta es una forma mucho más rápida de llegar al final de la advertencia MSB3247, que depender de la salida MSBuild.

Descubrí que (al menos en Visual Studio 2010) necesita establecer la verbosidad de salida al menos detallada para poder detectar el problema.

Es posible que mi problema fuera una referencia que anteriormente era una referencia del GAC, pero que ya no era el caso después de la reinstalación de mi máquina.

En algún momento la respuesta de @AMissico no es suficiente. En mi caso, no pude encontrar el error en las ventanas de Salida, así que decidí crear un archivo de registro y analizarlo, siguiendo los siguientes pasos:

  1. Guardar el registro de comstackción en un archivo … https://msdn.microsoft.com/en-us/library/ms171470.aspx

    msbuild MyProject.proj /fl /flp:logfile=MyProjectOutput.log;verbosity=detailed

  2. Encuentre el texto: warning MS... o la información de advertencia específica: (por ejemplo, línea 9293) Found conflicts between different versions... y el detalle completo del error de conflicto estará arriba de este mensaje (por ejemplo, la línea 9277) There was a conflicts between... Encuentra el mensaje de error

Visual Studio 2013

Esta advertencia generada para ASP.NET MVC 4 beta por defecto ver aquí

En cualquier molde, esta Advertencia se puede eliminar editando manualmente el archivo .csproj para su proyecto.

modificar ……..: Reference Include = “System.Net.Http”

para leer ……: Reference Include = “System.Net.Http, Version = 4.0.0.0”

Use un lector de dependencia

Utilizando dep.exe puede listar todas las dependencias anidadas de una carpeta completa. Combinado con herramientas de Unix como grep o awk, puede ayudarte a resolver tu problema

Encontrar ensamblajes a los que se hace referencia en más de una versión

 $ dep | awk '{ print $1 " " $2; print $4 " " $5 }' | awk '{ if (length(versions[$1]) == 0) versions[$1] = $2; if (versions[$1] != $2) errors[$1] = $1; } END{ for(e in errors) print e } ' System.Web.Http 

Esta línea de comandos oscura ejecuta dep.exe y luego canaliza la salida dos veces para awk a

  • coloque el padre y el hijo en una sola columna (de forma predeterminada, cada línea contiene un padre y un hijo para express el hecho de que este padre depende de ese hijo)
  • luego haz una especie de ‘grupo por’ usando una matriz asociativa

Comprender cómo se obtuvo este conjunto en su contenedor

 $ dep myproject/bin | grep -i System\.Web\.Http MyProject-1.0.0.0 >> System.Web.Http.Web-5.2.3.0 2 ( FooLib-1.0.0.0 ) MyProject-1.0.0.0 >> System.Web.Http.Web-4.0.0.0 2 ( BarLib-1.0.0.0 ) FooLib-1.0.0.0 > System.Web.Http.Web-5.2.3.0 1 BarLib-1.0.0.0 > System.Web.Http.Web-4.0.0.0 1 

En este ejemplo, la herramienta le mostrará que System.Web.Http 5.2.3 proviene de su dependencia de FooLib, mientras que la versión 4.0.0 proviene de BarLib.

Entonces puedes elegir entre

  • convencer a los propietarios de las libs para que utilicen la misma versión
  • deja de usar uno de ellos
  • agregar redireccionamientos de enlace en su archivo de configuración para usar la última versión

Cómo ejecutar estas cosas en Windows

Si no tiene un shell de tipo Unix, tendrá que descargar uno antes de poder ejecutar awk y grep . Pruebe uno de los siguientes

  • cmder + awk + dep.exe
  • gitbash + awk + dep.exe
  • cygwin + dep.exe

Tuve el mismo error y no pude resolverlo con las otras respuestas. Descubrí que podemos “consolidar” paquetes NuGet.

  1. Haga clic derecho en la solución
  2. Haga clic en Administrar paquetes de Nuget
  3. Consolidar pestaña y actualizar a la misma versión.

También tuve este problema y usé el consejo de AMissico para descubrir el problema (aunque tenía que establecer el nivel de detalle en Detallado).

El problema fue bastante directo después de encontrar al culpable.

Antecedentes: actualicé mi proyecto de VS2008 a VS2010. En VS2008, el marco de destino era 3.5 y cuando lo introduje en VS2010 lo cambié a 4 (completo). También actualicé algunos componentes de terceros, incluidos los informes de Crystal.

Resultó que la mayoría de las referencias del sistema apuntaban a la versión 4.0.0.0, pero una pareja no se había cambiado automáticamente (System and System.Web.Services) y todavía estaban buscando en 2.0.0.0. Los informes de Crystal están haciendo referencia a 4.0.0.0, por lo que aquí era donde se estaban produciendo los conflictos. Simplemente colocando el cursor en la primera biblioteca del sistema en el explorador de soluciones, deslice el cursor hacia abajo en la lista y busque cualquier referencia a 2.0.0.0, eliminando y volviendo a agregar la versión 4.0.0.0 más reciente que hizo el truco.

Lo extraño fue que la mayoría de las referencias se habían actualizado correctamente y, si no fuera por los informes de Crystal, probablemente nunca me hubiera dado cuenta …

Hice una aplicación basada en la aplicación Mike Hadlow: AsmSpy .

Mi aplicación es una aplicación WPF con GUI y se puede descargar desde mi servidor web casero: AsmSpyPlus.exe .

El código está disponible en: GitHub

Muestra Gui

Como se menciona aquí , debe eliminar las referencias no utilizadas y las advertencias irán.

El administrador de comstackción de ASP.NET está construyendo el sitio web yendo por las carpetas alfabéticamente, y para cada carpeta se da cuenta de sus dependencias y construye primero las dependencias y luego la carpeta seleccionada.

En este caso, la carpeta problemática que es ~ / Controls, se selecciona para ser construida al principio, desde un motivo desconocido, construye algunos de los controles allí como un ensamblaje separado en lugar de dentro del mismo ensamblaje que otros controles (parece estar conectado al hecho de que algunos controles dependen de otros controles en la misma carpeta).

Entonces la siguiente carpeta que se construye (~ / File-Center / Control) depende de la carpeta raíz ~ / que depende de ~ / Controls, por lo que la carpeta ~ / Controls se está construyendo nuevamente solo esta vez los controles que fueron separados a su propio conjunto ahora se unen al mismo conjunto que otros controles con el ensamblaje separado aún referenciado.

Entonces, en este momento, el ensamblaje 2 (al menos) tiene los mismos controles y la comstackción falla.

Aunque todavía no sabemos por qué sucedió esto, pudimos evitar cambiar el nombre de la carpeta Controles a ZControls, de esta manera no se comstack antes de ~ / File-Center / Control, solo después y de esta manera se construye como debería.

Arreglo rapido:

Haga clic con el botón derecho en la solución -> Administrar paquetes de NuGet para la solución -> En Consolidar , puede ver si hay diferentes versiones del mismo paquete instaladas. Desinstale las diferentes versiones e instale la última.

La forma más sencilla sin sin tener en cuenta las dependencias (internas):

  1. Abra “Solution Explorer”.
  2. Haga clic en “Mostrar todos los archivos”
  3. Expandir “Referencias”
  4. Verá una (o más) referencia (s) con un icono ligeramente diferente que el rest. Por lo general, es con un cuadro amarillo que sugiere que tome nota de ello. Solo elimínalo.
  5. Agregue la referencia 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 de la misma bajo la lista de todas las referencias disponibles. Seguí los procesos 1 a 6 anteriores y funcionó para mí.

Complemento de la comunidad de Visual Studio para Mac:

Como la respuesta de AMISICO requiere cambiar el nivel de registro, y ASMSpy ni ASMSpyPlus están disponibles como una solución multiplataforma, aquí hay una breve adición para Visual Studio para Mac:

https://docs.microsoft.com/en-us/visualstudio/mac/compiling-and-building

Está en Visual Studio Community → Preferencias … → Proyectos → Build Log → verbosity