La definizione manifest dell'assembly individuato non corrisponde al riferimento dell'assembly

Sto cercando di eseguire alcuni test unitari in un'applicazione Windows Forms C # (Visual Studio 2005) e ottengo il seguente errore:

System.IO.FileLoadException: impossibile caricare il file o l'assembly 'Utility, Version = 1.2.0.200, Culture = neutral, PublicKeyToken = 764d581291d764f7' o una delle sue dipendenze. La definizione manifest dell'assembly individuato non corrisponde al riferimento dell'assembly. (Eccezione da HRESULT: 0x80131040) **

su x.Foo.FooGO ()

at x.Foo.Foo2 (String groupName_) in Foo.cs: riga 123

at x.Foo.UnitTests.FooTests.TestFoo () in FooTests.cs: linea 98 **

System.IO.FileLoadException: impossibile caricare il file o l'assembly 'Utility, Version = 1.2.0.203, Culture = neutral, PublicKeyToken = 764d581291d764f7' o una delle sue dipendenze. La definizione manifest dell'assembly individuato non corrisponde al riferimento dell'assembly. (Eccezione da HRESULT: 0x80131040)

Guardo i miei riferimenti e ho solo un riferimento a Utility version 1.2.0.203(l'altro è vecchio).

Qualche suggerimento su come capire cosa sta cercando di fare riferimento a questa vecchia versione di questo file DLL?

Inoltre, non credo di avere questo vecchio assemblaggio sul mio disco rigido. Esiste uno strumento per cercare questo vecchio assembly con versione?

Caricatore di assembly .NET:

• non è in grado di trovare 1.2.0.203
• ma ho trovato un 1.2.0.200

Questo assembly non corrisponde a quanto richiesto e pertanto viene visualizzato questo errore.

In parole semplici, non riesce a trovare l'assembly a cui si fa riferimento. Assicurarsi che riesca a trovare l'assemblaggio corretto inserendolo nel GAC o nel percorso dell'applicazione. Vedi anche https://docs.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference .

Puoi fare un paio di cose per risolvere questo problema. Innanzitutto, utilizza la ricerca di file di Windows per cercare il tuo disco rigido per il tuo assembly (.dll). Una volta che hai un elenco di risultati, fai Visualizza-> Scegli Dettagli ... e quindi seleziona "Versione file". Verrà visualizzato il numero di versione nell'elenco dei risultati, in modo da poter vedere da dove potrebbe provenire la versione precedente.

Inoltre, come ha detto Lars, controlla il tuo GAC per vedere quale versione è elencata lì. Questo articolo di Microsoft afferma che gli assembly trovati nel GAC non vengono copiati localmente durante una build, quindi potrebbe essere necessario rimuovere la versione precedente prima di fare una ricostruzione di tutto. (Vedi la mia risposta a questa domanda per le note sulla creazione di un file batch per farlo per te)

Se non riesci ancora a capire da dove provenga la vecchia versione, puoi utilizzare l'applicazione fuslogvw.exe fornita con Visual Studio per ottenere ulteriori informazioni sugli errori di associazione. Microsoft ha informazioni su questo strumento qui . Nota che dovrai abilitare la registrazione impostando la HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLogchiave di registro su 1.

Mi sono appena imbattuto in questo problema da solo e ho scoperto che il problema era qualcosa di diverso da quello in cui si sono imbattuti gli altri.

Avevo due DLL a cui faceva riferimento il mio progetto principale: CompanyClasses.dll e CompanyControls.dll. Stavo ricevendo un errore di runtime che diceva:

Impossibile caricare il file o l'assembly 'CompanyClasses, Version = 1.4.1.0, Culture = neutral, PublicKeyToken = 045746ba8544160c' o una delle sue dipendenze. La definizione manifest dell'assembly individuato non corrisponde al riferimento dell'assembly

Il problema era che non avevo alcun file CompanyClasses.dll sul mio sistema con un numero di versione 1.4.1. Nessuno nel GAC, nessuno nelle cartelle dell'app ... nessuno da nessuna parte. Ho cercato tutto il mio disco rigido. Tutti i file CompanyClasses.dll che avevo erano 1.4.2.

Il vero problema, ho scoperto, era che CompanyControls.dll faceva riferimento alla versione 1.4.1 di CompanyClasses.dll. Ho appena ricompilato CompanyControls.dll (dopo averlo fatto riferimento a CompanyClasses.dll 1.4.2) e questo errore è andato via per me.

Di seguito reindirizza qualsiasi versione dell'assembly alla versione 3.1.0.0. Abbiamo uno script che aggiornerà sempre questo riferimento in App.config, quindi non dovremo più affrontare questo problema.

Tramite reflection è possibile ottenere l'assembly publicKeyToken e generare questo blocco dal file dll stesso.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
  </dependentAssembly>
</assemblyBinding>

Si noti che senza un attributo dello spazio dei nomi XML (xmlns) questo non funzionerà.

Se si utilizza Visual Studio, provare "soluzione pulita" e quindi ricostruire il progetto.

Le altre risposte non funzionerebbero per me. Se non ti interessa la versione e vuoi solo che la tua app venga eseguita, fai clic con il pulsante destro del mouse sul riferimento e imposta "versione specifica" su false ... Questo ha funzionato per me.

Ho appena riscontrato questo problema e il problema era che avevo una vecchia copia del DLL nella mia directory di debug dell'applicazione. Potresti anche voler controllare lì (invece del GAC) per vedere se lo vedi.

Adesso farò esplodere la mente di tutti. . .

Elimina tutti i <assemblyBinding>riferimenti dal tuo file .config, quindi esegui questo comando dalla console di NuGet Package Manager:

Get-Project -All | Add-BindingRedirect

Ho aggiunto un pacchetto NuGet, solo per rendermi conto che una parte nera della mia applicazione faceva riferimento a una versione precedente della libreria.

Ho rimosso il pacchetto e fatto riferimento al file DLL statico della versione precedente, ma il file web.config non è mai stato aggiornato da:

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

a ciò che avrebbe dovuto ripristinare quando ho disinstallato il pacchetto:

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

Nel mio caso, questo errore si è verificato durante l'esecuzione di un'applicazione ASP.NET. La soluzione era:

1. Elimina le cartelle obje binnella cartella del progetto

Clean non funzionava, la ricostruzione non funzionava, tutti i riferimenti andavano bene, ma non stava scrivendo una delle librerie. Dopo aver eliminato quelle directory, tutto ha funzionato perfettamente.

Nel mio caso era una vecchia versione della DLL nella directory C: \ WINDOWS \ Microsoft.NET \ Framework \ ~ \ Temporary ASP.NET Files \. È possibile eliminare o sostituire la versione precedente oppure rimuovere e aggiungere nuovamente il riferimento alla DLL nel progetto. Fondamentalmente, in entrambi i casi verrà creato un nuovo puntatore ai file temporanei ASP.NET.

Per noi, il problema è stato causato da qualcos'altro. Il file di licenza per i componenti DevExpress includeva due righe, una per una versione precedente dei componenti che non era installata su questo particolare computer. La rimozione della versione precedente dal file di licenza ha risolto il problema.

La parte fastidiosa è che il messaggio di errore non ha fornito indicazioni su quale riferimento causasse i problemi.

Questo stesso errore esatto viene generato se si tenta di eseguire il binding tardivo mediante la riflessione, se l'assembly a cui si sta eseguendo il collegamento viene assegnato un nome sicuro o il relativo token di chiave pubblica è stato modificato. L'errore è lo stesso anche se in realtà non è stato trovato alcun assembly con il token di chiave pubblica specificato.

È necessario aggiungere il token di chiave pubblica corretto (è possibile ottenerlo utilizzando sn -T sulla dll) per risolvere l'errore. Spero che sia di aiuto.

La mia era una situazione molto simile alla posta di Nathan Bedford ma con una leggera svolta. Anche il mio progetto ha fatto riferimento alla DLL modificata in due modi. 1) Direttamente e 2) Indirettamente facendo riferimento a un componente (libreria di classi) che a sua volta aveva un riferimento alla DLL modificata. Ora il mio progetto Visual Studio per il componente (2) faceva riferimento alla versione corretta della DLL modificata. Tuttavia, il numero di versione del componente stesso NON è stato modificato. Di conseguenza, l'installazione della nuova versione del progetto non è riuscita a sostituire quel componente sul computer client.

Risultato finale: il riferimento diretto (1) e il riferimento indiretto (2) puntavano a versioni diverse della DLL modificata sul computer client. Sulla mia macchina di sviluppo ha funzionato bene.

Soluzione: rimuovere l'applicazione; Elimina tutte le DLL dalla cartella dell'applicazione; Reinstalla Semplice come quello nel mio caso.

Lascerò che qualcuno tragga beneficio dalla mia stupidità di taglio. Ho alcune dipendenze per un'applicazione completamente separata (chiamiamo questa App1). Le DLL di quell'App1 vengono inserite nella mia nuova applicazione (App2). Ogni volta che faccio aggiornamenti in APP1, devo creare nuove dll e copiarle in App2. Bene. . Mi sono stancato di copiare e incollare tra 2 diverse versioni di App1, quindi ho semplicemente aggiunto un prefisso "NEW_" alle DLL.

Bene. . . Sto indovinando che il processo di compilazione analizza la cartella / bin e quando corrisponde in modo errato a qualcosa, si blocca con lo stesso messaggio di errore di cui sopra. Ho cancellato le mie versioni "new_" e le ho costruite semplicemente dandy.

Il mio problema era copiare il codice sorgente su una nuova macchina senza trasferire nessuno degli assembly di riferimento.

Nulla di ciò che ho fatto ha corretto l'errore, quindi in fretta, ho eliminato del tutto la directory BIN. Ricostruito il mio codice sorgente, e ha funzionato da allora in poi.

Vorrei solo aggiungere che stavo creando un progetto ASP.NET MVC 4 di base e ho aggiunto DotNetOpenAuth.AspNet tramite NuGet. Ciò ha comportato lo stesso errore dopo aver fatto riferimento a un file DLL non corrispondente per Microsoft.Web.WebPages.OAuth.

Per aggiustarlo ho fatto un Update-Package e pulito la soluzione per una ricostruzione completa.

Ha funzionato per me ed è un po 'un modo pigro, ma il tempo è denaro :-P

Ho riscontrato questo errore durante la creazione del servizio di build di Team Foundation Server. Si è scoperto che avevo diversi progetti nella mia soluzione utilizzando diverse versioni della stessa libreria aggiunta con NuGet. Ho rimosso tutte le vecchie versioni con NuGet e ho aggiunto quella nuova come riferimento per tutti.

Team Foundation Server mette tutti i file DLL in una directory e, naturalmente, può esistere un solo file DLL con un determinato nome alla volta.

La mia app.config contiene a

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>

per npgsql. In qualche modo sul computer dell'utente, il mio app.exe.config è scomparso. Non sono ancora sicuro che si tratti di un utente sciocco, di un problema con l'installer o di un anti-virus. La sostituzione del file ha risolto il problema.

Ho appena trovato un altro motivo per ottenere questo errore. Ho pulito il mio GAC da tutte le versioni di una libreria specifica e ho creato il mio progetto con riferimento alla versione specifica distribuita insieme all'eseguibile. Quando eseguo il progetto ho ottenuto questa eccezione cercando una versione più recente della libreria.

Il motivo era la politica del publisher . Quando ho disinstallato le versioni della libreria da GAC, ho dimenticato di disinstallare anche gli assembly dei criteri del publisher, quindi, invece di utilizzare il mio assembly distribuito localmente, il programma di caricamento degli assembly ha trovato il criterio del publisher in GAC che gli ha detto di cercare una versione più recente.

Per me la configurazione della copertura del codice nel file "Local.testtesttings" "ha causato" il problema. Ho dimenticato di aggiornare i file a cui è stato fatto riferimento lì.

L'eliminazione del contenuto della cartella bin del progetto e la ricostruzione della soluzione hanno risolto il mio problema.

ripulire e ricostruire la soluzione potrebbe non sostituire tutte le DLL dalla directory di output.

quello che suggerirò è provare a rinominare la cartella da "bin" a "oldbin" o "obj" a "oldobj"

e poi prova a ricostruire la tua silenziosità.

in caso di utilizzo di dll di terze parti, sarà necessario copiarle nella cartella "bin" o "obj" appena creata dopo la compilazione corretta.

spero che questo funzionerà per te.

Potrebbe essere utile eliminare manualmente il vecchio assieme dalla posizione della cartella e quindi aggiungere il riferimento ai nuovi assiemi.

Ho avuto lo stesso errore ... Nel mio caso è stato risolto come segue:

• Inizialmente quando l'applicazione era installata, le persone qui avevano usato Microsoft Enterprise Library 4.1 nell'applicazione.
• Nella settimana precedente il mio computer era formattato e dopo quello oggi, quando ho creato quell'applicazione, mi ha dato un errore che mancava l'assemblaggio della Libreria Enterprise.
• Quindi ho installato Microsoft Enterprise Library 5.0 che ho ottenuto su Google come prima voce di ricerca.
• Quindi, quando ho creato l'applicazione, mi ha dato l'errore precedente, ovvero la definizione manifest dell'assembly individuato non corrisponde al riferimento dell'assembly.
• Dopo gran parte del lavoro di ricerca e analisi, ho scoperto che l'applicazione si riferiva alla 4.1.0.0 e che la DLL nella cartella bin era della versione 5.0.0.0
• Quello che ho fatto è stato quindi installare la Microsoft Enterprise Library 4.1.
• Rimosso il riferimento precedente (5.0) e aggiunto il riferimento 4.0.
• Costruito l'applicazione e voilà ... ha funzionato.

Ecco il mio metodo per risolvere questo problema.

1. Dal messaggio di eccezione, ottenere il nome della libreria "problem" e il numero di versione "previsto".

2. Trova tutte le copie di quel .dll nella tua soluzione, fai clic con il tasto destro su di esse e controlla quale versione del .dll è.

Ok, quindi in questo esempio, il mio .dll è sicuramente 2.0.5022.0 (quindi il numero di versione dell'eccezione è sbagliato).

3. Cerca il numero di versione che è stato mostrato nel messaggio Eccezione in tutti i file .csproj nella tua soluzione. Sostituisci questo numero di versione con il numero effettivo dalla dll.

Quindi, in questo esempio, vorrei sostituire questo ...

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

... con questo...

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

Lavoro fatto !

Nel mio caso il problema era tra la sedia e la tastiera :-)

Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)

Due o più assembly diversi volevano utilizzare una versione diversa della libreria DotNetOpenAuth e questo non sarebbe un problema. Inoltre, sul mio computer locale un web.config è stato automaticamente aggiornato da NuGet:

<dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
    <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>

Poi ho capito che avevo dimenticato di copiare / distribuire il nuovo web.config sul server di produzione. Quindi, se hai un modo manuale di distribuire web.config, controlla che sia aggiornato. Se si dispone di web.config completamente diverso per il server di produzione, è necessario unire queste sezioni di assemblaggio dipendente in sincronia dopo aver utilizzato NuGet.

Se si verifica un errore del tipo " La definizione manifest dell'assembly individuato non corrisponde al riferimento dell'assembly " e se è stato aggiornato tramite Progetto> Gestisci pacchetti NuGet e la scheda Aggiorna in VS , la prima cosa che puoi fare è provare a installare un'altra versione del pacchetto dopo aver verificato le versioni dalla pagina NuGet Gallery ed eseguito il comando folowing dalla console di Package Manager:

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

Sebbene la risposta non sia direttamente correlata al pacchetto in questione ed è stata chiesta molto tempo fa, è piuttosto generica, ancora pertinente e spero che aiuti qualcuno.

Nessuna soluzione ha funzionato per me. Ho provato a pulire la soluzione del progetto, rimuovere il cestino, aggiornare il pacchetto, eseguire il downgrade del pacchetto e così via ... Dopo due ore ho caricato App.config predefinito dal progetto con assembly e lì ho cambiato la versione di riferimento errata da:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

per:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

Dopo questo ho pulito il progetto, lo costruisco di nuovo e ha funzionato. Nessun avviso nessun problema.

Ho ricevuto questo messaggio di errore a causa del riferimento a un assembly con lo stesso nome dell'assembly che stavo costruendo.

Questo è stato compilato ma ha sovrascritto l'assembly di riferimento con l'assembly dei progetti correnti, causando così l'errore.

Per risolverlo ho cambiato il nome del progetto e le proprietà dell'assembly disponibili facendo clic con il tasto destro del mouse sul progetto e scegliendo 'Proprietà'.