Sono stati rilevati conflitti tra versioni diverse dello stesso assembly dipendente che non è stato possibile risolvere

Quando pulisco e quindi costruisco la mia soluzione con diversi progetti, la finestra di output indica che la compilazione è riuscita. Tuttavia, quando visualizzo la finestra Elenco errori , viene visualizzato questo avviso:

Sono stati rilevati conflitti tra versioni diverse dello stesso assembly dipendente che non è stato possibile risolvere. Questi conflitti di riferimento sono elencati nel registro di build quando la verbosità del registro è impostata su dettagliata. C: \ Programmi (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets

Quando faccio doppio clic su questo messaggio, viene aperto il file C: \ Programmi (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets ma non capisco nulla al suo interno.

Sto usando Visual Studio Express 2013 per il Web.

Come faccio a sapere cosa c'è che non va e con quale DLL e come faccio a far scomparire l'avviso?

eta: C'è un articolo killer su questa roba di @Nick Craver di SO che dovresti leggere

Mentre le altre risposte dicono questo, non lo rendono esplicito, quindi lo farò ....

Su VS2013.2, per attivare effettivamente l'emissione delle informazioni citate, non è necessario leggere il messaggio, che dice:

C: \ Programmi (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): avviso MSB3277: trovati conflitti tra versioni diverse dello stesso assembly dipendente che non è stato possibile risolvere. Questi conflitti di riferimento sono elencati nel registro di build quando la verbosità del registro è impostata su dettagliata .

Questo non è corretto (o almeno lo era per alcune versioni di Visual Studio - sembra essere OK su un aggiornamento VS2015 aggiornato 3 o successivo). Invece trasformalo in Diagnostica (da Strumenti-> Opzioni-> Progetto e soluzioni-> Crea ed esegui , imposta la verbosità dell'output di compilazione del progetto MSBuild ), dopodiché vedrai messaggi come:

Si è verificato un conflitto tra "Newtonsoft.Json, Version = 6.0.0.0, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" e "Newtonsoft.Json, Version = 6.0.5.17707, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed".

• "Newtonsoft.Json, Version = 6.0.0.0, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" è stato scelto perché era primario e "Newtonsoft.Json, Version = 6.0.5.17707, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" non lo era.

Poi

• Ctrl-Alt-O per andare alla finestra Crea output
• cerca "è stato scelto " per trovare il drilldown.

... E sì, per coloro che stanno guardando i dettagli del messaggio [diagnostico], è stata una novità per questo ignorante che ci sia una convenzione in città in base alla quale tutte le 6.xversioni sono, internamente, la versione dell'Assemblea 6.0.0.0, cioè solo il componente SemVer Major entra nell'Assemblea Versione :)

Eseguire msbuild Foo.sln /t:Rebuild /v:diag(da C:\Program Files (x86)\MSBuild\12.0\bin) per creare la soluzione dalla riga di comando e ottenere un po 'più di dettagli, quindi trovare quello .csproj.che registra l'avviso e controllare i suoi riferimenti e riferimenti di altri progetti che utilizzano lo stesso assembly comune che differisce nella versione.

Modifica: puoi anche impostare la verbosità di compilazione direttamente in VS2013. Vai a Tools> Optionsmenu quindi vai a Projects and Solutionse imposta la verbosità di MSBuild su Diagnostic.

Modifica: pochi chiarimenti appena ne ho preso uno da solo. Nel mio caso l'avvertimento è dovuto al fatto che ho aggiunto un riferimento usando il prompt di Resharper invece della finestra di dialogo Aggiungi riferimento, che lo ha reso privo di versione anche se sia la v4 che la v12 sono disponibili tra cui scegliere.

<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, ..." />

Nel registro di MSBuild con /v:diagverbosità sembrava il seguente. fornendo dettagli su cui due riferimenti erano in conflitto: -

  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]

Posso solo supportare ulteriormente la risposta di Ruben con un confronto tra i due messaggi visualizzati:

e il messaggio:

C: \ Programmi (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): avviso MSB3277: trovati conflitti tra versioni diverse dello stesso assembly dipendente che non è stato possibile risolvere. Questi conflitti di riferimento sono elencati nel registro di build quando la verbosità del registro è impostata su dettagliata .

Quindi, Ruben ha ragione: questo non è vero. Non ci sono conflitti di alcun tipo, solo un'assemblea mancante. Ciò è particolarmente noioso quando il progetto è un'applicazione ASP.NET, poiché le viste sono compilate su richiesta , ovvero appena prima visualizzate per la prima volta. Questo è quando diventa necessario avere l'assemblaggio disponibile. (C'è un'opzione per precompilare le viste insieme al resto del codice, ma questa è un'altra storia .) D'altra parte, se imposti la verbosità su Diagnostica otterrai il seguente output:

C: \ Programmi (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): avviso MSB3245: Impossibile risolvere questo riferimento. Impossibile trovare l'assembly "System.Web.Razor, Version = 3.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL". Verificare che l'assembly esista sul disco. Se questo riferimento è richiesto dal tuo codice, potresti ricevere errori di compilazione.

Di conseguenza, tutto ciò che devi fare è:

1. Aggiungere manualmente un riferimento all'assembly (individuarlo su disco, magari GAC, e aggiungerlo come riferimento "diretto"), oppure
2. Utilizzare il pacchetto NuGet (se pubblicato nella galleria) per scaricarlo e fare riferimento all'assembly contenuto al suo interno.

Maggiori informazioni sulla galleria NuGet qui . Maggiori informazioni sulla precompilazione delle viste ASP.NET qui .

Cambiare la verbosità di compilazione in Visual Studio aiuterà a puntare nella giusta direzione. Seguire i passaggi seguenti per modificare la verbosità in VS

1. Vai su Strumenti-> menu Opzioni in VS
2. Apri progetti e soluzioni-> Crea ed esegui
3. Modificare il valore della verbosità dell'output di compilazione del progetto MSBuild. Sceglietene uno da Quiet, Minimal, Normal, DetailedeDiagnostic

Controllare la finestra di output ( Ctrl+ Alt+ O) in VS per vedere le modifiche nel registro di build.

e come faccio a far scomparire l'avviso?

Probabilmente dovrai reinstallare o aggiornare i tuoi pacchetti NuGet per risolvere questo problema.

Ribadendo uno dei commenti di @elshev Fare clic con il tasto destro del mouse sulla soluzione -> Gestisci pacchetti NuGet per soluzione -> In Consolidato è possibile vedere se sono state installate versioni diverse dello stesso pacchetto. Aggiorna i pacchetti lì. L'errore di conflitto è stato risolto.

Sto usando Visual Studio 2017 e ho riscontrato questo quando ho aggiornato alcuni pacchetti Nuget. Ciò che ha funzionato per me è stato aprire il mio web.configfile e trovare il <runtime><assemblyBinding>nodo ed eliminarlo. Salva web.confige ricostruisci il progetto.

Guarda la Error Listfinestra Vedrai quello che sembra un avvertimento di lunga durata sui conflitti vincolanti. Fare doppio clic su di esso per ricreare automaticamente il <runtime><assemblyBinding>blocco con i mapping corretti.

Come indicato nel numero 6583 della CLI della dotnet, il problema dovrebbe essere risolto con il dotnet nuget locals --clear allcomando.

Ho potuto risolvere l'installazione di Newtonsoft Json nel progetto Web con pacchetti nugget

Ovviamente ci sono molte cause diverse e quindi molte soluzioni per questo problema. Per aggiungere il mio al mix, abbiamo aggiornato un assembly (System.Net.Http) che in precedenza era stato direttamente referenziato nel nostro progetto Web a una versione gestita da NuGet. Ciò ha rimosso il riferimento diretto all'interno di quel progetto, ma il nostro progetto Test conteneva ancora il riferimento diretto. L'aggiornamento di entrambi i progetti per l'utilizzo dell'assembly gestito da NuGet ha risolto il problema.

Se hai apportato modifiche ai pacchetti, riapri lo sln. Questo ha funzionato per me!

Ho scoperto che, a volte, i pacchetti nuget installeranno (quello che suppongo siano) componenti richiesti da .NET Core o altri elementi in conflitto con il framework già installato. La mia soluzione era quella di aprire il file di progetto (.csproj) e rimuovere quei riferimenti. Ad esempio, System.IO, System.Threading e simili, tendono ad essere aggiunti quando Microsoft.Bcl è incluso tramite alcuni pacchetti NuGet installati di recente. Non c'è motivo per versioni specifiche di quelle nei miei progetti, quindi rimuovo i riferimenti e le build del progetto. Spero che aiuti.

È possibile cercare "riferimento" nel file di progetto e rimuovere i conflitti. Se sono inclusi nel sistema, eliminali e la build dovrebbe funzionare. Questo potrebbe non rispondere a tutti i casi di questo problema - mi assicuro che tu sappia cosa ha funzionato per me :)

Esempio di ciò che ho commentato:

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

Ho seguito il consiglio di alcune delle risposte qui per capire cosa c'era di sbagliato, ma nessuna delle risposte sembrava spiegare come risolverlo. Il mio problema era che un riferimento richiedeva una versione diversa di un secondo riferimento. Quindi Newtonsoft era alla versione 6, ma alcune altre DLL volevano 4.5. Quindi ho aggiornato Newtonsoft come suggerito da una delle altre risposte e ciò ha peggiorato le cose.

Quindi ho effettivamente declassato la mia installazione di Newtonsoft e l'avviso è andato via (VS 2017):

Fai clic con il pulsante destro del mouse su Esplora soluzioni e seleziona Gestisci pacchetti NuGet ... Nella scheda "Installato", trova Newtonsoft (o qualunque sia il tuo conflitto) Sul lato destro, accanto a "Versione" viene visualizzato un menu a discesa che puoi modificare in versioni precedenti versioni. Non era ovvio per me che questo menu a discesa potesse essere utilizzato per il downgrade.

È possibile eseguire l'interfaccia della riga di comando Dotnet con la massima precisione diagnostica per aiutare a trovare il problema.

dotnet run --verbosity diagnostic >> full_build.log

Una volta completata la compilazione, è possibile cercare l'errore nel file di registro (full_build.log). La ricerca di "un conflitto", ad esempio, dovrebbe portarti direttamente al problema.

Ho disinstallato Microsoft ASP.NET MVC nuget.org dalla gestione di NuGet Packagaes e l'ho reinstallato di nuovo. Durante la reinstallazione ha risolto tutti i conflitti relativi alla versione del rasoio. Provalo .

Ho cambiato la verbosità di MSBuild in Diagnostic.ma non sono riuscito a trovare dove fosse il problema, quindi in base alle risposte sopra ho avuto questo codice in 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>

Quindi ho appena cambiato il primo sistema, versione da 4.0.0.0 a 12.0.0.0 e il mio progetto ha funzionato.

Come per le altre risposte, imposta il livello di registrazione dell'output su dettagliato e cerca lì i conflitti, che ti diranno dove cercare dopo.

Nel mio caso, mi ha spinto in alcune direzioni alla ricerca della fonte dei riferimenti, ma alla fine si è scoperto che il problema era uno dei miei progetti di librerie di classe portatili, stava prendendo di mira la versione sbagliata e stava tirando fuori la sua versione dei riferimenti in, quindi i conflitti. Un rapido re-target e il problema è stato risolto.

Mi sono appena imbattuto in questo e nel problema dopo aver passato un pacchetto da nuget a DLL di riferimento locale. Il problema riguardava i vecchi elementi di binding di runtime in app.config.

Ho ricevuto questo avviso dopo la migrazione a Riferimento pacchetto. Nell'output diagnostico c'erano informazioni che la libreria faceva riferimento alla stessa libreria stessa. Potrebbe essere un bug del nuovo riferimento al pacchetto. La soluzione era abilitare AutoGenerateBindingRedirects ed eliminare il reindirizzamento dell'associazione personalizzato.

VS 2017, progetto MVC

Non so perché, ma per me la soluzione a questo problema è stata quella di rimuovere un outparametro da una firma del metodo modello chiamata dal metodo di azione del controller. è un comportamento molto strano ma questa è stata la soluzione al mio problema.

Esegui Update-Packagecomando tramite la console di Package Manager

Questo risolverà MSB3277, cosa fa reinstallando tutti i pacchetti e tutti i relativi assemblaggi che arrivano con la versione più alta possibile . È anche possibile aggiornare solo un pacchetto specifico. Oppure, se lo desideri, esegui il downgrade dopo l'aggiornamento, questo problema risolto per me poche volte è emerso. A seconda di quanti pacchetti nuget hai, questo processo potrebbe richiedere alcuni minuti.

Maggiori informazioni sui documenti ufficiali https://docs.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages