c# - stato - visual studio reference folder




La definizione manifest di assembly individuato non corrisponde al riferimento all'assembly (20)

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?


Ecco il mio metodo per risolvere questo problema.

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

  1. Trova tutte le copie di tale .dll nella soluzione, fai clic con il pulsante destro del mouse su di esse e verifica quale versione del file .dll è.

Va bene, quindi in questo esempio, il mio .dll è sicuramente 2.0.5022.0 (quindi il numero di versione di Eccezione è sbagliato).

  1. Cerca il numero di versione che è stato mostrato nel messaggio Exception in tutti i file .csproj nella tua soluzione. Sostituire 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 !


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>

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.


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 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à".


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.


Il mio problema è stato copiare il codice sorgente su una nuova macchina senza forzare nessuno degli assembly referenziati.

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 da quel momento in poi ha funzionato.


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


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 sicuro se sia stato un utente stupido, un errore tecnico dell'installatore o ancora l'antivirus. La sostituzione del file ha risolto il problema.


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.


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.


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 si trattava di una vecchia versione della DLL in C: \ WINDOWS \ Microsoft.NET \ Framework \ ~ \ Temporary ASP.NET Files \ directory. È possibile eliminare o sostituire la versione precedente oppure rimuovere e aggiungere il riferimento alla DLL nel progetto. Fondamentalmente, in entrambi i casi creerà un nuovo puntatore ai file temporanei di ASP.NET.


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.


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


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.


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.


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.


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


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





version