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


372

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?



Respuestas:


513

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


3
Gracias: he estado usando Visual Studio durante muchos años y nunca tuve un problema que requiriera profundizar tanto en el registro de compilación. Problema diferente, pero al darme cuenta de que la información que estaba buscando se estaba emitiendo en alguna parte resolvió mi problema.
Timothy Lee Russell

44
El nivel de registro detallado parece funcionar dentro de VS (por lo que no se requiere diagnóstico). Sin embargo, no sería la primera vez que MSBuild se comporta de manera diferente dentro de VS ...
Johannes Rudolph

105
Para cambiar la verbosidad del registro desde el menú Herramientas-> Opciones, busque Proyecto y Soluciones-> Compilar y ejecutar
Jenn

3
En mi caso, tuve tres conflictos y uno de ellos fue responsable de los otros dos. Copié mi registro de compilación "detallado" en el Bloc de notas, busqué "conflicto", actualicé el paquete NuGet para la referencia que reconocí y el problema se resolvió.
Isaac Lyman

@robotnik Gracias por la sugerencia de edición [que fue negada por otros]. De hecho, había incluido la información en la parte inferior de la respuesta, pero espero que la respuesta como está ahora sea tan clara como pretendía.
Ruben Bartelink

76

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]

10
Terminé canalizando ese comando a un archivo de registro, para poder msbuild "Foo.sln" /t:Rebuild /v:d > build.log
revisarlo

2
La mejor manera de llegar al terminal para esto: stackoverflow.com/a/22702405/268066
CrazyPyro

@CrazyPyro msbuild tiene una tubería "incorporada" - /l:FileLogger,Microsoft.Build.Engine;logfile=build.log- tenga en cuenta los interruptores para la explicación de los registradores aquí
drzaus

3
¿Dónde se encuentra el "registro de compilación"? ¿Cómo lo encuentro?
Prisionero CERO

Esta respuesta muestra cómo obtener más detalles de msbuild, que es lo que le importa a un usuario mono. Todas las demás respuestas suponen que está utilizando VS y se está ejecutando en un entorno Windows.
Incondicionalmente

39

Solo puedo soportar más la respuesta de Ruben con una comparación entre los dos mensajes mostrados:

ingrese la descripción de la imagen aquí

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


En VS 2017, cuando configuré el "nivel de detalle de salida de compilación del proyecto MSBuild" (no el archivo de registro) en Detallado (no diagnóstico), obtuve el error "No se pudo ubicar el ensamblado" en mi ventana de Salida.
ALEXintlsos

@ALEXintlsos: aparentemente esta funcionalidad ha cambiado; aún tiene el error donde sea que esté; siga las instrucciones para deshacerse de él.
Alexander Christov

22

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.


16

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

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


2
Esto, con una combinación de reiniciar Visual Studio cuando se negó a reinstalar un paquete correctamente, resolvió el problema para mí.
Ohad Schneider

22
La forma más sencilla de verificar: haga clic con el botón derecho en la solución -> Manage NuGet packages for solution-> Debajo Consolidatepuede ver si se instalaron diferentes versiones del mismo paquete
elshev

16

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.


1
Esto no me resolvió. Tuve que desinstalar Newtonsoft.JSON y reinstalar a través de NuGet. Esta dependencias actualizadas en los otros paquetes.
Garr Godfrey

Esto también me sucedió al usar herramientas como Resharper, que agrega automáticamente referencias faltantes de DLL. "Agregar siempre usando nuget" podría ser una buena sugerencia aquí.
Shaswat Rungta

No funciona para mí porque al desinstalar un paquete intenta una compilación que no puede suceder porque hay un conflicto de paquetes. Así que ni siquiera puedo volver a instalar el paquete :(
nickornotto

8

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.



3

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


3

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.


2

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


1

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


1

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.


1

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.


0

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 .


0

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


0

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.


0

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.


0

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.


0

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.


-2

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


14
Este consejo puede arruinar su día si no desea los paquetes más recientes, que a menudo es el caso del código de producción.
Tony O'Hagan

1
Esto se indica en el consejo y lo que podría ser un problema para usted, es una forma segura y fácil de solucionar un problema, así que por favor no desestime a las personas en su propia opinión.
Aistis Taraskevicius

1
Esta solución no me funcionó. Ya tenía todas las últimas versiones.
Zero3

@ Zero3 lo ha ejecutado desde su solución principal, sin especificar ningún paquete directamente, por lo general funciona, porque reinstala cada uno y actualiza las referencias, que es lo que causa errores
Aistis Taraskevicius

3
Este es un consejo realmente terrible. No es opinión, la actualización de paquetes rompe el código si no se hace con intención.
TheBatman
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.