Ein weiteres Problem über log4net 1.2.11 Konflikte

Question

Ich habe die letzten 2 Stunden damit verbracht, über diese Probleme auf SO zu schauen, und nichts scheint zu funktionieren.

Ich habe eine Lösung, die log4net 1.2.11 verwendet, über NuGet. Es funktioniert gut auf meiner 32-Bit-Entwicklungs-Workstation mit Windows 7. Es läuft nicht auf meinem 64-Bit Windows 2008 R2-Testsystem. Der Fehler, den ich bekommen ist:

Unbehandelte Ausnahme: System.IO.FileLoadException: Konnte Datei oder Assembly 'log4net, Version = 1.2.11.0, Culture = neutral, PublicKeyToken = 669e0ddf0bb1aa2a' oder eine ihrer Abhängigkeiten laden. Die Manifestdefinition der lokalisierten Assembly stimmt nicht mit der Assemblyreferenz überein.

Ich suche im Anwendungsverzeichnis auf meinem Testsystem. Die log4net.dll Datei dort ist Version 1.2.11.

Die Version in der GAC war Version 1.2.10. Ich habe es entfernt. Es gab eine Version auf meinem Entwicklungsserver, die wieder etwas anderes war; Ich habe das auch entfernt. Ich habe umgebaut; Ich habe mich umgezogen. Ich habe hinzugefügt

<dependentAssembly> 
    <assemblyIdentity name="log4net" publicKeyToken="669E0DDF0BB1AA2A" culture="neutral"/> 
    <bindingRedirect oldVersion="0.0.0.0-1.2.10.0" newVersion="1.2.11.0"/> 
</dependentAssembly> 

in meine Konfigurationsdatei. Nichts scheint einen Unterschied zu machen. Mein Bereitstellungsprojekt zeigt die richtige Version und Signatur der bereitgestellten log4net-Assembly an.

Ich weiß nicht, was ich noch tun kann, aber ich bin ziemlich frustriert, dass eine Protokollierungsbibliothek verhindert, dass meine Anwendung ausgeführt wird.

Was habe ich verpasst?

Answer 1

Hier war meine Lösung: Ich wechselte von log4net zu Common.Logging zu NLog. Es hat nicht viel Mühe gekostet, und ich denke nicht, dass es nötig gewesen wäre, aber es hat funktioniert und es hat gut funktioniert.

Answer 2

Wir haben genau das gleiche Problem. Eine Abhängigkeit tief in der Codebasis setzt 1.2.10 in den GAC und NuGet versucht 1.2.11 zu verwenden. Wir haben die Verwendung von NuGet für log4net aufgegeben, zu viele Kopfschmerzen. Scheint NuGet ist ein bisschen alles oder nichts.

Answer 3

Ich hatte dieses Problem nach dem Upgrade von log4net durch NuGet, nur um festzustellen, dass die neuere Version mit einem anderen Schlüssel signiert wurde. Seufzer. Aus irgendeinem Grund wurde dies erst bei der Bereitstellung auf dem Live-Server offensichtlich, es kam jedoch nicht in der Entwicklung vor.

Sie können die 'Oldkey' Version von the apache log4net site greifen. Nukiere einfach deine Referenzen aus der Projektdatei und referenziere stattdessen die oldkey-Version.

Answer 4

Manchmal muss man wirklich in die Projektabhängigkeiten einsteigen. In meinem Fall war es eine Referenz einer Referenz des aktuellen Service Stack-Projekts, die auf eine andere Version von Log4Net Bezug nahm.

Um es zu beheben, habe ich die neueste Version von Log4Net von Nuget zum ServiceStack-Projekt hinzugefügt. Ich habe auch sichergestellt, dass die direkte Referenz die neueste Version verwendet und das Problem gelöst wurde.

Sie können ein Abhängigkeitstool verwenden, um schnell zu finden, welche Verweise in Konflikt stehende Versionen verwenden. Wenn Sie jedoch kein Tool dafür haben, können Sie den Verweis des Projekts selbst kompilieren und sehen, welche Version von log4net.dll kopiert wird in das Verzeichnis.