Avvertenza: sono stati rilevati conflitti tra versioni diverse dello stesso assembly dipendente

Attualmente sto sviluppando un'applicazione .NET, che comprende 20 progetti. Alcuni di questi progetti sono compilati usando .NET 3.5, altri sono ancora progetti .NET 2.0 (finora nessun problema).

Il problema è che se includo un componente esterno ricevo sempre il seguente avviso:

"Found conflicts between different versions of the same dependent assembly".

Cosa significa esattamente questo avviso e c'è forse la possibilità di escludere questo avviso (come usare #pragma disable nei file di codice sorgente)?

Questo avviso indica che due progetti fanno riferimento allo stesso assieme (ad es. System.Windows.Forms) Ma i due progetti richiedono versioni diverse. Hai alcune opzioni:

1. Ricompila tutti i progetti per utilizzare le stesse versioni (ad esempio, sposta tutto su .Net 3.5). Questa è l'opzione preferita perché tutto il codice è in esecuzione con le versioni delle dipendenze con cui sono state compilate.

2. Aggiungi un reindirizzamento vincolante . Questo eliminerà l'avvertimento. Tuttavia, i tuoi progetti .Net 2.0 saranno (in fase di esecuzione) associati alle versioni .Net 3.5 di assiemi dipendenti come System.Windows.Forms. È possibile aggiungere rapidamente un reindirizzamento di associazione facendo doppio clic sull'errore in Visual Studio.

3. Usa CopyLocal=true. Non sono sicuro se questo eliminerà l'avvertimento. Significherà, come l'opzione 2 sopra, che tutti i progetti useranno la versione .Net 3.5 di System.Windows.Forms.

Ecco un paio di modi per identificare i riferimenti offensivi:

• È possibile utilizzare un'utilità come quella disponibile su https://gist.github.com/1553265
• Un altro metodo semplice consiste nell'impostare la verbosità dell'output (Strumenti, Opzioni, Progetti e soluzioni, Build and Run, Compilazione dell'output della compilazione del progetto MSBuild, Informazioni dettagliate) e dopo la creazione, cercare l'avviso nella finestra di output e guardare il testo sopra di esso . (Punta del cappello a pauloya che lo ha suggerito nei commenti su questa risposta) .

Fondamentalmente ciò accade quando gli assembly a cui fai riferimento hanno "Copia locale" impostato su "Vero", il che significa che una copia della DLL viene inserita nella cartella bin insieme al tuo exe.

Poiché Visual Studio copierà anche tutte le dipendenze di un assembly a cui viene fatto riferimento, è possibile finire con due diverse build dello stesso assembly a cui si fa riferimento. Ciò è più probabile che accada se i tuoi progetti sono in soluzioni separate e possono quindi essere compilati separatamente.

Il modo in cui ci sono riuscito è impostare Copia locale su Falso per riferimenti nei progetti di assemblaggio. Fallo solo per eseguibili / applicazioni Web in cui è necessario eseguire l'assemblaggio per l'esecuzione del prodotto finito.

Spero che abbia un senso!

Volevo pubblicare la soluzione di pauloya che hanno fornito nei commenti sopra. Credo che sia la migliore soluzione per trovare i riferimenti offensivi.

Il modo più semplice per trovare quali sono i "riferimenti offensivi" è impostare la verbosità dell'output (strumenti, opzioni, progetti e soluzioni, Build and Run, verbosità dell'output del progetto MSBuild, dettagliata) e dopo la creazione, cercare nella finestra di output per l'avvertimento. Vedi il testo sopra di esso.

Ad esempio, quando cerchi "conflitti" nel pannello di output potresti trovare qualcosa del genere:

3>  There was a conflict between "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".
3>      "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it was primary and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was not.

Come puoi vedere, c'è un conflitto tra le versioni EF 5 e 6.

Ho avuto lo stesso problema con uno dei miei progetti, tuttavia nessuna delle precedenti ha aiutato a risolvere l'avvertimento. Ho controllato il file di registro di build dettagliato, ho usato AsmSpy per verificare di aver utilizzato le versioni corrette per ciascun progetto nella soluzione interessata, ho ricontrollato le voci effettive in ciascun file di progetto - nulla ha aiutato.

Alla fine si è scoperto che il problema era una dipendenza nidificata di uno dei riferimenti che avevo in un progetto. Questo riferimento (A) a sua volta richiedeva una versione diversa di (B) a cui faceva riferimento direttamente da tutti gli altri progetti nella mia soluzione. L'aggiornamento del riferimento nel progetto di riferimento lo ha risolto.

Solution A
+--Project A
   +--Reference A (version 1.1.0.0)
   +--Reference B
+--Project B
   +--Reference A (version 1.1.0.0)
   +--Reference B
   +--Reference C
+--Project C
   +--Reference X (this indirectly references Reference A, but with e.g. version 1.1.1.0)

Solution B
+--Project A
   +--Reference A (version 1.1.1.0)

Spero che quanto sopra mostri cosa intendo, ho impiegato un paio d'ore per scoprirlo, quindi spero che anche qualcun altro ne trarrà beneficio.

Su Visual Studio se fai clic con il pulsante destro del mouse sulla soluzione e gestisci i pacchetti nuget c'è una scheda "Consolida" che imposta tutti i pacchetti sulla stessa versione.

Ho appena ricevuto questo messaggio di avviso, pulito la soluzione e ricompilato (Build -> Clean Solution) ed è andato via.

Ho avuto lo stesso problema e ho risolto modificando quanto segue in web.config.

Mi è successo perché sto eseguendo l'applicazione utilizzando Newtonsoft.Json 4.0

A partire dal:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

Per:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

Ho un altro modo per farlo se stai usando Nuget per gestire le tue dipendenze. Ho scoperto che a volte VS e Nuget non coincidono e Nuget non è in grado di riconoscere che i tuoi progetti non sono sincronizzati. Packages.config dirà una cosa ma il percorso mostrato in Riferimenti - Proprietà indicherà qualcos'altro.

Se desideri aggiornare le tue dipendenze, procedi come segue:

1. Da Esplora soluzioni, fai clic con il pulsante destro del mouse sul progetto e fai clic su "Gestisci pacchetti Nuget"

2. Seleziona la scheda "Pacchetti installati" nel riquadro a sinistra Registra i pacchetti installati Potresti voler copiare prima i pacchetti Packages.config sul desktop se ne hai molti, quindi puoi fare un controllo incrociato con Google per vedere quali pacchetti Nuget sono installati

3. Disinstalla i tuoi pacchetti. Va bene, li aggiungeremo subito.

4. Installa immediatamente i pacchetti necessari. Ciò che Nuget farà non sarà solo procurarti l'ultima versione, ma modificherà i tuoi riferimenti e aggiungerà anche i reindirizzamenti vincolanti per te.

5. Fallo per tutti i tuoi progetti.

6. A livello di soluzione, eseguire una pulizia e ricostruzione.

Potresti voler iniziare con i progetti inferiori e arrivare a quelli di livello superiore e ricostruire ogni progetto mentre procedi.

Se non si desidera aggiornare le proprie dipendenze, è possibile utilizzare la console di gestione dei pacchetti e utilizzare la sintassi Update-Package -ProjectName [nomeProject] [nomepacchetto] -Versione [versionNumber]

Questo in realtà dipende dal tuo componente esterno. Quando si fa riferimento a un componente esterno in un'applicazione .NET, viene generato un GUID per identificare quel componente. Questo errore si verifica quando il componente esterno a cui fa riferimento uno dei tuoi progetti ha lo stesso nome e una versione diversa di un altro componente in un altro assieme.

Questo a volte accade quando si utilizza "Sfoglia" per trovare riferimenti e aggiungere una versione errata dell'assembly o si dispone di una versione diversa del componente nel repository di codici rispetto a quella installata nel computer locale.

Prova a trovare quali progetti hanno questi conflitti, rimuovi i componenti dall'elenco di riferimento, quindi aggiungili nuovamente assicurandoti di puntare allo stesso file.

=> controlla ci sarà qualche istanza dell'applicazione installata parzialmente.

=> prima di tutto disinstallare quell'istanza dall'applicazione di disinstallazione.

=> quindi, pulisci, ricostruisci e prova a distribuire.

questo ha risolto il mio problema. Spero che aiuti anche te. I migliori saluti.

Aveva anche questo problema - nel mio caso era causato dall'avere la proprietà "Versione specifica" su un numero di riferimenti impostato su true. Modificandolo in false su quei riferimenti, il problema è stato risolto.

Se usando NuGet tutto quello che dovevo fare era:

1. fare clic con il tasto destro del mouse sul progetto e fare clic su Gestisci pacchetti NuGet.

2. fai clic sull'ingranaggio in alto a destra

3. fare clic sulla scheda Generale in Gestione pacchetti NuGet sopra Fonti pacchetto

4. seleziona "Salta Applicazione di reindirizzamenti vincolanti" in Reindirizzamenti vincolanti

5. Pulito e ricostruito e l'avvertimento è sparito

Vai tranquillo

Ho appena passato un po 'di debug dello stesso problema. Si noti che il problema potrebbe non riguardare progetti diversi, ma in realtà tra più riferimenti in un progetto che dipendono da versioni diverse dello stesso dll / assembly. Nel mio caso, il problema era la FastMember.dllmancata corrispondenza delle versioni di riferimento che proviene da due diversi pacchetti NuGet in un singolo progetto. Quando mi è stato dato un progetto, non veniva compilato perché mancavano i pacchetti NuGet e VS si rifiutava di ripristinare i pacchetti mancanti. Attraverso il menu NuGet, aggiorno manualmente tutti i NuGet all'ultima versione, ovvero quando è apparso l'avviso.

In Visual Studio Tools > Options > Build and Run > MSBuld Project build output verbosity: (set to) Diagnostics.Cerca le linee There was a conflict betweennella Outputfinestra. Di seguito è la parte di output che ho ottenuto:

1>  There was a conflict between "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null". (TaskId:19)
1>      "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" was chosen because it was primary and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" was not. (TaskId:19)
1>      References which depend on "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" [C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll]. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll". (TaskId:19)
1>              FastMember, Version=1.5.0.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)
1>      References which depend on "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" []. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll". (TaskId:19)
1>              ClosedXML, Version=0.94.2.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)

Notare che Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll"

ClosedXML.dllproviene da ClosedXMLNuGet e dipende da FastMember.dll 1.3.0.0. Inoltre, FastMembernel progetto c'è anche Nuget FastMember.dll 1.5.0.0. Mancata corrispondenza !

Ho disinstallato ClosedXMLe FastMemberNuGets, perché avevo il reindirizzamento vincolante e ho installato solo l'ultima versione di ClosedXMLThat risolto il problema!

Questo è successo anche a me. Una dll è stata referenziata due volte: una volta direttamente (nei riferimenti) e una volta indirettamente (a cui fa riferimento un altro progetto referenziato). Ho rimosso la soluzione di riferimento diretto, pulita e ricostruita. Problema risolto.

1. Apri "Esplora soluzioni".
2. Fai clic su "Mostra tutti i file"
3. Espandi "Riferimenti"
4. Vedrai uno (o più) riferimenti con un'icona leggermente diversa rispetto al resto. In genere, è con una scatola gialla che ti suggerisce di prenderne nota. Basta rimuoverlo.
5. Aggiungi il riferimento indietro e compila il tuo codice.
6. È tutto.

Nel mio caso, si è verificato un problema con il riferimento MySQL. In qualche modo, potrei elencarne tre versioni nell'elenco di tutti i riferimenti disponibili; per .net 2.0, .net 4.0 e .net 4.5. Ho seguito il processo da 1 a 6 sopra e ha funzionato per me.

Un'altra cosa da considerare e verificare è, assicurarsi di non avere alcun servizio in esecuzione che utilizza quella cartella bin. se il loro è interrompere il servizio e ricostruire la soluzione

Sembra esserci un problema su Mac Visual Studio durante la modifica dei file .resx. Non so davvero cosa sia successo, ma ho riscontrato questo problema non appena ho modificato alcuni file .resx sul mio Mac. Ho aperto il progetto su Windows, aperto i file ed erano come se non fossero stati modificati. Quindi le ho modificate, salvate e tutto ha ripreso a funzionare anche su Mac.

Ho avuto un tale problema quando il mio progetto faceva riferimento a NETStandardLibrary e uno degli assiemi di riferimento è stato pubblicato per netcore. L'ho appena pubblicato come standard netto e il problema era sparito

Ecco la soluzione, stile .NET Core 3.0: https://github.com/HTD/ref-check

Quando trovi quali conflitti, forse sarai in grado di risolverli. Se i riferimenti in conflitto provengono da altri pacchetti, sei sfortunato o devi invece utilizzare fonti.

Nel mio caso, i pacchetti in conflitto sono spesso miei, quindi posso risolvere i problemi di dipendenza e ripubblicarli.