Errore CS1705: "che ha una versione superiore rispetto all'assembly referenziato"

Question

Ho esaminato questo aspetto per un po 'e non l'ho risolto. Ottengo il seguente messaggio di errore:

Compiler Error Message: CS1705: Assembly 'My.Model, Version=1.1.4422.23773, Culture=neutral, 
PublicKeyToken=bfde95ba233094b2' uses 
'Common, Version=3.3.4273.24368, Culture=neutral, PublicKeyToken=bfde95ba233094b2' 
which has a higher version than referenced assembly 
'Common, Version=3.3.4269.17112, Culture=neutral, PublicKeyToken=bfde95ba233094b2' 

c:\WINDOWS\assembly\GAC_MSIL\Common\3.3.4269.17112__bfde95ba233094b2\Common.dll: 
(Location of symbol related to previous error) 

Il server Web è in esecuzione Server 2003. Sono andato a c: windows \ assembly \ e ha fatto in comunicazione fatto che c'erano 3 versioni di Common.dll elencati. La versione più alta elencata era 3.3.4269.17112

Ho copiato la DLL con la versione: 3.3.4273.24368 nella directory dell'assembly. Ho quindi ri-compilato e ridistribuito il mio codice (probabilmente eccessivo, ma vabbè). Quando ho aperto il browser in una nuova sessione e sono tornato all'URL del sito, ho ancora ricevuto lo stesso messaggio.

Posso usare Windows Explorer e verificare che Common.dll con versione superiore sia ora elencato.

Cos'altro posso esaminare per risolvere questo problema? Non voglio cambiare il riferimento nel mio assembly per puntare alla versione precedente.

Answer 1

3 idee per provare:

1. assicurarsi che di tutte le DLL sono compilati contro la stessa versione di Common.
2. Verificare di avere riferimenti di progetto nella soluzione anziché riferimenti file.
3. Uso binding redirections nel web.config

Answer 2

(Oltre alle idee Jakub')

ho avuto questo errore perché "Rebuild" non era davvero la ricostruzione.
Chiudere Visual Studio, davvero andare ed eliminare la cartella bin, quindi ricostruire, potrebbe funzionare meglio.

Inoltre, a volte Visual Studio giace sui riferimenti, quindi controllare lo HintPath nei file .csproj.

Answer 3

Vai a Riferimento e aggiungi un nuovo riferimento al file dll che causa il problema e assicurati che tutte le tue DLL siano compilate con la stessa versione. Funziona per me, spero che funzioni anche per te.

Answer 4

Il mio problema era che avevo 2 progetti che facevano riferimento a 2 diverse copie della stessa dll che avevano versioni differenti. L'ho risolto rimuovendoli entrambi e assicurandomi che stessero facendo riferimento allo stesso file dll.

Answer 5

La mia squadra si è imbattuta in questo problema nel nostro ambiente di costruzione. Il problema era dovuto a una differenza nell'elementoHintPath > del file .csproj.

Il nostro assieme comune aveva un percorso relativo corretto alla directory contenente i nostri assiemi di riferimento. L'assembly dipendente aveva un percorso da una precedente struttura di directory. La soluzione è stata compilata con successo su macchine di sviluppo poiché GAC ha risolto il riferimento del dipendente alla versione corretta installata in C: \ Programmi. L'ambiente di compilazione aveva un'installazione legacy dell'assieme (anche se avrebbe dovuto non averne) che ricadesse e quindi l'errore. L'aggiornamento del <HintPath> in un editor di testo ha risolto il problema.

Answer 6

Avevo un problema simile, avevo creato una DLL, ad esempio A.dll, che faceva riferimento ad altre DLL, ad esempio B.dll.

Ho creato un'applicazione C.exe e DLL di riferimento A.dll e B.dll.

Soluzione - Rimuovendo il riferimento di B.dll da c.exe sono riuscito a risolvere il problema.

Spero che questo aiuti.

Answer 7

Una possibile causa è che il secondo assembly viene installato in GAC mentre il primo assembly, con un numero di versione superiore, viene aggiunto ai riferimenti del progetto. Per verificare ciò, fare doppio clic sull'assembly nei riferimenti del progetto e verificare se esiste un altro assembly con lo stesso nome nel Visualizzatore oggetti.

In questo caso, utilizzare l'utilità gacutil.exe per disinstallare il secondo assembly dal GAC. Ad esempio, se si tratta di gruppi di 64 bit:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\gacutil.exe -u <assembly_name> 

Answer 8

Se si sta utilizzando NuGet vale la pena di andare a 'gestire i pacchetti Nuget per soluzione', trovare il pacchetto che sta causando problemi e colpire aggiornamento. Dovrebbe quindi portare tutti i pacchetti fino alla versione più recente e risolvere il problema.

Vale la pena provare perché è facile e veloce.

Answer 9

Aveva un problema simile. Il mio problema era che avevo diversi progetti all'interno della stessa soluzione, ognuno dei quali faceva riferimento a una versione specifica di una DLL ma a versioni diverse. La soluzione era impostare 'Versione specifica' su falso in tutte le proprietà di tutti i riferimenti.

Answer 10

So che questo è stato chiesto un po 'di tempo fa, dopo aver provato alcuni dei passaggi precedenti. Ciò che mi ha aiutato sono stati i seguenti passaggi e this article.

Ho individuato il riferimento e modificato il PublicKeyToken da quello a cui si fa riferimento a quello precedente.

Spero che questo aiuti anche.

Answer 11

Nel tuo progetto trovare referenze System.Web.Mvc controllare la versione.

Dopo di che fare clic destro referances -> assemblee e cercare System.Web.Mvc e configurazione esso.

Il problema causa le diverse versioni di questi assiemi.

Edit: Than selezionare gestire pacchetti NuGet e installare gli aggiornamenti (se si dispone di più progetti installare gli aggiornamenti anche a loro.)

Importante aggiornamento è Microsoft.AspNet.Mvc e Microsoft.Net.Compilers non dimenticarlo!

Answer 12

cartella collezione di mano dll
Se la soluzione ha una cartella della spazzatura per la DLL file da diverse librerie
lib, source, libs, etc.
È possibile ottenere questo guai se si apre la soluzione (per un tempo abeti) in Visual Studio. E la cartella di raccolta della tua DLL è mancata per qualche motivo o un dll-file concreto è mancato.

Visual Studio cercherà silenziosamente a sostituire il riferimento di dll di qualcosa da solo. Se VS avrà successo, un nuovo riferimento sarà persistente per la soluzione locale. Non per altri cloni/casse.

I.e. il tuo <HintPath> verrà ignorato e il tuo file di progetto (.csproj) non verrà modificato.
Come esempio di me

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> 
    <SpecificVersion>False</SpecificVersion> 
    <HintPath>..\..\..\lib\DocumentFormat.OpenXml.dll</HintPath> 
</Reference> 

Il DocumentFormat.OpenXml verrà fatto riferimento da non C:\Program Files (x86)\Open XML SDK\V2.5\lib da una cartella solution\..\lib.

Soluzione rapida

• controlli e il ripristino si DLL raccolta cartella
• da Esplora soluzioni fare Scarica progetto, quindi Ricarica progetto.

right La soluzione è la migrazione al gestore pacchetti NuGet.

Answer 13

per SharePoint, assicurarsi che sotto la cartella principale non si dispone di una cartella "bin" con il vostro DLL, in tal caso è sufficiente eliminarlo. (e cambia "Copia locale" su falso in VS).