Se encontraron conflictos entre diferentes versiones del mismo ensamblado dependiente que no se pudieron resolver

Cuando limpio y luego compilo mi solución que tiene varios proyectos, la ventana de salida informa que la compilación se realizó correctamente. Sin embargo, cuando veo la ventana Lista de errores , me muestra esta advertencia:

Se encontraron conflictos entre diferentes versiones del mismo ensamblado dependiente que no se pudieron resolver. Estos conflictos de referencia se enumeran en el registro de compilación cuando la verbosidad del registro se establece en detallado. C: \ Archivos de programa (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets

Cuando hago doble clic en este mensaje, abre el archivo C: \ Archivos de programa (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets , pero no entiendo nada en él.

Estoy usando Visual Studio Express 2013 para la Web.

¿Cómo averiguo qué está mal y con qué DLL y cómo hago para que desaparezca la advertencia?

eta: Hay un artículo genial sobre este tema escrito por el propio @Nick Craver de SO que deberías leer

Si bien las otras respuestas dicen esto, no lo hacen explícito, así que lo haré ...

En VS2013.2, para activar realmente la emisión de la información citada, no es necesario leer el mensaje, que dice:

C: \ Archivos de programa (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): advertencia MSB3277: Se encontraron conflictos entre diferentes versiones del mismo ensamblado dependiente que no se pudieron resolver. Estos conflictos de referencia se enumeran en el registro de compilación cuando el nivel de detalle del registro se establece en detallado .

Esto es incorrecto (o al menos lo fue para algunas versiones de Visual Studio; parece estar bien en una actualización VS2015 Update 3 o posterior). En su lugar, conviértalo en Diagnóstico (desde Herramientas-> Opciones-> Proyecto y soluciones-> Construir y ejecutar , configure la verbosidad de salida de la compilación del proyecto MSBuild ), después de lo cual verá mensajes como:

Hubo un conflicto entre "Newtonsoft.Json, Version = 6.0.0.0, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" y "Newtonsoft.Json, Version = 6.0.5.17707, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed".

• Se eligió "Newtonsoft.Json, Version = 6.0.0.0, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" porque era principal y "Newtonsoft.Json, Version = 6.0.5.17707, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" no lo era.

Entonces

• Ctrl-Alt-O para ir a la ventana de salida de compilación
• buscar " fue elegido " para encontrar el desglose.

... Y sí, para aquellos que miran el detalle del mensaje [de diagnóstico], fue una novedad para este ignorante que hay una convención en la ciudad por la cual todas las 6.xversiones son, internamente, versión de ensamblaje 6.0.0.0, es decir, solo el componente SemVer Major entra en el ensamblaje Versión :)

Ejecute msbuild Foo.sln /t:Rebuild /v:diag(desde C:\Program Files (x86)\MSBuild\12.0\bin) para construir su solución desde la línea de comando y obtenga un poco más de detalles, luego busque el .csproj.que registra la advertencia y verifique sus referencias y referencias de otros proyectos que usan el mismo ensamblado común que difiere en la versión.

Editar: también puede configurar la verbosidad de la compilación directamente en VS2013. Vaya a Tools> Optionsmenú, luego vaya a Projects and Solutionsy configure la verbosidad de MSBuild en Diagnostic.

Editar: Pocas aclaraciones ya que acabo de recibir una. En mi caso, la advertencia se debió a que agregué una referencia usando el indicador Resharper en lugar del cuadro de diálogo Agregar referencia, que lo hizo sin versión a pesar de que tanto la v4 como la v12 están disponibles para elegir.

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework" />

vs

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework, Version=12.0.0.0, ..." />

En el registro de MSBuild con /v:diagverbosidad tenía el siguiente aspecto. dando detalles que dos referencias entraron en conflicto: -

  There was a conflict between 
  "Microsoft.Build.Framework, Version=4.0.0.0, ..." and 
  "Microsoft.Build.Framework, Version=12.0.0.0, ...". (TaskId:16)

      "Microsoft.Build.Framework, Version=4.0.0.0, ..." was chosen because it was primary and 
      "Microsoft.Build.Framework, Version=12.0.0.0, ..." was not. (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=4.0.0.0, ..." 
      [C:\...\v4.5.1\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v4.5.1\Microsoft.Build.Framework.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v4.5.1\Microsoft.Build.Framework.dll". (TaskId:16)
              Microsoft.Build.Framework (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=12.0.0.0, ..." 
      [C:\...\v12.0\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v12.0\Microsoft.Build.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

          C:\...\v12.0\Microsoft.Build.Engine.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.Engine.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3277: 
Found conflicts between different versions of the same dependent assembly that could not be resolved.  
These reference conflicts are listed in the build log when log verbosity is set to detailed. 
[C:\Users\Ilya.Kozhevnikov\Dropbox\BuildTree\BuildTree\BuildTree.csproj]

Solo puedo respaldar más la respuesta de Ruben con una comparación entre los dos mensajes que se muestran:

y el mensaje:

C: \ Archivos de programa (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): advertencia MSB3277: Se encontraron conflictos entre diferentes versiones del mismo ensamblado dependiente que no se pudieron resolver. Estos conflictos de referencia se enumeran en el registro de compilación cuando el nivel de detalle del registro se establece en detallado .

Entonces, Ruben tiene razón, esto simplemente no es cierto. No hay ningún conflicto, solo falta una asamblea. Esto es especialmente aburrido cuando el proyecto es una aplicación ASP.NET, ya que las vistas se compilan bajo demanda , es decir, justo antes de mostrarse por primera vez. Aquí es cuando se hace necesario tener disponible el ensamblaje. (Hay una opción para precompilar las vistas junto con el resto del código, pero esta es otra historia ). Por otro lado, si configuras la verbosidad en Diagnóstico , obtendrás el siguiente resultado:

C: \ Archivos de programa (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): advertencia MSB3245: No se pudo resolver esta referencia. No se pudo ubicar el ensamblado "System.Web.Razor, Version = 3.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL". Verifique para asegurarse de que el ensamblaje exista en el disco. Si su código requiere esta referencia, es posible que obtenga errores de compilación.

Como resultado, todo lo que necesita hacer es:

1. Agregue una referencia al ensamblaje manualmente (ubíquelo en el disco, tal vez GAC, y agréguelo como una referencia "directa"), o
2. Use el paquete NuGet (si está publicado en la galería) para descargarlo y hacer referencia al ensamblado que contiene.

Más sobre la galería NuGet aquí . Más información sobre la compilación previa de vistas ASP.NET aquí .

Cambiar la verbosidad de la compilación en Visual Studio ayudará a apuntar en la dirección correcta. Siga los pasos a continuación para cambiar la verbosidad en VS

1. Vaya al menú Herramientas-> Opciones en VS
2. Proyectos abiertos y soluciones-> Construir y ejecutar
3. Cambie el valor de la verbosidad de salida de la compilación del proyecto MSBuild. Escoja uno de Quiet, Minimal, Normal, DetailedyDiagnostic

Verifique la ventana de salida ( Ctrl+ Alt+ O) en VS para ver los cambios en el registro de compilación.

Reiterando uno de los comentarios de @elshev Haga clic con el botón derecho en la solución -> Administrar paquetes NuGet para la solución -> En Consolidar puede ver si hay diferentes versiones del mismo paquete que se instaló. Actualice los paquetes allí. Se resuelve el error de conflicto.

y ¿cómo hago para que desaparezca la advertencia?

Probablemente tendrá que reinstalar o actualizar sus paquetes NuGet para solucionar este problema.

Como se indica en el número 6583 de la CLI de dotnet, el problema debe resolverse con el dotnet nuget locals --clear allcomando.

Estoy usando Visual Studio 2017 y encontré esto cuando actualicé algunos paquetes de Nuget. Lo que funcionó para mí fue abrir mi web.configarchivo y encontrar el <runtime><assemblyBinding>nodo y eliminarlo. Guarde web.configy reconstruya el proyecto.

Mira la Error Listventana. Verá lo que parece una advertencia enormemente larga sobre conflictos vinculantes. Haga doble clic en él y automáticamente volverá a crear el <runtime><assemblyBinding>bloque con las asignaciones correctas.

Podría resolver esto instalando Newtonsoft Json en el proyecto web con paquetes nugget

Obviamente, hay muchas causas diferentes y, por lo tanto, muchas soluciones para este problema. Para incluir el mío en la mezcla, actualizamos un ensamblado (System.Net.Http) al que anteriormente se hacía referencia directamente en nuestro proyecto web a una versión administrada por NuGet. Esto eliminó la referencia directa dentro de ese proyecto, pero nuestro proyecto de prueba aún contenía la referencia directa. La actualización de ambos proyectos para usar el ensamblado administrado por NuGet resolvió el problema.

Si realizó algún cambio en los paquetes, vuelva a abrir el archivo sln. ¡Esto funcionó para mí!

Puede ejecutar la CLI de Dotnet con una verbosidad de diagnóstico completa para ayudar a encontrar el problema.

dotnet run --verbosity diagnostic >> full_build.log

Una vez que se completa la compilación, puede buscar el error en el archivo de registro (full_build.log). La búsqueda de "un conflicto", por ejemplo, debería llevarle directamente al problema.

Descubrí que, a veces, los paquetes nuget se instalarán (lo que supongo que son) los componentes necesarios de .NET Core u otros elementos que entran en conflicto con el marco ya instalado. Mi solución fue abrir el archivo del proyecto (.csproj) y eliminar esas referencias. Por ejemplo, System.IO, System.Threading y demás, tienden a agregarse cuando Microsoft.Bcl se incluye a través de algún paquete NuGet recientemente instalado. No hay ninguna razón para versiones específicas de esos en mis proyectos, así que elimino las referencias y el proyecto se construye. Espero que ayude.

Puede buscar su archivo de proyecto para "referencia" y eliminar los conflictos. Si están incluidos en el sistema, elimínelos y la compilación debería funcionar. Es posible que esto no responda a todos los casos de este problema; me aseguro de que sepa lo que funcionó para mí :)

Ejemplo de lo que comenté:

<!-- <Reference Include="System.Runtime, Version=2.6.9.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"> -->
  <!-- <HintPath>$(SolutionDir)packages\Microsoft.Bcl.1.1.9\lib\net40\System.Runtime.dll</HintPath> -->
  <!-- <Private>True</Private> -->
<!-- </Reference> -->

Me encontré con esto y el problema después de cambiar un paquete de nuget a dlls referenciados localmente. El problema era el antiguo material vinculante en tiempo de ejecución app.config.

Seguí el consejo de varias de las respuestas aquí para averiguar qué estaba mal, pero ninguna de las respuestas parecía explicar cómo solucionarlo. Mi problema fue que una referencia requería una versión diferente de una segunda referencia. Entonces Newtonsoft estaba en la versión 6, pero alguna otra DLL quería 4.5. Luego actualicé Newtonsoft como sugirió una de las otras respuestas y eso empeoró las cosas.

Entonces, de hecho, degradé mi instalación de Newtonsoft y la advertencia desapareció (VS 2017):

Haga clic con el botón derecho en Referencias en el explorador de soluciones y seleccione Administrar paquetes NuGet ... En la pestaña "Instalado", busque Newtonsoft (o cualquiera que sea su conflicto) En el lado derecho, aparece un menú desplegable junto a "Versión" que puede cambiar a más antiguo Versiones No era obvio para mí que este menú desplegable pudiera usarse para degradar.

Tenga en cuenta que resolví este problema colocando el AutoGenerateBindingRedirectsderecho después del TargetFrameworken el csprojarchivo:

<TargetFramework>net462</TargetFramework>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>

Desinstalé Microsoft ASP.NET MVC nuget.org de Manage NuGet Packagaes y lo volví a instalar. Al reinstalar, resolvió todos los conflictos relacionados con la versión de la maquinilla de afeitar. Intentalo .

Cambié la verbosidad de MSBuild a Diagnostic. Pero no pude encontrar dónde estaba el problema, así que de acuerdo con las respuestas anteriores, tenía este código en app.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
<sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="XbimXplorer.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
</sectionGroup>
</configSections>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>

Así que acabo de cambiar el primer sistema, versión de 4.0.0.0 a 12.0.0.0 y mi proyecto funcionó.

Según las otras respuestas, configure el nivel de registro de salida en detallado y busque allí los conflictos, que le indicarán dónde buscar a continuación.

En mi caso, me envió en varias direcciones buscando la fuente de las referencias, pero al final resultó que el problema era uno de mis proyectos de biblioteca de clases portátiles, apuntaba a la versión incorrecta y estaba sacando la suya propia. versión de las referencias en, de ahí los conflictos. Una rápida reorientación y el problema se resolvió.

Recibí esta advertencia después de migrar a Package Reference. En la salida de diagnóstico había información de que la biblioteca estaba referenciada por la misma biblioteca. Puede ser un error de la nueva referencia de paquete. La solución fue habilitar AutoGenerateBindingRedirects y eliminar la redirección de enlace personalizado.

VS 2017, proyecto MVC

No sé por qué, pero para mí, la solución para este problema fue eliminar un outparámetro de una firma de método de modelo que se llamó desde el método de acción del controlador. ese es un comportamiento muy extraño pero esa fue la solución a mi problema.