.Net picking errata versione dell'assembly di riferimento


141

Ho appena copiato un progetto esistente su una macchina nuova di zecca per iniziare a svilupparlo e ho riscontrato un problema con la versione di uno dei miei assiemi di riferimento (una DLL di Telerik come accade).

Il progetto originariamente faceva riferimento a una versione precedente dell'assembly (chiamiamolo v1.0.0.0). La mia nuova macchina ha l'ultima versione dell'assembly installata, quindi ho pensato di aggiornarla (chiamiamo la nuova versione v2.0.0.0).

Ora ecco il problema: se copio la vecchia dll v1.0.0.0 nella cartella del progetto e la aggiungo come riferimento, il sito Web si avvia senza problemi. Se cancello quel riferimento (e cancello anche la vecchia DLL dal mio sistema) e aggiungo la nuova versione (v2.0.0.0), la pagina mostra la seguente eccezione:

Impossibile caricare il file o l'assembly 'XXXXXX, Versione = 1.0.0.0, Cultura = neutro, PublicKeyToken = 121fae78165ba3d4' o una delle sue dipendenze. La definizione manifest dell'assembly individuato non corrisponde al riferimento dell'assembly. (Eccezione da HRESULT: 0x80131040)

Chiaramente, il codice sta cercando la versione non aggiornata e non la trova. Ma perché?

Ho grepped la cartella della soluzione per quel numero di versione e non sono riuscito a trovare un singolo riferimento. Ho ricontrollato il testo del file .csproj e ho scoperto che la versione mostra correttamente l'ultima versione e che HintPath mostra correttamente il percorso della nuova DLL. Inoltre, poiché non ho installato la vecchia DLL sul sistema, questa non viene visualizzata nel mio GAC (sebbene v2.0.0.0 funzioni, come previsto).

Ho quindi abilitato il visualizzatore log di fusione per provare a capire perché sta cercando quella vecchia versione, ma senza fortuna:

Assembly Load Trace: The following information can be helpful to determine why the assembly 'XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4' could not be loaded.


=== Pre-bind state information ===
LOG: User = MyComp\me
LOG: DisplayName = XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
 (Fully-specified)
LOG: Appbase = file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/
LOG: Initial PrivatePath = d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\bin
Calling assembly : WebApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\web.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX.DLL.
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX/XXXXXX.DLL.
LOG: Attempting download of new URL file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/bin/XXXXXX.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Tutto ciò che dice che inizia cercando quella vecchia assemblea. Ho provato a trovare una soluzione online e ho visto questa simile domanda SO , ma sembra essere l'esatto contrario del mio problema. Il programma di quell'interrogatore stava trovando la DLL sbagliata anziché quella referenziata. Considerando che il mio problema è che il programma sta misteriosamente cercando la DLL errata e non è in grado di trovarla quando quella giusta può essere trovata localmente nella cartella bin e nel GAC.

Perché il mio sta cercando la vecchia versione? Dove altro posso cercare per trovare questo riferimento errato?

Risposte:


151

La mia ipotesi è che un altro assembly che stai utilizzando si riferisca alla vecchia dll. Conoscete tutti gli altri riferimenti di progetto utilizzati e qualcuno di loro ha un riferimento alle DLL Telerik?

Puoi inserire un reindirizzamento vincolante nel tuo file web.config in questo modo?

<dependentAssembly>
 <assemblyIdentity name="Telerik" publicKeyToken="121fae78165ba3d4"/>
 <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

12
Ho avuto tutti i tipi di problemi simili a questo con diverse versioni di caricamento / non caricamento. Un altro trucco che puoi provare è quello di eliminare manualmente tutti i file nella cartella C: /WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files / root / 90233b18 / 10d54998. A volte durante la ricompilazione di siti Web, ASP.Net non pulisce quella cartella a causa di alcuni blocchi di file e quelle DLL potrebbero essere agganciate a vecchi riferimenti. Vale la pena provare, so che ha funzionato per me in passato.
Chris Conway,

1
Hai risolto un problema correlato per me - grazie! Una forma ereditata nella mia applicazione C # non si apriva nel designer perché cercava una versione precedente di un riferimento. Si scopre che un altro riferimento era stato originariamente creato facendo riferimento a quella vecchia versione del riferimento al problema.
Sam Skuce,


1
Grazie Chris! Hai risolto il mio problema qui: stackoverflow.com/q/11490177/7850
Shaul Behr

3
Puoi anche cercare in App.config o web.config e vedere se le <dependentAssembly>voci esistenti causano il problema.
Roy Tinker,

24

Sono con Chris Conway su questo (lo ha votato). Il problema è che stai facendo riferimento a una delle assemblee Telerik nel tuo progetto che fa riferimento a un'altra che non c'è.

Prima cosa: non installerei NESSUN assemblaggio di fornitori (ad esempio: telerik) nel GAC. Le cose di Telerik sono comunque compilate in sole due assemblee (telerik.web.design e telerik.web.ui). Distribuisci solo quelli con l'applicazione.

In secondo luogo, in ciascuno dei tuoi file .proj (come .csproj) ci sarà un punto <reference include..>che punta al file Telerik.Web.UI. Questo normalmente contiene un numero di versione. Assicurarsi che l'assembly inserito nella cartella bin corrisponda a quella versione.

Terzo, assicurati che TUTTI i tuoi progetti utilizzino l'ultimo assembly. Assicurarsi inoltre che stiano afferrando l'assemblaggio da un percorso locale anziché dal GAC. (Davvero non mi piace il GAC. Non ha causato la fine dei problemi su alcuni progetti a cui ho partecipato). Generalmente abbiamo una cartella "Assiemi" che tutti i progetti usano per riferimenti di assiemi esterni.

In quarto luogo, Visual Studio cerca automaticamente il tuo GAC ogni volta che viene caricato un progetto del sito Web e esegue il retargeting delle posizioni dell'assembly se trova qualcosa nel GAC. Non riesco a ricordare se lo fa mai per i progetti di applicazioni web, ma non ho avuto il problema da molto tempo con quelli. Ciò può causare problemi simili durante la distribuzione.

In quinto luogo, è possibile ricollegare i numeri di versione per gli assiemi in web.config. Nella runtime/assemblybindingsezione puoi usare qualcosa di simile al seguente che porta in avanti ogni assembly telerik distribuito nel 2008 e lo punta a una versione molto particolare:

  <dependentAssembly>
    <assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" />
    <bindingRedirect oldVersion="2008.0.0.0-2020.0.0.0" newVersion="2010.02.0713.35" />
  </dependentAssembly>

2
Intendevo "sentire", mi disturba da mesi ormai :)
Michael La Voie,

21

Ho provato la maggior parte delle risposte ma ancora non riuscivo a farlo funzionare. Questo ha funzionato per me:

fare clic con il tasto destro del mouse su riferimento -> proprietà -> cambiare 'Versione specifica' in falso.

inserisci qui la descrizione dell'immagine

Spero che questo ti aiuti.


30
Ecco cosa significa votare il +1.
xr280xr,

7
Ma a volte il semplice voto non riassume sufficientemente quanto sia felice e sollevata la risposta ti rende - dopo aver passato ore e ore a cercare di risolvere un problema stupido che non dovrebbe nemmeno essere un problema, e provi a cercarlo in un modo diverso , trova una risposta diversa da quella che hai provato prima e boom! ora funziona! Dopotutto, a volte semplicemente premendo il pulsante di voto non rende giustizia a quella sensazione travolgente, amico, mi hai davvero salvato da questo.
Michael Plautz,

7

Provare:

  • pulizia dei file di progetto temporanei
  • pulizia dei file build e obj
  • pulizia vecchie versioni installate su C:\Users\USERNAME\.nuget\packages\

Questo ha funzionato per me.


1
La pulizia della directory C: \ Users \ USERNAME \ .nuget \ pacchetti \ era ciò che mi mancava. Molte grazie!
Herdo,

per la vecchia versione nuget pulita, nel computer basato su Windows, ckuck Avvia e cerca "esegui"> copia e incolla "% userprofile% \. nuget \ pacchetti" - questo aprirà la cartella delle versioni
nuget

3
  1. Vai a C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG
  2. Trova il file machine.config
  3. apri nel blocco note
  4. trova conflitto dll
  5. Rimuovi questo e salva.

assemblee di compilazione

addassembly = dllName, Version = 1.0.0000.0000 Culture = neutral, PublicKeyToken = "QWEWQERWETERY"

compilazione di assiemi

per me va bene.


2
Ho anche scoperto questo incubo - anche se rimuovi l'assemblaggio da GAC ​​lascia riferimenti di versione errati in "C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG \ machine.config"
Evalds Urtans

3

Questa non è una risposta chiara al perché, ma abbiamo avuto questo problema, ecco le nostre circostanze e cosa l'ha risolto:

Dev 1:

La soluzione contiene Progetto A che fa riferimento a un pacchetto NuGet e un progetto MVC che fa riferimento a Progetto A. Abilitato Ripristino pacchetto NuGet, quindi aggiornato il pacchetto NuGet. Si è verificato un errore di runtime in cui non è stato possibile trovare la libreria NuGet, ma l'errore sta cercando la versione precedente e non aggiornata. Soluzione (e questo è ridicolo): imposta un punto di interruzione sulla prima riga di codice nel progetto MVC che chiama il Progetto A. Entra con F11. Risolto - non ho mai più avuto problemi.

Dev 2:

Stessa soluzione e progetti, ma il punto di interruzione della magia e il passaggio nella soluzione non funzionano. Ho cercato ovunque i reindirizzamenti della versione o altri riferimenti errati a questo pacchetto Nuget, rimosso il pacchetto e reinstallato, spazzato via, obj, Asp.Net Temp, niente ha risolto. Infine, rinominato Progetto A, ha eseguito il progetto MVC - risolto. Rinominato con il nome originale, rimase fisso.

Non ho alcuna spiegazione del motivo per cui ha funzionato, ma ci ha fatto uscire da un barlume serio.


2

Hai altri progetti in quella soluzione? (Potrebbe essere un altro progetto che fa riferimento a una versione precedente) Di solito in VS, la dipendenza dll abbraccia tutti i progetti nella soluzione.


Nessun altro progetto in soluzione e nessun'altra DLL referenziata che fa riferimento a Telerik. Sto solo facendo riferimento a DLL MS MS System. *
Michael La Voie

2

Il mio problema era che i vecchi assembly erano nella cartella _bin_deployableAssemblies nell'applicazione Web. Ciò significava che i vecchi assiemi stavano sovrascrivendo gli assiemi GAC durante la costruzione del progetto.


2

Nel caso in cui salva qualcun altro 3 ore ... il mio caso era un po 'diverso. Il mio codice utilizzava DevExpress v11.1 v11.1.4.0. Ho fatto riferimento tutto correttamente nel mio codice. Ma .net memory profiler ha installato DevExpress v11.1 v11.1.12.0 nel GAC. In realtà, non sono stati i componenti a cui ho fatto riferimento, ma quelli a cui hanno fatto riferimento internamente a non riuscire. Prova come potrei, il GAC viene sempre controllato per primo. È stato compilato e funzionava bene, ma non riuscivo a visualizzare il progettista dei moduli di vincita e la traccia dello stack non era affatto d'aiuto. Finalmente disinstallato .net memory profiler e tutto è stato ripristinato.


2

Ho avuto un problema simile e ho dovuto eliminare tutto dalle cartelle bin e obj e ricostruire per superare il mio problema. Spero che questo ti aiuti.


1

Se si verifica questo problema durante il test e / o il debug dell'applicazione dall'ambiente Visual Studio (ASP.NET Development Server), è necessario eliminare tutti i file temporanei nella cartella del sito Web di sviluppo. Per sapere dove si trova quella cartella, cerca l'icona ASP.NET Development Server sull'icona della barra delle applicazioni di Windows (dovrebbe avere un titolo come questo: ASP.NET Development Server - Porta ####), fai clic con il tasto destro sull'icona e seleziona Mostra Dettagli; quindi, il campo Percorso fisico ti dirà qual è la cartella temporanea, tutti gli elementi lì dovrebbero essere eliminati per risolvere il problema. Costruire ed eseguire nuovamente il sito Web e il problema dovrebbe essere risolto (di nuovo, risolto per l'ambiente di sviluppo).


1

Ho avuto lo stesso problema con assiemi diversi che fanno riferimento a versioni diverse di Newtonsoft.json. La soluzione che ha funzionato per me era l'esecuzione di update-package dalla console Nuget Package Manager.


1

Questo errore era in qualche modo fuorviante: stavo caricando alcune DLL che richiedevano la specifica dell'architettura x64. Nel .csprojfile:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release-ABC|AnyCPU'">
    <OutputPath>bin\Release-ABC</OutputPath>
    <PlatformTarget>x64</PlatformTarget>
</PropertyGroup>

Un PlatformTargeterrore ha causato questo errore.


1

Stavo ottenendo:

Impossibile caricare il file o l'assembly 'XXX-new-3.3.0.0' o una delle sue dipendenze. La definizione manifest dell'assembly individuato non corrisponde al riferimento dell'assembly. (Eccezione da HRESULT: 0x80131040)

È perché ho cambiato il nome dell'assembly da XXX.dlla XXX-new-3.3.0.0.dll. Il ripristino del nome nell'originale ha corretto l'errore.


Sì - inclusa una versione nel nome nella nostra libreria di assiemi comune per evitare problemi di denominazione nel controllo del codice sorgente. Modificato il nome indietro e aggiornato manualmente i percorsi dei riferimenti / suggerimenti e tutto ha funzionato.
Mathew Paxinos,

0

È quasi come se dovessi cancellare il tuo computer per sbarazzarti della vecchia dll. Ho già provato tutto quanto sopra e poi ho fatto il passo aggiuntivo di eliminare ogni istanza del file .DLL che era sul mio computer e rimuovere ogni riferimento dall'applicazione. Tuttavia, si compila ancora bene e quando funziona fa riferimento alle funzioni dll bene. Sto iniziando a chiedermi se da qualche parte si sta riferendo ad esso da un'unità di rete.


0

Ho avuto lo stesso messaggio quando passavo da una versione all'altra di un'applicazione che faceva riferimento a versioni diverse della stessa DLL. Anche se stavo testando in diverse cartelle, ho copiato accidentalmente la versione più recente sulla versione precedente.

Quindi la prima cosa da controllare è la versione della DLL di riferimento nella cartella dell'applicazione. Nel caso in cui.


0

Forse questo aiuta o forse no. Ho pulito il mio debug e le versioni di rilascio, quindi ho rinominato la cartella OBJ. Questo alla fine mi ha fatto venire la gola. I passaggi precedenti erano fondamentalmente la rimozione dei riferimenti del progetto e il loro reinserimento nelle proprietà del progetto.


0

In My Visual Studio 2015, mi sono assicurato che l'elenco dei percorsi di riferimento del progetto Visual Studio offensivo fosse vuoto:

inserisci qui la descrizione dell'immagine


Hai pubblicato la stessa identica risposta a 2 domande diverse?
AK47,

0

Questo è ciò che ha funzionato per me:

Stavo usando la Microsoft.IdentityModel.Clients.ActiveDirectoryversione 3.19 in un progetto di libreria di classi ma avevo installato solo la versione 2.22 nel progetto dell'applicazione Web ASP.NET attuale. L'aggiornamento a 3.19 nel progetto dell'app Web mi ha superato l'errore.


0

Nel mio caso avevo 3 progetti, 1 progetto principale e 2 progetti secondari a cui fa riferimento il progetto principale. Quindi ho aggiornato il progetto principale, tralasciando il progetto secondario. Ecco dove si trovava il conflitto. Dopo aver aggiornato tutto il mio progetto, tutto ha funzionato bene.


0

In VS2017, ho provato tutte le soluzioni di cui sopra ma non funziona nulla. Stiamo usando Azure Devops per il controllo delle versioni.

  1. Da Esplora team> Explorer controllo sorgente

inserisci qui la descrizione dell'immagine

  1. Seleziona il progetto che ti fa impazzire a lungo

  2. Fare clic con il tasto destro sul ramo o soluzione> Avanzate> ottieni versione specifica

inserisci qui la descrizione dell'immagine

  1. Quindi assicurati di aver spuntato la casella di controllo per sovrascrivere i file come da screenshot

inserisci qui la descrizione dell'immagine


0

Nel mio caso, ho scelto accidentalmente la versione errata del pacchetto Telerik da nuget, che ha quindi sostituito ogni pacchetto a cui ho fatto riferimento con la versione errata. Ha quindi inserito un reindirizzamento vincolante alla versione errata in modo che anche dopo aver sostituito tutto con la versione corretta, stesse ancora cercando la versione errata.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.