Imansible caricare il file o l’assembly o una delle sue dipendenze

Sto avendo un altro di questi problemi “Imansible caricare file o assembly o una delle sue dipendenze”.

Ulteriori informazioni: Imansible caricare il file o l’assembly ‘Microsoft.Practices.Unity, Versione = 1.2.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35’ o una delle sue dipendenze. La definizione manifest di assembly individuato non corrisponde al riferimento all’assembly. (Eccezione da HRESULT: 0x80131040)

Non ho idea di cosa stia causando questo o di come potrei eseguirne il debug per trovare la causa.

Ho fatto una ricerca nei miei cataloghi di soluzioni file .csproj, e ogni dove ho Unity che ho:

Riferimento Include = “Microsoft.Practices.Unity, Version = 2.0.414.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL”

Non riesco a trovare alcun riferimento da nessuna parte che vada contro 1.2.0.0 in nessuno dei miei progetti.

Qualche idea su come dovrei fare per risolvere questo?

Gradirei anche suggerimenti su come eseguire il debug di problemi come questo in generale.

  1. Controlla se stai facendo riferimento a un assieme che a sua volta fa riferimento a una vecchia versione dell’unità. Ad esempio, supponiamo che tu abbia un assembly chiamato ServiceLocator.dll che necessita di una vecchia versione di Unity assembly, ora quando fai riferimento a ServiceLocator dovresti fornirlo con la vecchia versione di Unity e questo rende il problema.

  2. Può essere la cartella di output in cui tutti i progetti costruiscono i loro assiemi, ha una vecchia versione di unità.

È ansible utilizzare FusLogVw per scoprire chi sta caricando i vecchi assembly, solo definire un percorso per il log ed eseguire la soluzione, quindi controllare (in FusLogvw) la prima riga in cui è caricato l’assembly Unity, fare doppio clic e vedere la chiamata assemblea, e qui vai.

Aprire Gestione IIS

Seleziona i pool di applicazioni

quindi seleziona il pool che stai utilizzando

vai alle impostazioni avanzate (sul lato destro)

Cambia il flag di Abilita applicazione a 32 bit false su true.

Per me, nessuna delle altre soluzioni ha funzionato (inclusa la strategia clean / rebuild). Ho trovato un’altra soluzione alternativa che consiste nel chiudere e riaprire Visual Studio .

Immagino che questo costringa Visual Studio a ricaricare la soluzione e tutti i progetti, ricontrollando le dipendenze nel processo.

Prova a pulire le cartelle Debug e Release nella tua soluzione. Quindi rimuovi e aggiungi di nuovo l’unità.

In seguito ha funzionato per me.

  • Rimuovi i file temporanei C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ File temporanei ASP.NET
  • Chiudi VSTS e Apri di nuovo
  • Rimuovi e aggiungi le stesse DLL (Nota: aggiungi le stesse versioni di corrispondenza)

Microsoft Enterprise Library (a cui si fa riferimento .NetTiers) era il nostro problema, che a sua volta faceva riferimento a una versione precedente di Unity. Per risolvere il problema, abbiamo utilizzato il seguente reindirizzamento dell’associazione nel web.config:

               

In alternativa, è ansible aggiornare semplicemente la libreria aziendale all’ultima versione.

Al 99% non è ansible caricare file o assembly o un problema di dipendenze causato dalle dipendenze! Ti suggerisco di seguire questa procedura:

  1. Scarica Dependency Walker da http://www.dependencywalker.com/

  2. Avviare Dependency Walker e aprire la DLL (nel mio caso NativeInterfaces.dll )

  3. Puoi vedere una o più dll con l’errore in rosso Errore durante l’apertura del file …

  4. Significa che questa dll è mancante nel tuo sistema; nel mio caso il nome della DLL è MSVCR71.DLL

  5. Puoi scaricare le miss dll da google e copiare nel percorso corretto (nel mio caso c:\windows\system32 )

  6. A questo punto, devi registrare la nuova dll nel GAC (Global Assembly Cache): apri un terminale DOS e scrivi:

     cd \Windows\System32 regsvr32 /i msvcr71.dll 
  7. Riavvia la tua applicazione!

Nonostante la domanda originale sia stata postata 5 anni fa, il problema persiste ancora ed è piuttosto fastidioso.

La soluzione generale è un’analisi approfondita di tutti gli assembly di riferimento per capire cosa non va. Per semplificare questo compito, ho creato uno strumento (un’estensione di Visual Studio) che consente di selezionare un assembly .Net (file .ddl o .exe) e ottenere un grafico di tutti gli assembly di riferimento con riferimenti evidenziati o mancanti evidenziati.

Lo strumento è disponibile nella Raccolta di Visual Studio: https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734

Esempio di output: inserisci la descrizione dell'immagine qui

Controllare il file Web.config / App.config nel progetto. Verifica se i numeri di versione sono corretti.

  

Questo ha funzionato per me.

Ho avuto un problema simile. ** La risposta di Juntos è corretta ** ma dovresti notare un suggerimento importante!

Per unità 2.1.505.2 vengono specificati diversi AssemblyVersion e AssemblyFileVersion :

inserisci la descrizione dell'immagine qui

AssemblyFileVersion viene utilizzato da nuget ma CLR non si preoccupa di ciò! CLR utilizzerà solo AssemblyVersion !

Quindi i reindirizzamenti dovrebbero essere applicati a una versione specificata in AssemblyVersion: 2.1.505.0

      

Vedi anche: Quali sono le differenze tra AssemblyVersion, AssemblyFileVersion e AssemblyInformationalVersion?

immagine dello schermo In solution explorer, fare clic con il tasto destro del mouse sul progetto (non sulla soluzione), nella scheda della build scegliere Target della piattaforma: “Qualsiasi CPU”.

  • Vai a: Soluzione -> Pacchetto
  • Fare clic sulla scheda Avanzate (Trova sotto la pagina)
  • Aggiungi la tua DLL ad altri assembly (in questo modo possiamo aggiungere DLL esterne in sharepoint).

Ho anche avuto questo terribile errore e ho trovato una soluzione per questo …

  1. Fare clic con il tasto destro sul nome della soluzione
  2. Fai clic su Pulisci soluzione
  3. Riavvia Visual Studio
  4. Proprietà del progetto Goto >> Build
  5. Cambia configurazione per rilasciare
  6. Avvia debug (F5)

1), 2)

Fare clic con il tasto destro sul nome della soluzione

4), 5)

Cambia configurazione per rilasciare

Spero che questo ti aiuterà anche.

Non sono sicuro se questo potrebbe aiutare.

Verifica che il nome dell’Assembly e lo spazio dei nomi di Default nella Properies nella tua asimmetria coincidano. Questo ha risolto il mio problema che ha prodotto lo stesso errore.

Grazie Riddhi M. In seguito ha lavorato per me.

Rimuovi i file temporanei C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ File temporanei ASP.NET Chiudi VSTS e Apri nuovamente Rimuovi e aggiungi le stesse DLL (Nota: aggiungi le stesse versioni corrispondenti)

Nel mio caso nella cartella bin c’era una dll non di riferimento chiamata Unity.MVC3, ho provato a cercare qualsiasi riferimento a questo in Visual Studio senza successo, quindi la mia soluzione è stata così facile come cancellare quella DLL dalla cartella bin.

Dici di avere molti progetti nella tua soluzione … beh, inizia con uno vicino alla cima dell’ordine di costruzione. Prendi quello da build e, una volta capito, puoi applicare la stessa correzione a tutti gli altri.

Onestamente, probabilmente hai solo bisogno di aggiornare il tuo riferimento. Sembra che tu abbia aggiornato la tua versione e non abbia aggiornato i riferimenti, oppure si tratti di un problema relativo al percorso se mantieni la soluzione nel controllo del codice sorgente. Basta verificare le ipotesi e aggiungere nuovamente il riferimento.

Questo problema mi è accaduto dove una delle mie librerie dipendenti stava compilando una DLL con “Qualsiasi CPU” quando la libreria genitrice si aspettava una compilazione di “x64”.

È necessario eliminare il file appname.dll dalla cartella di output. Pulisci le cartelle di debug e rilascio. Ricostruisci e copia nel file dll rigenerato della cartella di output.

I “Imposta come progetto di avvio” la libreria / progetto non caricato / non trovato.

Quindi lo ha distribuito.

Ha funzionato!

Penso che non sia stato ansible trovare il file .dll perché inizialmente non era nell’assembly.

Un’altra ansible causa: assicurarsi di non aver accidentalmente dato a entrambi i progetti lo stesso nome di assieme nelle proprietà del progetto.

In seguito ha funzionato per me.

  • Rimuovi i file temporanei C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ File temporanei ASP.NET
    • quindi fai clic con il pulsante destro su File temporanei di Asp.net> proprietà> sicurezza e concedi un accesso totale a IIS e a tutti gli utenti che eseguono il mio progetto

La mia soluzione per .NET 4.0, utilizzando Enterprise Library 5, era di aggiungere un riferimento a:

Microsoft.Practices.Unity.Interception.dll

Cerca riferimenti contraddittori. Anche dopo una pulizia e ricostruzione, i riferimenti in conflitto causeranno comunque un problema. Il mio problema era tra AForge e Accord. Ho rimosso entrambi i riferimenti e ho aggiunto nuovamente i riferimenti ri-scegliendo il riferimento particolare (in particolare per il mio caso, solo Accord).

Per me, la ricostruzione del gioco di unità senza Unity C # ha funzionato con il segno di spunta.

Nel mio caso, nessuna delle risposte proposte ha funzionato.

Ecco cosa ha funzionato per me:

  1. Rimuovi il riferimento
  2. Rinominare la DLL
  3. Importa nuovamente il riferimento

Il secondo passo era importante apparentemente in quanto non funzionava senza di esso.

Prova a verificare se la proprietà “Copia in locale” per il riferimento è impostata su true e la versione specifica è impostata su true. Questo è rilevante per le applicazioni in Visual Studio.

Ho avuto questo oggi, e nel mio caso il problema era molto strano:

     0. 

Nota i caratteri vaganti alla fine dell’XML – in qualche modo quelli sono stati spostati dal numero di versione alla fine di questo blocco di XML!

      

Modificato su quanto sopra e voilà! Tutto ha funzionato di nuovo.

se ricevi questo messaggio di errore aprendo un’applicazione su windows xp significa prima di aver installato quell’app a causa del suo funzionamento senza net framework 4 e service pack 3. hai installato entrambi e di nuovo ricevi questo errore, quindi devi reinstallare di nuovo l’app, ma prima rimuovi da aggiungi e rimuovi

se questo non funziona, per favore non abusare di me. sono anche un junior

Va bene, questo può sembrare molto stupido, ma ecco come ho risolto il problema dopo aver provato ogni altra soluzione e passare una notte in questa stupida cosa.

Stavo ottenendo lo stesso errore con alcune DLL mancanti dalla cartella Bin. Ho provato a eliminare, a recuperare tutto da Team Foundation Server ma non ho funzionato. Ho preso una copia della cartella Bin dalla mia macchina da ufficio-matelocal e l’ho sostituita. Non ha funzionato neanche. Alla fine, ho eseguito manualmente il server FTP, ho ricevuto la copia della DLL che risultava mancante e quindi ha iniziato a mostrare che il file successivo nella sequenza dell’elenco file è mancante.

Così ho ftped server Got all Bin Folder, sostituito manualmente ogni file uno per uno. (Non Ctrl + Tutti e sostituisci .. Ho provato: non ha funzionato.) E in qualche modo ha funzionato …