Impossibile caricare il file o l'assembly o una delle sue dipendenze

Sto riscontrando un altro di questi problemi "Impossibile caricare file o assembly o una delle sue dipendenze".

Ulteriori informazioni: Impossibile caricare il file o l'assembly "Microsoft.Practices.Unity, Version = 1.2.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35" o una delle sue dipendenze. La definizione manifest dell'assembly individuato non corrisponde al riferimento dell'assembly. (Eccezione da HRESULT: 0x80131040)

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

Ho effettuato una ricerca nei file .csproj dei miei cataloghi di soluzioni e ogni dove ho Unity ho:

Il riferimento include = "Microsoft.Practices.Unity, Versione = 2.0.414.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL"

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

Qualche idea su come dovrei risolvere questo?

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

1. Controlla se stai facendo riferimento a un'assemblea che a sua volta fa riferimento a una vecchia versione dell'unità. Ad esempio, supponiamo che tu abbia un assembly chiamato ServiceLocator.dllche necessita di una versione precedente dell'assembly Unity, ora quando fai riferimento ServiceLocatora 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 assembly, ha una vecchia versione di unità.

È possibile utilizzare FusLogVw per scoprire chi sta caricando i vecchi assembly, è sufficiente definire un percorso per il registro ed eseguire la soluzione, quindi controllare (in FusLogvw) la prima riga in cui è caricato l'assembly Unity, fare doppio clic su di esso e vedere la chiamata assemblea, ed ecco qua.

Apri Gestione IIS

Seleziona Pool di applicazioni

quindi seleziona il pool che stai utilizzando

vai alle impostazioni avanzate (a destra)

Cambia il flag di Enable 32-bit application false in true.

Per me, nessuna delle altre soluzioni ha funzionato (inclusa la strategia di pulizia / ricostruzione). 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 rimuovere e aggiungere nuovamente l'unità.

Al 99% Impossibile caricare file o assembly o uno dei suoi problemi di dipendenze è causato da dipendenze! Ti suggerisco di seguire questi passaggi:

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

2. Avvia Dependency Walker e apri 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 manca nel tuo sistema; nel mio caso il nome dll èMSVCR71.DLL

5. Puoi scaricare la DLL mancante da Google e copiarla nel percorso giusto (nel mio caso c:\windows\system32)

6. A questo punto, è necessario registrare la nuova dll nel GAC (Global Assembly Cache): aprire un terminale DOS e scrivere:

   cd \Windows\System32
   regsvr32 /i msvcr71.dll

7. Riavvia la tua applicazione!

Microsoft Enterprise Library (a cui 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 di associazione in web.config:

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity.Configuration" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

In alternativa, potresti voler semplicemente aggiornare Enterprise Library all'ultima versione.

Il seguito ha funzionato per me.

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

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

<bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />

Questo ha funzionato per me.

Nonostante la domanda originale sia stata pubblicata cinque anni fa, il problema persiste ed è piuttosto fastidioso.

La soluzione generale è un'analisi approfondita di tutti gli assiemi referenziati 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 (a .dllo .exefile) per ottenere un grafico di tutti gli assembly a cui si fa riferimento evidenziando riferimenti in conflitto o mancanti.

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

Esempio di output:

In Esplora soluzioni, fai clic con il pulsante destro del mouse sul progetto (non soluzione), nella scheda build scegli Target piattaforma: "Qualsiasi CPU".

La risposta di Juntos è corretta ma dovresti anche considerare:

Per l'unità v2.1.505.2 sono specificati diversi attributi AssemblyVersion e AssemblyFileVersion :

AssemblyFileVersion viene utilizzato da NuGet ma CLR non se ne preoccupa! CLR utilizzerà solo AssemblyVersion !

Quindi i reindirizzamenti devono essere applicati a una versione specificata nell'attributo AssemblyVersion . Quindi dovrebbe essere usato 2.1.505.0

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>

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

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 Soluzione pulita
3. Riavvia Visual Studio
4. Vai a Proprietà progetto >> Crea
5. Cambia configurazione in versione
6. Avvia debug (F5)

1), 2)

4), 5)

Spero che questo ti possa aiutare.

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

Non sono sicuro se questo potrebbe aiutare.

Verificare che il nome dell'assembly e lo spazio dei nomi predefinito nelle proprietà nei propri assiemi corrispondano. Ciò ha risolto il mio problema che ha prodotto lo stesso errore.

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 era così semplice come eliminare quella dll dalla cartella bin.

Grazie Riddhi M. Seguendo ha funzionato per me.

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

Dici di avere molti progetti nella tua soluzione ... beh, inizia con uno vicino alla cima dell'ordine di costruzione. Ottieni quello da costruire e una volta capito, puoi applicare la stessa correzione al resto di essi.

Onestamente, probabilmente devi solo aggiornare il tuo riferimento. Sembra che tu abbia aggiornato la tua versione e non abbia aggiornato i riferimenti, oppure è un problema relativo al percorso se mantieni la tua soluzione nel controllo del codice sorgente. Verifica i tuoi presupposti e aggiungi nuovamente il riferimento.

Il seguito ha funzionato per me.

• Rimuovere i file temporanei C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ File temporanei ASP.NET
  • quindi fai clic con il pulsante destro del mouse su File temporanei Asp.net> proprietà> sicurezza e dai il controllo totale dell'accesso a IIS e a tutti gli utenti che eseguono il mio progetto

Questo problema mi è accaduto quando una delle mie librerie dipendenti stava compilando una DLL con "Any CPU" quando la libreria padre si aspettava una compilation di "x64".

Ho avuto lo stesso problema, l'ho risolto tramite le istruzioni seguenti:

1. apri il menu degli strumenti e seleziona l'opzione
2. nelle opzioni, finestra vai a Progetti e soluzioni / Progetti Web
3. dai un'occhiata use the 64bit version of IIS ...

Devi eliminare il file appname.dll dalla cartella di output. Pulizia delle cartelle Debug e Release. Ricostruisci e copia nel file dll rigenerato della cartella di output.

I "Imposta come progetto di avvio" la libreria / progetto non scaricato / non trovato.

Quindi lo ha distribuito.

Ha funzionato!

Penso che non sia riuscito a trovare il DLL perché all'inizio non era nell'assemblea.

Un'altra possibile causa: assicurarsi di non aver accidentalmente assegnato a entrambi i progetti lo stesso nome di assieme nelle proprietà del progetto.

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

Microsoft.Practices.Unity.Interception.dll

Cerca riferimenti contrastanti. 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 aggiunto nuovamente i riferimenti scegliendo nuovamente il riferimento particolare (particolare nel mio caso, solo Accord).

Per me ricostruire il gioco di unità senza Unmark C # Proects Checkmark ha funzionato.

Nel mio caso, nessuna delle risposte proposte ha funzionato.

Ecco cosa ha funzionato per me:

1. Rimuovi il riferimento
2. Rinomina la DLL
3. Importa di nuovo il riferimento

Apparentemente il secondo passo era importante 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.

L'ho avuto oggi, e nel mio caso il problema era molto strano:

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0" newVersion="3.1.0.0" />
  </dependentAssembly>0.

Nota i caratteri vaganti alla fine dell'XML - in qualche modo quelli erano stati spostati dal numero di versione alla fine di questo blocco di XML!

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0.0" newVersion="3.1.0.0" />
  </dependentAssembly>

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

se ricevi questo messaggio di errore aprendo un'applicazione su Windows XP significa prima di tutto che hai installato quell'app perché non funziona senza net framework 4 e Service Pack 3. hai installato entrambi e ancora stai ricevendo questo errore, quindi dovresti reinstallare di nuovo quell'app ma prima disinstallare da aggiungi e rimuovi

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