[c#] La definizione manifest di assembly individuato non corrisponde al riferimento all'assembly


14 Answers

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 che hai un elenco di risultati, fai Visualizza-> Scegli dettagli ... e poi seleziona "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.

Question

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, Versione = 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 ricevuto questo errore durante la creazione del servizio di generazione di Team Foundation Server. È risultato che nella mia soluzione ho avuto più progetti utilizzando diverse versioni della stessa libreria aggiunta con NuGet. Ho rimosso tutte le vecchie versioni con NuGet e ho aggiunto quello nuovo come riferimento per tutti.

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




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.




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.




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>



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




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.




Questo può verificarsi anche se si utilizzano sia AssemblyInfo.cs con i tag AssemblyVersion che il file .csproj ha un valore diverso. Accoppiando l'AssemblyInfo o rimuovendo la sezione tutti insieme, il problema scompare.




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 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 si utilizza Visual Studio, provare "soluzione pulita" e quindi ricostruire il progetto.




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.




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.




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.




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.




Related