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

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

A veces, NDepend puede ayudar, pero en este caso no dio más detalles. Al igual que Bob , terminé teniendo que recurrir a la apertura de 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 solucionó en la próxima versión del CLR) pero eso tampoco proporcionó más detalles (tal vez solucionado después de Beta 2)

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

Cambie el "nivel de detalle de salida de compilación del proyecto MSBuild" a "Detallado" 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 Compilar y ejecutar .
   • Nota: si este nodo no aparece, asegúrese de que la casilla de verificación en la parte inferior del cuadro de diálogo muestre todas las configuraciones esté marcada.

3. En la página de herramientas / opciones que aparece, configure el detalle de salida de compilación del proyecto MSBuild en la configuración adecuada según su versión:

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

Echa un vistazo a los mensajes de MSBuild. losResolveAssemblyReferences tarea, que es la tarea de la que se origina MSB3247, debería ayudarlo a depurar este problema en particular.

Mi caso específico fue una referencia incorrecta a SqlServerCe. Vea abajo. Tuve 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 conjunto para determinar las versiones de los conjuntos referenciados.

• 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.
• Utilice .Net Reflector.

Mike Hadlow ha publicado una pequeña aplicación de consola llamada AsmSpy que enumera bastante 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 de MSBuild.

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. Guardando el registro de compilación en un archivo ... https://msdn.microsoft.com/en-us/library/ms171470.aspx

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

2. Busque el texto: warning MS...o la información de advertencia específica: (por ejemplo, la 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...

Visual Studio 2013

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

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

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

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

Esta advertencia generada para la versión beta de ASP.NET MVC 4 predeterminada, vea aquí

En cualquier conversión, esta Advertencia puede eliminarse editando manualmente el archivo .csproj para su proyecto.

modificar ........: Referencia Incluir = "System.Net.Http"

para leer ......: Referencia Incluir = "System.Net.Http, Versión = 4.0.0.0"

Use un lector de dependencia

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

Encontrar conjuntos 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 oscura línea de comando ejecuta dep.exe y luego canaliza la salida dos veces para awk a

• coloque el padre y el hijo en una sola columna (por defecto, cada línea contiene un padre y un hijo para expresar el hecho de que este padre depende de ese hijo)
• luego haga una especie de 'grupo por' usando una matriz asociativa

Comprender cómo esta asamblea se metió 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 tienes la opción entre

• convencer a los propietarios de las librerías para que usen la misma versión
• deja de usar uno de ellos
• Agregar redireccionamientos vinculantes en su archivo de configuración para usar la última versión

Cómo ejecutar estas cosas en Windows

Si usted no tiene un tipo de UNIX que tendrá que descargar uno antes de ser capaz de correr awky grep. Pruebe uno de los siguientes

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

También tuve este problema y utilicé el consejo de AMissico para descubrir el problema (aunque tuve que establecer el nivel de verbosidad en Detallado.

Sin embargo, el problema fue bastante sencillo 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 un par no se había cambiado automáticamente (System y System.Web.Services) y todavía estaban mirando 2.0.0.0. Crystal Reports hace referencia a 4.0.0.0, por lo que aquí es donde se producían los conflictos. Simplemente colocando el cursor en la primera biblioteca del Sistema en el explorador de soluciones, bajando el cursor por la lista y buscando referencias a 2.0.0.0, eliminando y volviendo a agregar la nueva versión 4.0.0.0 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 habría 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 el servidor web de mi casa: AsmSpyPlus.exe .

El código está disponible en: GitHub

Como se mencionó aquí , debe eliminar las referencias no utilizadas y las advertencias desaparecerán.

ASP.NET build manager está construyendo el sitio web revisando las carpetas alfabéticamente, y para cada carpeta calcula sus dependencias y construye las dependencias primero y luego la carpeta seleccionada.

En este caso, la carpeta problemática que es ~ / Controls, se selecciona para crearse al principio, por una razón aún desconocida, construye algunos de los controles allí como un ensamblaje separado en lugar de dentro del mismo ensamblaje que otros controles (parece que estar conectado al hecho de que algunos controles dependen de otros controles en la misma carpeta).

Luego, 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 vuelve a construir solo esta vez los controles que se separaron a su propio ensamblaje ahora se unen al mismo ensamblaje que otros controles con el ensamblado separado que todavía se hace referencia.

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

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

Arreglo rapido:

Haga clic derecho en la solución -> Administrar paquetes NuGet para la solución -> En Consolidar puede ver si se instalaron diferentes versiones del mismo paquete. Desinstale diferentes versiones e instale la última.

A veces AutoGenerateBindingRedirectsno es suficiente (incluso con GenerateBindingRedirectsOutputType). Buscar todas las There was a conflictentradas y corregirlas manualmente una por una puede ser tedioso, por lo que escribí un pequeño fragmento de código que analiza la salida del registro y las genera para usted (vuelca a stdout):

// Paste all "there was a conflict" lines from the msbuild diagnostics log to the file below
const string conflictFile = @"C:\AssemblyConflicts.txt";

var sb = new StringBuilder();
var conflictLines = await File.ReadAllLinesAsync(conflictFile);
foreach (var line in conflictLines.Where(l => !String.IsNullOrWhiteSpace(l)))
{
    Console.WriteLine("Processing line: {0}", line);

    var lineComponents = line.Split('"');
    if (lineComponents.Length < 2) 
        throw new FormatException("Unexpected conflict line component count");

    var assemblySegment = lineComponents[1];
    Console.WriteLine("Processing assembly segment: {0}", assemblySegment);
    var assemblyComponents = assemblySegment
                              .Split(",")
                              .Select(kv => kv.Trim())
                              .Select(kv => kv.Split("=")
                              .Last())
                              .ToArray();

    if (assemblyComponents.Length != 4) 
        throw new FormatException("Unexpected conflict segment component count");

    var assembly = assemblyComponents[0];
    var version = assemblyComponents[1];
    var culture = assemblyComponents[2];
    var publicKeyToken = assemblyComponents[3];

    Console.WriteLine("Generating assebmly redirect for Assembly={0}, Version={1}, Culture={2}, PublicKeyToken={3}", assembly, version, culture, publicKeyToken);
    sb.AppendLine($"<dependentAssembly><assemblyIdentity name=\"{assembly}\" publicKeyToken=\"{publicKeyToken}\" culture=\"{culture}\" /><bindingRedirect oldVersion=\"0.0.0.0-{version}\" newVersion=\"{version}\" /></dependentAssembly>");
}

Console.WriteLine("Generated assembly redirects:");
Console.WriteLine(sb);

Consejo: use MSBuild Binary and Structured Log Viewer y solo genere redireccionamientos vinculantes para los conflictos en el proyecto que emite la advertencia (es decir, solo pasa esas there was a conflictlíneas al archivo de texto de entrada para el código anterior [ AssemblyConflicts.txt]).

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

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 de este en la lista de todas las referencias disponibles. Seguí los procesos 1 a 6 anteriores y funcionó para mí.

Además de Visual Studio para Mac Community:

Como la respuesta de AMissico requiere cambiar el nivel de registro, y ni ASMSpy ni ASMSpyPlus están disponibles como una solución multiplataforma, aquí hay una pequeña 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

Si tiene un compartidor, elimine toda referencia no utilizada en su solución.