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

se encontraron conflictos entre diferentes versiones de microsoft.csharp que no se pudieron resolver (18)

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

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

Cuando limpio y luego compilo mi solución que tiene varios proyectos, la ventana de resultados informa que la compilación tuvo éxito. Sin embargo, cuando veo la ventana de 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 el nivel de detalle 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é es incorrecto y con qué DLL y cómo hago que desaparezca la advertencia?

Acabo de encontrar esto y el problema después de cambiar un paquete de nuget a dlls con referencias locales. El problema era cosas antiguas vinculantes de tiempo de ejecución en app.config .

Cambié la verbosidad de MSBuild a Diagnostic.but no pude encontrar dónde estaba el problema, de modo 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ó.

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. Go to Tools->Options menu in VS 2. Open Projects and Solutions->Build and Run 3. Change the value of the MSBuild project build output verbosity. Pick one from Quiet, Minimal, Normal, Detailed and Diagnostic

Verifique la ventana de salida (cntl + alt + o) en VS para los cambios en la construcción

Como se indica en el problema 6583 de la CLI de dotnet, el problema se debe resolver con el dotnet nuget locals --clear all

Descubrí que, a veces, los paquetes nuget se instalan (lo que supongo son) .NET Core requiere componentes u otros elementos que entren en conflicto con el marco ya instalado. Mi solución fue abrir el archivo de 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 algún paquete NuGet recientemente instalado. No hay ninguna razón para versiones específicas de esas 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, deshazte de ellos, y la construcció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 me funcionó :)

Ejemplo de lo que comenté:

   

Ejecutar el comando Update-Package través de la consola de Package Manager

Esto solucionará MSB3277, lo que hace es reinstalar todos los paquetes y todos los conjuntos relacionados que vienen con la versión más alta posible . También es posible actualizar solo el paquete específico. O bajar de categoría después de la actualización si se desea, este problema se solucionó varias veces. Dependiendo de cuántos paquetes de nuget tenga, este proceso puede demorar unos minutos.

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

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

Edición: También puede configurar la verbosidad de compilación directamente en VS2013. Vaya a Tools > Menú de Options , luego vaya a Projects and Solutions y establezca la verbosidad de MSBuild en Diagnostic .

Edit: Pocas aclaraciones ya que acabo de conseguir una. En mi caso, la advertencia se debió a que agregué una referencia utilizando el indicador Resharper en lugar del cuadro de diálogo Agregar referencia, que no tenía versión, aunque tanto v4 como v12 están disponibles para elegir.

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

<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 verbosidad /v:diag se parecía a lo siguiente. dando detalles que 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]

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

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

He desinstalado Microsoft ASP.NET MVC nuget.org de administrar NuGet Packagaes y lo he vuelto a instalar. Al reinstalarlo resolvió todos los conflictos relacionados con la versión de maquinilla de afeitar. Intentalo .

Mientras que las otras respuestas dicen esto, no lo hacen explícito, así que yo ...

En VS2013.2, para activar realmente la emisión de la información citada, no necesita 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 que está bien en una actualización actualizada de VS2015 3 o posterior). En su lugar, conviértalo en Diagnóstico (en Herramientas-> Opciones-> Proyecto y Soluciones-> Construir y Ejecutar , establezca el detalle de la 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, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" y "Newtonsoft.Json, Versión = 6.0.5.17707, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed".
"Newtonsoft.Json, Versión = 6.0.0.0, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" fue elegido porque era primario y "Newtonsoft.Json, Versión = 6.0.5.17707, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" no fue.

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 los detalles del mensaje [diagnóstico], fue una noticia para este ignorante que hay una convención en la ciudad donde todas las versiones 6.x son, internamente, la versión 6.0.0.0 la Asamblea, es decir, solo el SemVer El componente principal entra en la versión de ensamblaje :)

Obviamente, hay muchas causas diferentes y, por lo tanto, muchas soluciones para este problema. Para incluir el mío en la mezcla, actualizamos un ensamblaje (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.

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

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

Reiterando uno de los comentarios de @elshev 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 que se instaló. Actualizar los paquetes allí. El error de conflicto se resuelve.

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

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

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

Solo puedo admitir 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 el nivel de detalle del registro se establece en detallado .

Así que, Ruben tiene razón, esto simplemente no es cierto. No hay conflictos de ningún tipo, solo una asamblea que falta. 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 que se muestren 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 otra parte, si establece la verbosidad en Diagnóstico , obtendrá la siguiente salida:

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 ensamblaje "System.Web.Razor, Version = 3.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL". Asegúrese de que el ensamblaje existe en el disco. Si su código requiere esta referencia, puede obtener errores de compilación.

Como resultado, todo lo que necesita hacer es:

Agregue una referencia al ensamblaje manualmente (localícela en el disco, tal vez GAC, y agréguela como una referencia "directa"), o
Utilice 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 here . Más sobre precompilación de vistas ASP.NET here .