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 resultados 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 detallada. 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 asesino sobre estas cosas 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 la emisión de la información citada, no debe 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 la verbosidad del registro se establece en detallada .

Esto es incorrecto (o al menos lo fue para algunas versiones de Visual Studio; parece estar bien en una actualización actualizada de VS2015 3 o posterior). En lugar de eso, diríjalo a Diagnóstico (desde Herramientas-> Opciones-> Proyecto y Soluciones-> Compilar y Ejecutar , establezca la verbosidad de salida de compilación del proyecto MSBuild ), con lo cual verá mensajes como:

Hubo un conflicto entre "Newtonsoft.Json, Versión = 6.0.0.0, Cultura = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" y "Newtonsoft.Json, Versión = 6.0.5.17707, Cultura = neutral, PublicKeyToken = 30ad4fe6b2a6aeed".

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

Entonces

• Ctrl-Alt-O para ir a la ventana de salida de Build
• busque " fue elegido " para encontrar el desglose.

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

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 comandos y obtenga un poco más de detalles, luego encuentre el .csproj.que registra la advertencia y verifique sus referencias y referencias de otros proyectos que usan el mismo ensamblaje común que difiere en la versión.

Editar: también puede establecer la verbosidad de compilación directamente en VS2013. Vaya al menú Tools> Optionsluego vaya Projects and Solutionsy configure MSBuild verbosity en Diagnostic.

Editar: Pocas aclaraciones ya que acabo de recibir una yo mismo. 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 no tenía versión a pesar de que tanto v4 como 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, se parecía a lo siguiente. dando detalles con dos referencias 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 soportar más la respuesta de Ruben con una comparación entre los dos mensajes mostrados:

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 la verbosidad del registro se establece en detallada .

Entonces, Ruben tiene razón, esto simplemente no es cierto. No hay conflictos de ningún tipo, solo falta una asamblea. Esto es especialmente aburrido cuando el proyecto es una aplicación ASP.NET, ya que las vistas se compilan a pedido , es decir, justo antes de mostrarse por primera vez. Esto es cuando se hace necesario tener el ensamblaje disponible. (Hay una opción para precompilar las vistas junto con el resto del código, pero esta es otra historia ). Por otro lado, si configura la verbosidad en Diagnóstico , obtendrá 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 que el ensamblaje exista en el disco. Si su código requiere esta referencia, puede obtener 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 referencia "directa"), o
2. Use el paquete NuGet (si está publicado en la galería) para descargarlo y hacer referencia al ensamblaje que contiene.

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

Cambiar la verbosidad de 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 y soluciones abiertos-> Construir y ejecutar
3. Cambie el valor de la verbosidad de salida de 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.

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

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

Reiterando uno de los comentarios de @elshev 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. Actualiza los paquetes allí. El error de conflicto está resuelto.

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

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

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

Obviamente, hay muchas causas diferentes y, por lo tanto, muchas soluciones para este problema. Para agregar el mío a la mezcla, actualizamos un ensamblaje (System.Net.Http) al que se hizo 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 todavía 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 sln. ¡Esto funcionó para mí!

Descubrí que, a veces, los paquetes nuget se instalarán (lo que supongo que son) .NET Core requiere componentes 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 similares, tienden a agregarse cuando se incluye Microsoft.Bcl a través de un paquete NuGet recientemente instalado. No hay razón para versiones específicas de esos en mis proyectos, así que elimino las referencias y las compilaciones del proyecto. Espero que ayude.

Puede buscar "referencia" en su archivo de proyecto 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 estoy asegurando 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> -->

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

Así que en realidad bajé 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 anterior versiones. No era obvio para mí que este menú desplegable pudiera usarse para rebajar.

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 en el archivo de registro (full_build.log) el error. Buscar "un conflicto", por ejemplo, debería llevarlo directamente al problema.

Desinstalé Microsoft ASP.NET MVC nuget.org de administrar NuGet Packagaes y lo reinstalé nuevamente. Al volver a instalarlo, resolvió todos los conflictos relacionados con la versión de afeitar. Intentalo .

Cambié la verbosidad de MSBuild a Diagnóstico, pero no pude encontrar dónde estaba el problema, así que de acuerdo con las respuestas anteriores, tuve 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, establezca el nivel de registro de salida en detallado y busque conflictos allí, que le indicarán dónde buscar a continuación.

En mi caso, me envió en algunas direcciones buscando la fuente de las referencias, pero al final resultó que el problema era uno de mis proyectos de biblioteca de clase portátil, estaba apuntando a la versión incorrecta y estaba sacando la suya. versión de las referencias en, de ahí los conflictos. Un rápido re-objetivo y el problema fue resuelto.

Acabo de encontrar esto y el problema después de cambiar un paquete de nuget a dlls referenciados localmente. La cuestión era vieja materia obligatoria en tiempo de ejecución app.config.

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

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

Ejecutar Update-Packagecomando a través de la consola del Administrador de paquetes

Esto solucionará MSB3277, lo que hace es reinstalar todos los paquetes y todos los ensamblados relacionados con la versión más alta posible . También es posible actualizar solo un paquete específico. O rebaje después de la actualización si lo desea, este problema solucionado para mí pocas veces surgió. Dependiendo de cuántos paquetes nuget tenga, este proceso puede demorar unos minutos.

Más información sobre documentos oficiales https://docs.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages