Avviso: trovati conflitti tra diverse versioni dello stesso assembly dipendente

Attualmente sto sviluppando un’applicazione .NET, che consiste in 20 progetti. Alcuni di questi progetti sono compilati utilizzando .NET 3.5, altri ancora sono progetti .NET 2.0 (finora nessun problema).

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

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

Che cosa significa esattamente questo avviso e c’è forse la possibilità di escludere questo avviso (come l’uso della disabilitazione #pragma nei file del codice sorgente)?

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

  1. Ricompila tutti i progetti per utilizzare le stesse versioni (es. Sposta tutto in .Net 3.5). Questa è l’opzione preferita perché tutto il codice è in esecuzione con le versioni delle dipendenze con cui sono stati compilati.

  2. Aggiungi un reindirizzamento obbligatorio . Questo sopprimerà l’avvertimento. Tuttavia, i tuoi progetti .Net 2.0 saranno (in fase di esecuzione) vincolati alle versioni .Net 3.5 di assembly dipendenti come System.Windows.Forms . È ansible aggiungere rapidamente un reindirizzamento dell’associazione facendo doppio clic sull’errore in Visual Studio.

  3. Usa CopyLocal=true . Non sono sicuro se questo sopprimerà l’avvertimento. Come l’opzione 2 sopra, significa che tutti i progetti useranno la versione 3.5 di Net.Windows.Forms.

Ecco un paio di modi per identificare i riferimenti incriminati:

  • È ansible utilizzare un’utilità come quella disponibile su https://gist.github.com/1553265
  • Un altro metodo semplice consiste nel impostare la verbosità di output di Build (Strumenti, Opzioni, Progetti e soluzioni, Build ed Esegui, verbosità di output del build del progetto MSBuild, Detailed) e dopo la costruzione, cercare la finestra di output per l’avviso e guardare il testo appena sopra . (Un consiglio a pauloya che lo ha suggerito nei commenti su questa risposta) .

Fondamentalmente ciò accade quando gli assembly a cui si fa riferimento hanno “Copy Local” impostato su “True”, ovvero una copia della DLL viene collocata nella cartella bin insieme al proprio exe.

Dal momento che Visual Studio copierà anche tutte le dipendenze di un assembly referenziato, è ansible finire con due differenti build dello stesso assembly a cui si fa riferimento. Questo è più probabile che accada se i progetti sono in soluzioni separate e possono quindi essere compilati separatamente.

Il modo in cui mi sono aggirato è impostare Copy Local su False per i 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 senso!

Volevo pubblicare la soluzione di pauloya fornita nei commenti sopra. Credo che sia la soluzione migliore per trovare i riferimenti incriminati.

Il modo più semplice per trovare quali sono i “riferimenti offensivi” è impostare la verbosità di output di Build (Strumenti, Opzioni, Progetti e Soluzioni, Build ed Esegui, verbosità di output del build del progetto MSBuild, Detailed) e dopo la costruzione, cercare nella finestra di output per l’avvertimento. Guarda il testo appena sopra di esso.

Ad esempio, quando si cerca “conflitto” nel pannello di output, si può trovare qualcosa di simile a questo:

 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, nessuno dei precedenti ha aiutato a risolvere l’avvertimento. Ho controllato il file di log di build dettagliato, ho usato AsmSpy per verificare che ho usato le versioni corrette per ogni progetto nella soluzione interessata, ho controllato le voci effettive in ogni file di progetto – niente di utile.

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 si 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 eg version 1.1.1.0) Solution B +--Project A +--Reference A (version 1.1.1.0) 

Spero che quanto sopra mostra cosa intendo, mi ci sono volute un paio d’ore per scoprirlo, quindi spero che anche qualcun altro ne trarrà beneficio.

Ho appena ricevuto questo messaggio di avviso e ho pulito la soluzione e ricompilata (Build -> Clean Solution) e se ne è andato.

Su Visual Studio se si fa clic con il tasto destro sulla soluzione e si gestiscono i pacchetti di nuget, esiste una scheda “Consolida” che imposta tutti i pacchetti sulla stessa versione.

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

È successo a me perché sto facendo funzionare l’applicazione usando Newtonsoft.Json 4.0

A partire dal:

     

A:

     

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 tale 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 rispetto a un altro componente di questo tipo in un altro assieme.

Questo a volte accade quando si usa “Sfoglia” per trovare riferimenti e aggiungere la versione errata dell’assieme, oppure si ha una versione diversa del componente nel proprio repository di codice come quella installata nel computer locale.

Prova a trovare i progetti che presentano questi conflitti, rimuovi i componenti dall’elenco di riferimento, quindi aggiungili di nuovo assicurandoti di puntare allo stesso file.

Ho un altro modo per farlo se stai usando Nuget per gestire le tue dipendenze. Ho scoperto che a volte VS e Nuget non corrispondono e Nuget non è in grado di riconoscere che i tuoi progetti non sono sincronizzati. Il file packages.config dirà una cosa ma il percorso mostrato in References – Properties indicherà qualcos’altro.

Se sei disposto ad aggiornare le tue dipendenze, procedi come segue:

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

  2. Seleziona la scheda ‘Pacchetti installati’ nel riquadro di sinistra Registra i pacchetti installati Potresti voler copiare prima il pacchetto packages.config sul tuo desktop se ne hai molti, quindi puoi controllarlo con Google per vedere che cosa è installato Nuget pkgs

  3. Disinstalla i tuoi pacchetti. Va bene, li aggiungeremo di nuovo.

  4. Installa immediatamente i pacchetti che ti servono. Ciò che farà Nuget non è solo quello di ottenere la versione più recente, ma altererà i tuoi riferimenti e aggiungerà anche i reindirizzamenti vincolanti per te.

  5. Fallo per tutti i tuoi progetti.

  6. A livello di soluzione, fai un Clean and Rebuild.

Potresti voler iniziare con i progetti più bassi e lavorare a quelli di livello superiore e ribuild ogni progetto mentre procedi.

Se non si desidera aggiornare le proprie dipendenze, è ansible utilizzare la console del gestore pacchetti e utilizzare la syntax Update-Package -ProjectName [yourProjectName] [packageName] -Version [versionNumber]

=> verifica 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. Anche questo ti aiuta. I migliori saluti.

Aveva anche questo problema – nel mio caso era causato dalla presenza della proprietà “Versione specifica” su un numero di riferimenti impostato su true. La modifica di questo a falso su quei riferimenti ha 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 di riferimento). Ho rimosso il riferimento diretto, pulito e ricostruito la soluzione. Problema risolto

  1. Apri “Esplora soluzioni”.
  2. Clicca 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 la scatola gialla che suggerisce di prenderne nota. Basta rimuoverlo.
  5. Aggiungi il riferimento indietro e compila il tuo codice.
  6. È tutto.

Nel mio caso, c’era un problema con il riferimento MySQL. In qualche modo, potrei elencarne tre versioni sotto l’elenco di tutti i riferimenti disponibili; per .net 2.0, .net 4.0 e .net 4.5. Ho seguito le procedure da 1 a 6 sopra e ha funzionato per me.

Un’altra cosa da considerare e controllare è assicurarsi di non avere alcun servizio in esecuzione che usi quella cartella bin. se il loro è interrompere il servizio e ribuild la soluzione

Sembra che ci sia un problema su Mac Visual Studio durante la modifica dei file .resx. Non so davvero cosa sia successo, ma ho avuto questo problema non appena ho modificato alcuni file .resx sul mio Mac. Ho aperto il progetto su Windows, ho aperto i file ed erano come se non fossero stati modificati. Così li ho modificati, salvati e tutto ha ripreso a funzionare anche su Mac.