c# il - La definizione manifest di assembly individuato non corrisponde al riferimento all'assembly




risolvere reference (25)

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 alla ricerca di una versione più recente della libreria.

Il motivo era la politica dei publisher . Quando ho disinstallato le versioni della libreria da GAC, ho dimenticato di disinstallare anche gli assembly della politica del publisher, quindi anziché utilizzare l'assembly distribuito a livello locale, il caricatore dell'assembly ha rilevato criteri dei publisher in GAC che gli hanno suggerito di cercare una versione più recente.

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

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

a x.Foo.FooGO ()

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

a x.Foo.UnitTests.FooTests.TestFoo () in FooTests.cs: riga 98 **

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

Guardo nei miei riferimenti e ho solo un riferimento alla Utility version 1.2.0.203 (l'altra è vecchia).

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

Inoltre, non penso di avere nemmeno questa vecchia assemblea sul mio disco fisso. C'è qualche strumento per cercare questo vecchio assembly versione?


Ho aggiunto un pacchetto NuGet, solo per rendermi conto che una porzione di 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 cosa dovrebbe essere ripristinato 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>

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


Per noi, il problema è stato causato da qualcos'altro. Il file di licenza per i componenti DevExpress includeva due righe, una per una vecchia versione 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 dato alcuna indicazione su quale riferimento stava causando i problemi.


Mi sono imbattuto in questo problema da solo, e ho scoperto che il problema era qualcosa di diverso rispetto a quello che hanno incontrato gli altri.

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

Impossibile caricare file o assembly 'CompanyClasses, Versione = 1.4.1.0, Culture = neutral, PublicKeyToken = 045746ba8544160c' o una delle sue dipendenze. La definizione manifest di assembly individuato non corrisponde al riferimento all'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 in nessun luogo. Ho cercato il mio intero disco rigido. Tutti i file CompanyClasses.dll che avevo erano 1.4.2.

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


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

  1. Elimina le cartelle obj e bin nella cartella del progetto

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


La mia era una situazione molto simile a quella 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 di Visual Studio per il componente (2) ha fatto riferimento alla versione corretta della DLL modificata. Tuttavia, il numero di versione del componente stesso NON è stato modificato. E come risultato l'installazione della nuova versione del progetto non è riuscita a sostituire quel componente sul computer client.

Risultato finale: riferimento diretto (1) e riferimento indiretto (2) stavano indicando diverse versioni 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; Reinstallare. Semplice come nel mio caso.


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


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


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

Questo ha compilato ma ha sovrascritto l'assembly referenziato con l'assembly dei progetti corrente, causando così l'errore.

Per risolvere il problema ho modificato il nome del progetto e le proprietà dell'assieme disponibili facendo clic con il pulsante destro del mouse sul progetto e scegliendo "Proprietà".


Puoi fare un paio di cose per risolvere questo problema. Innanzitutto, utilizza la ricerca di file di Windows per cercare sul disco rigido il tuo assembly (.dll). Una volta ottenuto un elenco di risultati, fare Visualizza-> Scegli dettagli ... e quindi selezionare "Versione file". Questo mostrerà il numero di versione nell'elenco dei risultati, così puoi vedere da dove potrebbe arrivare la vecchia versione.

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

Se non si riesce ancora a capire da dove proviene la versione precedente, è possibile utilizzare l'applicazione fuslogvw.exe fornita con Visual Studio per ottenere ulteriori informazioni sugli errori di associazione. Microsoft ha informazioni su questo strumento here . Si noti che è necessario abilitare la registrazione impostando la HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog su 1.


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.


Il seguente reindirizza qualsiasi versione di assembly alla versione 3.1.0.0. Abbiamo uno script che aggiornerà sempre questo riferimento in App.config in modo da non dover più risolvere questo problema.

Attraverso il 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à.


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

Per risolvere il problema, ho creato 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 avuto lo stesso errore ... Nel mio caso è stato risolto come segue:

  • All'inizio, quando l'applicazione è stata installata, le persone qui avevano utilizzato Microsoft Enterprise Library 4.1 nell'applicazione.
  • Nella settimana precedente la mia macchina è stata formattata e dopo di che oggi, quando ho creato quell'applicazione, mi è venuto un errore che manca l'assembly della libreria 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 restituito l'errore di cui sopra, vale a dire la definizione manifest di assembly individuato non corrisponde al riferimento all'assembly.
  • Dopo molte ricerche e analisi, ho trovato che l'applicazione faceva riferimento a 4.1.0.0 e la DLL nella cartella bin era della versione 5.0.0.0
  • Quello che ho fatto è stato quindi ho installato la libreria di Microsoft Enterprise 4.1.
  • Rimosso il riferimento precedente (5.0) e aggiunto il riferimento 4.0.
  • Costruito l'applicazione e voilà ... ha funzionato.

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


L'eliminazione manuale del vecchio assieme dal percorso della cartella e l'aggiunta del riferimento ai nuovi assiemi potrebbero aiutare.


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 differenti volevano utilizzare una versione diversa della libreria DotNetOpenAuth e questo non sarebbe un problema. Inoltre, sul mio computer locale un web.config è stato aggiornato automaticamente 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 al server di produzione. Quindi, se hai un modo manuale di distribuire web.config, controlla che sia aggiornato. Se hai completamente differente web.config per il server di produzione, devi unire questa sezione dependentAssembly in sync dopo aver usato NuGet.


Ho riscontrato questo problema durante l'utilizzo di un repository di pacchetti interni. Ho aggiunto il pacchetto principale al repository interno, ma non le dipendenze del pacchetto. Assicurati di aggiungere tutte le dipendenze, le dipendenze delle dipendenze, ricorsive ecc. Al tuo repository interno.


Se non ti interessa la versione e desideri solo eseguire l'app, fai clic con il pulsante destro del mouse sul riferimento e imposta "versione specifica" su false. Le altre soluzioni non funzionerebbero per me.


Questo errore identico viene generato se si tenta di associare in ritardo il reflection, se l'assembly a cui si sta eseguendo l'associazione ottiene il nome sicuro o il token della chiave pubblica è cambiato. L'errore è lo stesso anche se in realtà non esiste alcun assembly trovato con il token della 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 ti aiuti.


Oggi ho avuto lo stesso problema che mi ha impedito di eseguire Add-Migration dopo aver apportato modifiche in Entity Framework.

Ho avuto due progetti nella mia soluzione, chiamiamoli "Client" e "Data" - un progetto di libreria di classi che conteneva i miei modelli e il contesto EF. Il Cliente ha fatto riferimento al progetto Dati.

Avevo firmato entrambi i progetti e poi apportato le modifiche a un modello EF. Dopo aver rimosso la firma, sono riuscito ad aggiungere le migrazioni e ho quindi potuto firmare nuovamente il progetto.

Spero che questo possa essere utile a qualcuno, risparmiando loro una prolungata frustrazione ..


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 App1, quindi ho semplicemente aggiunto un prefisso 'NEW_' alle dll.

Bene. . . Sto indovinando che il processo di costruzione analizza la cartella / bin e quando corrisponde a qualcosa in modo errato, barfs con lo stesso messaggio di errore di cui sopra. Ho cancellato le mie versioni "new_" e ha creato solo dandy.


Il caricatore di .NET Package non è stato in grado di trovare 1.2.0.203, ma ha trovato 1.2.0.200. Questo assembly non corrisponde a ciò che è stato richiesto e pertanto si ottiene questo errore. In parole semplici, non riesce a trovare l'assembly a cui è stato fatto riferimento. Assicurati che possa trovare l'assembly corretto inserendolo nel GAC o nel percorso dell'applicazione. Vedi anche http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx .


Sembra che un assembly corrotto sia referenziato.

Cancella entrambi:

  1. la cartella \ bin del tuo progetto

  2. la cartella temp (dovrebbe essere C:\Users\your_username\AppData\Local\Temp\Temporary ASP.NET Files in windows 7)

e vedere se l'errore si verifica ancora





c# reference compiler-errors dependencies version