Thomas Bandt

Remove HttpHandler Bug immer noch nicht beseitigt!?

HttpHandler sind für einen ASP.NET-Entwickler ein schönes Werkzeug um allerlei Sachen über HTTP zu machen, für die eine "richtige Website", also in unserem Fall ein WebForm, einfach zu viel Overhead mitbringt, oder garnicht angebracht ist (Streamen von Dateien z.B.).

Nun gibt es 2 gängige Wege einen HttpHandler zu nutzen:

1. Man legt sich ein *.ashx-File an und schreibt seinen Code dort rein bzw. referenziert ihn.
2. Man spart sich die Datei, die im Normalfall eh nur ein Platzhalter ist, und registriert den Handler in der Web.config:

<httpHandlers>
  <add verb="GET" path="Download.ashx" type="Acciado.Frontend.Kernel.UI.Downloads.StreamFile, Acciado.Frontend.Kernel" />
</httpHandlers>

Das funktioniert bestens, bis zu einem Punkt. Legt man sich nämlich unterhalb der Anwendung, in der dieser Handler registriert ist, eine weitere Applikationi an, also beispielsweise

http://<RootApp>/<SubApp>

dann kracht es. Und zwar dann, wenn die referenzierte Assembly, in dem Fall also "Acciado.Frontend.Kernel", nicht in <SubApp> verfügbar ist.

Normalerweise sollte man nun den Handler aus der übergeordneten Anwendung mittels

<remove verb="*" path="Download.ashx" />

einfach entfernen können, aber das funktioniert schlicht und ergreifend nicht.

Das Problem besteht seit Ewigkeiten, unter anderem habe ich hier einen Beitrag von 2004, also von vor 4 Jahren!, gefunden. Es war für mich nur bisher nicht relevant, weil ich die Bibliotheken zw. den 2 Webanwendungen nicht getrennt habe. Gerade eben habe ich diese Trennung vollzogen, und nun kracht es.

Was gibt es für Workarounds?

1. Man legt eine Assembly gleichen Namens in die SubApp. Diese kann theoretisch leer sein, es muss also nicht das Original sein.
2. Man verwendet die Original-Assembly in beiden Webs, referenziert sie also 2x.
3. Man verzichtet auf die globale Registrierung in der Web.config und legt sich stattdessen eine *.ashx-Datei in die Root-Anwendung.

Alles in allem ziemlich bescheidene Optionen, aber ich werde nun wohl zu 1. oder 3. greifen.

Meine Meinung:

Es regt mich auf. Das ist ein wirklich bekannter und gleichzeitig banaler Bug, den wir nun schon seit Jahren, wenn nicht seit Anbeginn, mit uns herumschleppen. Es ist nichts Dramatisches, aber es zeigt in meinen Augen ganz gut, was derzeit in der Entwicklung von ASP.NET passiert: nämlich nicht viel.

Es wird zwar an der hundertsten Datenzugriffstechnologie seit Bestehen von .NET gearbeitet, es wird ein zweiter Weg zum WebForm-Modell eingeschlagen (MVC), aber den Kern lässt man so stehen wie er ist. Auch in Sachen Controls ist seit ASP.NET 2.0 so gut wie nichts geschehen.

Zwar bietet ASP.NET wirklich alle Voraussetzungen um für einen geübten Entwickler schnell und einfach neue Controls zu entwickeln, aber was spricht denn dagegen den bestehenden Standardsatz an fertigen Controls einmal zu erweitern und zu verbessern?

Es sind oft Kleinigkeiten die nerven, aber augenscheinlich hat man in Redmond in den letzten Jahren besseres zu tun als sich um sein angebliches Flaggschiff in der Webentwicklung zu kümmern.

Just my 2 cents.