blog.yots.de

Wird bei einem selbsterstellten .NET COM Interop, beim ersten Instanziieren eines neuen Objektes auf einer ASP Seite der folgende Fehler geworfen:

AspCode: ASP 0177
Source: Server object
Description: Server.CreateObject Failed. 8000ffff

Könnte eine fehlende Berechtigung in der Registry die Ursache sein.

Ein Fehlerreport mit Quellcode zum Reproduzieren der Fehlers kann hier nachgelesen werden : KB937143 breaks ASP to .NET COM Interop

It seems strange an IE7 update is affecting .NET interop to ASP, but it is.

Achja, wie ich komplexe Software doch liebe
Der für mich akzeptabelste Workaround befindet sich am Ende der Comments:

Also wanted to note that the exact same problem just happened with our App in Server 2008/IIS7 and the same workaround fixed the problem. I simply had to give the IUSR account (or whomever the site is running as) Read access to HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones all fixed...

Gesagt, getan und zu Ende war ein tagelanges Martyrium. 

 

Will man unter ASP Classic erreichen, dass auch Sessioncookies über den sicheren SSL Kanal übermittelt werden, muss man erst in der Metabase die Eigenschaft “AspKeepSessionIDSecure” setzen.

Eine Beschreibung gibt es hier - AspKeepSessionIDSecure Metabase Property (IIS 6.0)

Heute mal wieder zwei Links für Leute die noch ASP Classic Projekt betreuen.

• Ajaxed - Ein Projekt das die ähnliche Funktionalität bereitstellen will, wie xajax für PHP

• CLASP 2.0 - ein ASP.NET ähnliches Framework für ASP Classic. Schaut sehr vielversprechend aus. Leider ist wegen der Schließung von GotDotNet gerade kein Download möglich.
Ich habe bei den Betreuern angefragt, ob es eine alternative Downloadmöglichkeit gibt. Mal sehen ob jemand antwortet

Kleiner Tipp, wer Unit Tests unter ASP Classic schreiben will, wird beim Projekt ASPUnit fündig.

Das letzte Update ist zwar schon fast 3 Jahre zurück, aber ASPUnit lies sich schnell und zweckmäßig in ein größeres Projekt einbinden. Der Quellcode ist auch überschaubar, so dass Änderungen oder Erweiterungen bei Bedarf schnell eingebaut werden können.

ASP.NET ist ja schön und gut, aber es gibt ja immer noch Projekte die in ASP Classic geschrieben sind und da hat man bei XP-Home (gerade bei billigeren Laptops sehr verbreitet) ein Problem: Kein IIS/Personal Webserver unter XP-Home.
Bei der Suche nach Alternativen, bin ich auf den Quick ‘n Easy Web Server Professional gestoßen.
Nach einigen kurzen Tests mit anderen Tools hat er sich als einzige gangbare Lösung herausgestellt.
Er ist bestimmt nicht als Ersatz für einen IIS zu sehen, aber als Entwicklungssystem und zum Vorzeigen beim Kunden durchaus brauchbar.

Das Schöne an der Sache war:
– Projekt aus Subversion ausgecheckt
– "Quick ‘n Easy Web Server" gestartet
– 90% der Seiten gingen auf Anhieb ohne Codeanpassung
Aber wie es im Programmieralltag so ist, sind die letzten 10% immer die kompliziertesten.

Bei den restlichen Seiten hatte ich abstruse Fehlermeldungen der Art:
Script error detected at line XXXX.
Source line: Response.write "
Description: Nicht abgeschlossene Zeichenfolgenkonstante

Im IIS hingegen funktionierte alles wunderbar.
Nach stundenlangem Suchen bin ich dann dahinter gekommen, dass der Webserver wohl nicht mit Dateien umgehen kann, die unter Linux erstellt wurden. Als ich dann meine paar Include Dateien konvertiert hatte, die Unix Zeilenumbrüche enthielten, liefen auch die restlichen Seiten ohne Probleme.
Hätte ich das vorher gewusst, hätte die ganze Umstellung für den Test nur 1 Minute gedauert.

Daher kann ich bisher, von meiner Seite aus, nur ein positives Fazit ziehen.

Vorteile
• Läuft unter XP-Home
• So gut wie keine Anpassungen am Quellcode notwendig
• Leichte Konfiguration

Nachteile
• Zeilennummer stimmt nicht bei Fehlermeldungen
• Dateiname wird bei Fehlermeldung nicht angezeigt, was bei der Fehlersuche richtig stört
• Kostet Geld (aber mit 29,95$ durchaus vertretbar)
• Unterstützt nicht alle Funktionen eines IIS, es ist also vom Projekt abhängig ob der Webserver als Alternative in Frage kommt

Super da sitze ich hier und grübele warum ich keine Dateien in einem Webprojekt ansahen kann, die in einem Verzeichnis "App_data" liegen (wohlgemerkt keine ASP.NET Anwendung) bis mir dann doch noch der Gedanke kam, dass Microsoft den Zugriff auf den App_Data Ordern bestimmt mit einem ISAPI-Filter realisiert hat. Und tatsächlich - den ASP.NET ISAPI Filter rausgeschmissen und schon klappst mit dem Dateien. Ist die Welt nicht wunderbar.