Datei oder Assembly oder eine ihrer Abhängigkeiten konnte nicht geladen werden

Ich habe ein anderes dieser Probleme "Datei oder Assembly oder eine ihrer Abhängigkeiten konnte nicht geladen werden".

Zusätzliche Informationen: Datei oder Assembly 'Microsoft.Practices.Unity, Version = 1.2.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein. (Ausnahme von HRESULT: 0x80131040)

Ich habe keine Ahnung, was dies verursacht oder wie ich es debuggen könnte, um die Ursache zu finden.

Ich habe in meinen Lösungskatalogen .csproj-Dateien gesucht und überall dort, wo ich Unity habe, habe ich:

Referenz Include = "Microsoft.Practices.Unity, Version = 2.0.414.0, Kultur = neutral, PublicKeyToken = 31bf3856ad364e35, Prozessorarchitektur = MSIL"

Ich kann in keinem meiner Projekte eine Referenz finden, die gegen 1.2.0.0 verstößt.

Irgendwelche Ideen, wie ich das lösen soll?

Ich würde mich auch über Tipps zum Debuggen solcher Probleme im Allgemeinen freuen.

1. Überprüfen Sie, ob Sie auf eine Assembly verweisen, die wiederum auf eine alte Version von Unity verweist. Angenommen, Sie haben eine Assembly mit dem Namen, für ServiceLocator.dlldie eine alte Version der Unity-Assembly erforderlich ist. Wenn Sie jetzt auf die Assembly verweisen ServiceLocator, sollten Sie sie mit der alten Version von Unity bereitstellen, und das macht das Problem.

2. Möglicherweise ist der Ausgabeordner, in dem alle Projekte ihre Assemblys erstellen, eine alte Version von Unity.

Mit FusLogVw können Sie herausfinden, wer die alten Assemblys lädt, einfach einen Pfad für das Protokoll definieren und Ihre Lösung ausführen. Überprüfen Sie dann (in FusLogvw) die erste Zeile, in die die Unity-Assembly geladen wird, doppelklicken Sie darauf und sehen Sie den Aufruf Montage, und los geht's.

Öffnen Sie den IIS-Manager

Wählen Sie Anwendungspools

Wählen Sie dann den Pool aus, den Sie verwenden

Gehen Sie zu den erweiterten Einstellungen (rechts).

Ändern Sie das Flag "32-Bit-Anwendung aktivieren" auf "true".

Für mich hat keine der anderen Lösungen funktioniert (einschließlich der Clean / Rebuild-Strategie). Ich habe eine andere Problemumgehungslösung gefunden, die darin besteht, Visual Studio zu schließen und erneut zu öffnen .

Ich denke, dies zwingt Visual Studio, die Lösung und alle Projekte neu zu laden und die Abhängigkeiten im Prozess erneut zu überprüfen.

Versuchen Sie, Debug- und Release-Ordner in Ihrer Lösung zu bereinigen. Dann entfernen und wieder Einheit hinzufügen.

Bei 99% kann das Problem " Datei oder Assembly konnte nicht geladen werden" oder eines der Abhängigkeiten nicht durch Abhängigkeiten verursacht werden! Ich schlage vor, Sie folgen diesen Schritten:

1. Laden Sie Dependency Walker von http://www.dependencywalker.com/ herunter.

2. Starten Sie Dependency Walker und öffnen Sie die DLL (in meinem Fall NativeInterfaces.dll)

3. Sie können eine oder mehrere DLLs mit dem Fehler in rot sehen. Fehler beim Öffnen der Datei ...

   

4. Dies bedeutet, dass diese DLL in Ihrem System fehlt. in meinem Fall ist der DLL-NameMSVCR71.DLL

5. Sie können Missings DLL von Google herunterladen und in den richtigen Pfad kopieren (in meinem Fall c:\windows\system32)

6. Zu diesem Zeitpunkt müssen Sie die neue DLL im GAC (Global Assembly Cache) registrieren: Öffnen Sie ein DOS-Terminal und schreiben Sie:

   cd \Windows\System32
   regsvr32 /i msvcr71.dll

7. Starten Sie Ihre Anwendung neu!

Microsoft Enterprise Library (von .NetTiers referenziert) war unser Problem, das wiederum auf eine ältere Version von Unity verwies. Um das Problem zu lösen, haben wir die folgende Bindungsumleitung in der web.config verwendet:

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

Alternativ können Sie die Unternehmensbibliothek auch einfach auf die neueste Version aktualisieren.

Das Folgende hat bei mir funktioniert.

• Temporäre Dateien entfernen C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporäre ASP.NET-Dateien
• Schließen Sie VSTS und öffnen Sie es erneut
• Entfernen und Hinzufügen derselben DLLs (Hinweis: Sie fügen dieselben passenden Versionen hinzu)

Überprüfen Sie die Datei Web.config / App.config in Ihrem Projekt. Überprüfen Sie, ob die Versionsnummern korrekt sind.

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

Das hat bei mir funktioniert.

Obwohl die ursprüngliche Frage vor fünf Jahren gestellt wurde, bleibt das Problem bestehen und ist ziemlich ärgerlich.

Die allgemeine Lösung ist eine gründliche Analyse aller Baugruppen, auf die verwiesen wird, um zu verstehen, was falsch läuft. Um diese Aufgabe zu vereinfachen, habe ich ein Tool (eine Visual Studio-Erweiterung) erstellt, mit dem Sie eine .NET-Assembly (a .dlloder ) auswählen können.exe Datei) , um eine grafische Darstellung aller referenzierten Assemblys zu erhalten und gleichzeitig widersprüchliche oder fehlende Referenzen hervorzuheben.

Das Tool ist in der Visual Studio-Galerie verfügbar: https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734

Beispiel für die Ausgabe:

Klicken Sie im Solution Explorer mit der rechten Maustaste auf das Projekt (nicht auf die Lösung) und wählen Sie auf der Registerkarte Build die Option Plattformziel: "Beliebige CPU".

Die Antwort von Juntos ist richtig, aber Sie sollten auch Folgendes berücksichtigen:

Für die Einheit v2.1.505.2 werden verschiedene AssemblyVersion- und AssemblyFileVersion- Attribute angegeben:

AssemblyFileVersion wird vom NuGet verwendet, aber CLR kümmert sich nicht darum! CLR wird nur AssemblyVersion verwenden !

Daher sollten Ihre Weiterleitungen auf eine Version angewendet werden, die im AssemblyVersion- Attribut angegeben ist. Daher sollte 2.1.505.0 verwendet werden

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

Siehe auch: Was sind die Unterschiede zwischen AssemblyVersion, AssemblyFileVersion und AssemblyInformationalVersion?

Ich habe auch diesen schrecklichen Fehler bekommen und eine Lösung dafür gefunden ...

1. Klicken Sie mit der rechten Maustaste auf den Lösungsnamen
2. Klicken Sie auf Clean Solution
3. Starten Sie Visual Studio neu
4. Gehe zu Projekteigenschaften >> Erstellen
5. Ändern Sie die Konfiguration in " Freigeben"
6. Starten Sie das Debuggen (F5)

1), 2)

4), 5)

Hoffe das wird dir auch helfen.

• Gehe zu: Lösung -> Paket
• Klicken Sie auf die Registerkarte Erweitert (Finden Sie unter der Seite)
• Fügen Sie Ihre DLL zu zusätzlichen Assemblys hinzu (auf diese Weise können wir externe DLLs in Sharepoint hinzufügen).

Ich bin mir nicht sicher, ob dies helfen könnte.

Überprüfen Sie, ob der Assembly-Name und der Standard-Namespace in den Eigenschaften in Ihren Assemblies übereinstimmen. Dies löste mein Problem, das den gleichen Fehler ergab.

In meinem Fall im bin-Ordner befand sich eine Nicht-Referenz-DLL namens Unity.MVC3. Ich habe erfolglos versucht, in Visual Studio nach einem Verweis darauf zu suchen. Daher war meine Lösung so einfach, diese DLL aus dem bin-Ordner zu löschen.

Danke Riddhi M. Im Anschluss hat für mich gearbeitet.

Temporäre Dateien entfernen C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporäre ASP.NET-Dateien Schließen Sie VSTS und öffnen Sie sie erneut. Entfernen und Hinzufügen derselben DLLs (Hinweis: Sie fügen dieselben übereinstimmenden Versionen hinzu.)

Sie sagen, Sie haben viele Projekte in Ihrer Lösung ... Nun, beginnen Sie mit einem Projekt ganz oben im Build-Auftrag. Lassen Sie dieses erstellen, und sobald Sie es herausgefunden haben, können Sie das gleiche Update auf den Rest anwenden.

Ehrlich gesagt müssen Sie wahrscheinlich nur Ihre Referenz aktualisieren. Es hört sich so an, als hätten Sie entweder Ihre Version aktualisiert und die Referenzen nicht aktualisiert, oder es handelt sich um ein relatives Pfadproblem, wenn Sie Ihre Lösung in der Quellcodeverwaltung behalten. Überprüfen Sie einfach Ihre Annahmen und fügen Sie die Referenz erneut hinzu.

Das Folgende hat bei mir funktioniert.

• Temporäre Dateien entfernen C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporäre ASP.NET-Dateien
  • Klicken Sie dann mit der rechten Maustaste auf Temporäre Asp.net-Dateien> Eigenschaften> Sicherheit und gewähren Sie den vollständigen Zugriff auf IIS und alle Benutzer, die mein Projekt ausführen

Dieses Problem trat bei mir auf, als eine meiner abhängigen Bibliotheken eine DLL mit "Beliebige CPU" kompilierte, als die übergeordnete Bibliothek eine Kompilierung von "x64" erwartete.

Ich hatte das gleiche Problem, das ich über die folgenden Anweisungen gelöst habe:

1. Öffnen Sie das Werkzeugmenü und wählen Sie die Option
2. In den Optionen gehen Sie zu Projekte und Lösungen / Webprojekte
3. prüfen use the 64bit version of IIS ...

Sie müssen Ihre Datei appname.dll aus Ihrem Ausgabeordner löschen. Bereinigen von Debug- und Release-Ordnern. Erstellen Sie die neu generierte DLL-Datei neu und kopieren Sie sie in den Ausgabeordner.

Ich "Als Startprojekt festlegen " die entladene / nicht gefundene Bibliothek / das Projekt.

Dann bereitgestellt.

Es funktionierte!

Ich denke, es konnte die DLL nicht finden, weil sie zuerst nicht in der Assembly war.

Eine weitere mögliche Ursache: Stellen Sie sicher, dass Sie nicht versehentlich beiden Projekten in den Projekteigenschaften denselben Assemblynamen zugewiesen haben.

Meine Lösung für .NET 4.0 unter Verwendung von Enterprise Library 5 bestand darin, einen Verweis auf Folgendes hinzuzufügen:

Microsoft.Practices.Unity.Interception.dll

Achten Sie auf widersprüchliche Referenzen. Auch nach einer Bereinigung und Neuerstellung verursachen widersprüchliche Referenzen immer noch ein Problem. Mein Problem war zwischen AForge und Accord. Ich habe beide Referenzen entfernt und die Referenzen erneut hinzugefügt, indem ich die bestimmte Referenz neu ausgewählt habe (speziell für meinen Fall, nur Accord).

Für mich hat das Wiederherstellen des Unity-Spiels ohne Unity C # Proects Checkmark funktioniert.

In meinem Fall hat keine der vorgeschlagenen Antworten funktioniert.

Folgendes hat bei mir funktioniert:

1. Entfernen Sie die Referenz
2. Benennen Sie die DLL um
3. Importieren Sie die Referenz erneut

Der zweite Schritt war anscheinend wichtig, da er ohne ihn nicht funktionierte.

Überprüfen Sie, ob die Eigenschaft "In lokale kopieren" für die Referenz auf "true" und die spezifische Version auf "true" festgelegt ist. Dies ist relevant für Anwendungen in Visual Studio.

Ich hatte das heute und in meinem Fall war das Problem sehr seltsam:

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

Beachten Sie die streunenden Zeichen am Ende des XML - irgendwie wurden diese von der Versionsnummer an das Ende dieses XML-Blocks verschoben!

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

Geändert zu oben und voila! Alles hat wieder funktioniert.

Wenn Sie diese Fehlermeldung erhalten, indem Sie eine Anwendung unter Windows XP öffnen, bedeutet dies, dass Sie diese App zuerst installiert haben, da sie ohne Net Framework 4 und Service Pack 3 nicht funktioniert. Sie haben beide installiert und erneut wird dieser Fehler angezeigt. Sie sollten diese App erneut installieren, aber zuerst von Hinzufügen und Entfernen deinstallieren

Wenn dies nicht funktioniert, missbrauchen Sie mich bitte nicht. Ich bin auch ein Junior