Errore CS1705: "che ha una versione successiva all'assembly di riferimento"


109

Lo sto esaminando da un po 'e non l'ho risolto. Ricevo 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 esegue Server 2003. Sono andato in c: \ windows \ assembly e ho notato infatti che c'erano 3 versioni di Common.dll elencate. 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 ricompilato e ridistribuito il mio codice (probabilmente eccessivo ma vabbè). Quando ho aperto il browser in una nuova sessione e sono andato di nuovo all'URL del sito, ho ancora ricevuto lo stesso messaggio.

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

Cos'altro posso esaminare per risolvere questo problema? Non voglio modificare il riferimento nel mio assembly in modo che punti alla versione precedente.


2
*.*Numeri di versione pazzi . Ricostruisci tutto, unico modo per esserne sicuri.
Hans Passant

Risposte:



68

Ho riscontrato questo errore perché "Ricostruisci" non stava realmente ricostruendo.

Soluzione: chiudere Visual Studio, andare davvero ed eliminare la cartella bin, quindi ricostruire, potrebbe funzionare meglio.

Inoltre, a volte Visual Studio mente sui riferimenti, quindi controlla i HintPathtuoi .csprojfile.


2
Questo mi ha salvato la pancetta. Gestire il locale andava bene, ma ho pubblicato una modifica e le cose sono andate in modo strano. L'eliminazione del contenuto della cartella bin in linea ha costretto le cose a tornare sincronizzate. Grazie!
pStan

40

Se stai usando NuGet, vale la pena andare a "Gestisci pacchetti NuGet per soluzione" , trovare il pacchetto che causa problemi e premere aggiornamento. Dovrebbe quindi portare tutti i pacchetti all'ultima versione e risolvere il problema.

Vale la pena provare perché è facile e veloce.


2
Questo mi ha risolto, grazie. La mia situazione era leggermente diversa però: non era elencato negli aggiornamenti, quindi dovevo andare su installato e c'era una finestra che mostrava la versione del pacchetto per progetto. Stavo aggiornando alcuni vecchi moduli a una nuova versione di un cms, quindi sono dovuto andare ai pacchetti problematici, selezionarli e fare clic su Installa. Potrebbe essere perché il cms era appena cambiato per usare nuget, ma mi hai risparmiato un sacco di noiose csprojmodifiche!
rtpHarry

3
Assicurati di aggiornare i pacchetti NuGet a livello di soluzione anziché a livello di progetto.
Jess

2
Questa certamente dovrebbe essere la risposta accettata con tutti i mezzi, non l'ho letto ma ho provato involontariamente nella mia soluzione, che ha funzionato a meraviglia.
baymax

30

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


13

Una possibile causa è che il secondo assembly è installato in GAC mentre il primo assembly, con un numero di versione più alto, viene aggiunto ai riferimenti del progetto. Per verificarlo, fare doppio clic sull'assieme nei riferimenti del progetto e controllare se è presente un altro assieme con lo stesso nome nel Visualizzatore oggetti.

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

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

Due anni dopo e il tuo suggerimento ha funzionato a meraviglia. La visualizzazione dei riferimenti nel browser degli oggetti l'ha ordinata.
ceebreenk

3

Vai a Riferimento e aggiungi un nuovo riferimento al tuo 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.


2

Il mio team ha appena riscontrato questo problema nel nostro ambiente di compilazione. Il problema era dovuto a una differenza nell'elemento <HintPath> del file .csproj.

Il nostro assembly comune aveva un percorso relativo corretto per la directory contenente i nostri assembly 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é il GAC ha risolto il riferimento del dipendente alla versione corretta installata in C: \ Programmi. L'ambiente di compilazione aveva un'installazione legacy dell'assembly (anche se non avrebbe dovuto averne) a cui ricadeva e quindi l'errore. L'aggiornamento di <HintPath> in un editor di testo ha risolto il problema.


2

Il problema si verifica se i pacchetti nuget variano in più progetti all'interno della soluzione.

Puoi risolvere questo problema aggiornando i pacchetti nuget a una versione comune con tutti i PROGETTI nella SOLUZIONE


1

Ho avuto un problema simile. Il mio problema era che avevo diversi progetti all'interno della stessa soluzione che facevano riferimento a una versione specifica di una DLL ma a versioni diverse. La soluzione era impostare "Versione specifica" su false in tutte le proprietà di tutti i riferimenti.


1

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 questo articolo .

Ho individuato il riferimento e cambiato il PublicKeyToken da quello a cui si fa riferimento a quello più vecchio.

Spero che anche questo aiuti.


1

Ho avuto lo stesso errore. Ho corretto l'errore dopo l'installazione Microsoft.AspNetCore.ALLnel progetto di test.


0

Cartella collezione di dll a mano
Se la soluzione ha una cartella della spazzatura per la DLL file da diverse biblioteche
lib, source, libs, etc.
Si può ottenere questo guai se si apre la soluzione (per un tempo abeti) in Visual Studio. E la cartella di raccolta del tuo dll è persa per qualche motivo o manca un file dll concreto.

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

Cioè il tuo <HintPath>verrà ignorato e il tuo file di progetto (.csproj) non verrà modificato.
Come un 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.OpenXmlsarà fatto riferimento da C:\Program Files (x86)\Open XML SDK\V2.5\libnon da una solution\..\libcartella.

Soluzione rapida

  • controlla e ripristina la cartella di raccolta della dll
  • da Esplora soluzioni fare Scarica progetto , quindi Ricarica progetto .

La soluzione alternativa è eseguire la migrazione al gestore pacchetti NuGet.


0

per SharePoint, assicurati che nella cartella principale non sia presente una cartella "bin" con le tue DLL, in tal caso eliminala. (e modificare "Copia locale" in false in VS).


0

I riferimenti in un progetto di sito Web vengono memorizzati nel relativo file web.config. Aggiorna il riferimento lì per correggere l'errore.

Ho passato un po 'di tempo a esaminare tutti i riferimenti nella mia soluzione prima di rendermi conto che avevo dimenticato i riferimenti nel file web.config.


0

Ho avuto lo stesso problema con UnitTestingProject, dove nel MainProject stavo usando "System.Web.Mvc, Version = 3.0.0.0" e in UnitTestingProject stavo usando "System.Web.Mvc, Version = 3.0.0.1"

Modificare quanto segue nel file <Reference Include="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> <HintPath>..\packages\Microsoft.AspNet.Mvc.3.0.50813.1\lib\net40\System.Web.Mvc.dll</HintPath> </Reference>


0

Ho ottenuto questo dopo aver aggiunto Episerver Find al nostro sito e installato il pacchetto NuGet corrispondente per Episerver Find.

La soluzione è stata semplice: aggiorna anche tutti i componenti aggiuntivi relativi a Episerver (anche se sembrano non correlati: CMS, CMS.TinyMCE, CMS.UI, ecc.)

Dopo aver aggiornato tutti i possibili componenti aggiuntivi di Episerver e la ricompilazione, l'errore è scomparso.


0

Nel mio scenario, ho modificato il file .csproj per la mia app dotnetCore. Ho notato che il tag TargetFramework aveva un valore di netcoreapp2.1 e il tag RuntimeFrameworkVersion un valore di 2.0.0 . Quindi ho cambiato RuntimeFrameworkVersion in 2.1.0 , salvato, riavviato VS e ricostruito e poi ha risolto gli errori.

Spero che questo ti aiuti ...

In bocca al lupo,

Sugeshan


-1

Nel tuo progetto trova riferimenti System.Web.Mvc controlla la versione.

Quindi fai clic con il pulsante destro del mouse su riferimenti -> assembly e cerca system.web.mvc e configuralo .

Il problema causa le diverse versioni di questi assembly .

Modifica: quindi seleziona Gestisci pacchetti NuGet e installa gli aggiornamenti (se hai più progetti installa anche gli aggiornamenti su di essi).

L'aggiornamento importante è Microsoft.AspNet.Mvc e Microsoft.Net.Compilers non dimenticarlo!


-1

Nel nostro team stavamo lavorando su diversi computer con git. Qualcuno ha aggiornato un dlle io non l'avevo. Ho appena aggiornato i miei riferimenti alle dipendenze e il problema è stato risolto.


-3

Ho avuto un problema simile, avevo creato una DLL, cioè A.dll, che faceva riferimento ad altre DLL, cioè B.dll.

Ho creato un'applicazione C.exe e ho fatto riferimento alle DLL A.dll e B.dll.

Soluzione: rimuovendo il riferimento di B.dll da c.exe sono stato in grado di risolvere il problema.

Spero che questo ti aiuti.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.