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

https://stackoverflow.com/questions/215026

03-07-2019
|

Domanda

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

System.IO.FileLoadException: impossibile caricare il file o l'assembly 'Utilità, Versione = 1.2.0.200, Cultura = neutro, 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: linea 123

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

System.IO.FileLoadException: impossibile caricare il file o l'assembly 'Utilità, Versione = 1.2.0.203, Cultura = neutro, 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 assembly sul mio disco rigido. Esiste uno strumento per cercare questo vecchio assembly con versione?

Soluzione

Il caricatore di .NET Assembly non è riuscito a trovare 1.2.0.203, ma ha trovato 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 http://blogs.msdn.com/junfeng/archive /2004/03/25/95826.aspx .

Altri suggerimenti

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 - & Gt; Scegli Dettagli ... e quindi controlla & Quot; Versione file & Quot ;. 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 compilazione, 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 da fare questo 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 maggiori informazioni sugli errori di associazione. Microsoft ha informazioni su questo strumento qui . Tieni presente che dovrai abilitare la registrazione impostando la HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog chiave 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, versione = 1.4.1.0, Culture = neutral, PublicKeyToken = 045746ba8544160c 'o una delle sue dipendenze. Il situato lo fa la definizione manifest dell'assembly 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.

Il seguente 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 mai più affrontare questo problema.

Tramite reflection puoi 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>

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

Se si utilizza Visual Studio, provare " soluzione pulita " e poi ricostruisci il tuo 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. inserisci qui la descrizione dell'immagine

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

Ho aggiunto un pacchetto NuGet, solo per rendermi conto che una parte black-box 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 quello 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:

Elimina le cartelle obj e bin nella 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.

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

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 identico errore viene generato se si tenta di eseguire il binding tardivo utilizzando la riflessione, se l'assembly a cui si sta eseguendo il collegamento viene assegnato un nome sicuro o se il token della 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 della chiave pubblica corretto (è possibile ottenerlo utilizzando sn -T sulla dll) per risolvere l'errore. Spero che questo aiuti.

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.

Risoluzione: rimuovere l'applicazione; Elimina tutte le DLL dalla cartella dell'applicazione; Reinstalla. Semplicemente 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 a qualcosa in modo errato, si blocca con lo stesso messaggio di errore come notato sopra. Ho eliminato il mio & Quot; nuovo _ & Quot; versioni e ha costruito appena dandy.

Il mio problema era la copia del codice sorgente su una nuova macchina senza il pull di 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 provocato lo stesso errore dopo aver fatto riferimento a un file DLL non corrispondente per Microsoft.Web.WebPages.OAuth.

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

Ha funzionato per me ed è un po '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 ovviamente può esserci solo un file DLL con un determinato nome alla volta.

La mia app.config contiene un

<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 norme per i 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 nella " Local.testtesttings " file " causato " il problema. Ho dimenticato di aggiornare i file a cui è stato fatto riferimento lì.

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

pulisci e ricostruisci la soluzione potrebbe non sostituire tutte le DLL dalla directory di output.

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

, quindi prova a ricostruire la tua silenziosità.

in caso di utilizzo di dll di terze parti, è necessario copiarle in " appena creato; bin " oppure " obj " cartella dopo la compilazione corretta.

spero che questo funzioni per te.

Potrebbe essere utile eliminare manualmente il vecchio assembly dalla posizione della cartella e quindi aggiungere il riferimento a nuovi assembly.

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

All'inizio, quando l'applicazione era installata, le persone qui avevano usato Microsoft Enterprise Library 4.1 nell'applicazione.
Nella settimana precedente la mia macchina era formattata & amp; dopo quello oggi, quando ho creato quell'applicazione, mi ha dato un errore che manca l'assemblaggio della Biblioteca aziendale.
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 & amp; analisi, ho scoperto che l'applicazione si riferiva a 4.1.0.0 & amp; 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) & amp; aggiunto il riferimento 4.0.
Crea l'applicazione & amp; voilà ... ha funzionato.

Ecco il mio metodo per risolvere questo problema.

Dal messaggio di eccezione, ottenere il nome del " problema " libreria e il " previsti " numero di versione.

Trova tutte le copie di quella .dll nella tua soluzione, fai clic con il pulsante destro del mouse su di esse e controlla quale versione della .dll è.

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

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, sostituirei 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 mi sono reso conto 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 come " La definizione manifest dell'assembly individuato non corrisponde al riferimento dell'assembly " e se hai effettuato l'aggiornamento tramite Progetto > Gestisci i pacchetti NuGet e la scheda Aggiorna in VS , la prima cosa che potresti fare è provare a installare un'altra versione del pacchetto dopo aver controllato le versioni da pagina NuGet Gallery ed eseguendo 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.

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 correggerlo ho cambiato il nome del progetto e le proprietà dell'assembly sono disponibili facendo clic con il tasto destro del mouse sul progetto e scegliendo 'Proprietà'.

Nel file AssemblyVersion nel file AssemblyInfo.cs, utilizzare un numero di versione fisso invece di specificare *. * Cambierà il numero di versione su ogni compilation. Questo è stato il problema di questa eccezione nel mio caso.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow