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





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

c# reference compiler-errors dependencies version

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?




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




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.




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>



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.




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.




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




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.




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'eliminazione manuale del vecchio assieme dal percorso della cartella e l'aggiunta del riferimento ai nuovi assiemi potrebbero aiutare.




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 !




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.




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.




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






Related