get the solution


DLL Hell – Could not load file or assembly System.Web.http 4.0.0.0

By
on Regards: .NET Framework;

Bei einem Erstdeployment kann es zu unliebsamen Überraschungen kommen bei denen nicht sofort die Ursache erkennbar ist.

Besonders tragisch ist es, wenn die Fehlermeldung am Testsystem nicht am Entwicklungssystem reproduzierbar ist. Nach dem Installieren und Aufrufen der Applikation wird vom IIS die Fehlermeldung “Could not load file or assembly System.Web.http 4.0.0.0” ausgegeben.

Die StackOverFlow Antworten brachten keine Lösung, weshalb das Problem genauer anlysiert werden musste.

Das Testsystem war eine Windows Server 2003 Installation und siehe da, im GAC war tatsächlich die Datei nicht vorhanden. Der Global Assembly Cache ist dazu da, um Versionskonflikte zu vermeiden. Ein weiteres Feature vom GAC ist, das die Assemblies dort nativ vorliegen. Während der Installation vom .NET Framework werden die Assemblies prozessoroptimiert kompiliert und sind dann in nativem Code verfügbar. Das heißt die Bibliotheken können um einiges schneller gestartet werden, als die “üblichen” welche in der Common Intermediate Language vorliegen und mit dem JIT ausgewertet werden.

Wie auch immer, nach Recherechen hat sich dann herausgestellt, dass genau diese File und noch ein paar Andere auf Server Installationen nicht ausgeliefert werden (Security Issues).

Also habe ich die Option Copy to Local im Visual Studio auf true gesetzt. Auch das zeigte keinen Effekt. Somit löschte ich die Referenz und kompilierte nochmal das Projekt auf dem Entwicklungssystem. Trotz der Änderung kam am Testsystem nach wie vor die Fehlermeldung. Also die Änderung wieder Rückgäng machen und die Referenz System.Web.http zum Projekt hinzufügen.

Nach dem die Projekt-Referenzen genauer unter die Lupe genommen wurden, fiel eine Third Party Referenz auf, die eine Abhänigkeit auf System.Web.http hatte. Außerdem waren die referenzierten Versionen auf System.Web.http der Lib und der Web Application unterschiedlich. Es wurden deshalb alle Referenzen von System.Web.Http zunächst einmal auf die Version upgedated welche die Third Party Lib verwendete. In der web.config ist auch der Eintrag

 < dependentAssembly>
    < assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    < bindingRedirect oldVersion="0.0.0.0-5.3.0.0" newVersion="5.3.0.0" />
 < / dependent Assembly > 

interessant. Den dieser ist dafür verantwortlich, dass wenn keine geeignete Assembly Version gefunden wird, ein Fallback auf den GAC passiert. Genau das ist auf der Testmaschine passiert. Die Assembly System.Web.http war im bin Folder der Web Application vorhanden, aber aufgrund des web.config Eintrag wurde stattdessen auf den GAC zurückgegriffen. Da auf der Windows Server Installation die File nicht existierte, kam die Fehlermeldung. Auf dem Entwicklungsystem waren beide Assembly Versionen vorhanden, weshalb der Fehler so nicht reproduzierbar war.

Nachdem bei allen Projekten die Referenzen auf die korrekte Assembly Version verwiesen haben kam immer noch die Fehlermeldung System.Web.Http 4.0.0.0 wurde nicht gefunden, obwohl die neue Assembly Version 5.3.0.0 lauten sollte. Nach weiterem suchen, hat sich herausgestellt, dass die Projektdateien im Visual Studio zwei Referenzen auf die gleiche Assembly hatten mit jeweils der unterschiedlichen Assembly Version. In diesem Fall hat die Visual Studio GUI die falsche Information angezeigt. Das Visual Studio Projekt musste also ungeloaded werden und in der xml Ansicht nachbearbeitet um die alten Assembly Verweise zu löschen. Der Fehler könnte von einem auto. TFS merge stammen.

In diesem Fall haben mehrere ungünstige Faktoren zusammengespielt.