rdb: Debugging von vorgeführtem (klassischem) ASP – Open Text Web Solutions Usergroup e.V.

  • RedDot CMS Blog
  • 15.11.2019
  • DE

rdb: Debugging Pre-Executed (classic) ASP

Das Problem

Ich bin mir sicher, dass so ziemlich jeder RedDot CMS Web Solutions Management Server-Entwickler in seinen Vorlagen auf einige pre-executed ASP gestoßen wäre, die fehlgeschlagen sind. Die daraus resultierende Frustration, keine integrierte Methode zum Debuggen zu haben oder einfach nur eine aussagekräftige Fehlermeldung aus dem CMS-WSMS zu erhalten, ist eines der am meisten diskutierten Ärgernisse des Produkts. Sicher, es gibt das Pre-Execute Debugger Plug-In, aber um das zu verwenden, müssen Änderungen am RDServer vorgenommen werden.ini-Datei. Diese Änderungen können ein Projekt unbrauchbar machen oder sogar den RedDot CMS Web Solutions Management Server … err … Server zum Absturz bringen (ich habe beide Szenarien mehrmals erlebt). Letzteres kann natürlich durch einen Neustart behoben werden, aber wenn dies ein ausgelastetes Produktionssystem ist, ist das einfach nicht praktikabel.

Sicherlich muss es eine Möglichkeit geben, diese Fehler aus dem System und zurück zum Entwickler zu bekommen?

Die Lösung

Ich weiß nicht, ob ich die erste Person bin, die darüber nachdenkt, aber ich habe es noch nicht gesehen, also ist dies hoffentlich eine nützliche Information.

Einige Hintergrundinformationen

Vorab ausgeführtes ASP wird von CMS WSMS gerendert, bevor es zur Ausführung an IIS übergeben wird. Der resultierende Code wird zur Aufnahme in die Seite an CMS WSMS zurückgegeben. Obwohl Sie es nicht sehen, wird ein 500-Fehler von IIS generiert, wenn der ASP fehlschlägt. Leider gehen diese Informationen über den 500-Fehler verloren, wenn Daten zwischen CMS WSMS und IIS und wieder zurück übertragen werden.

Geben Sie die benutzerdefinierte Fehlerseite ein

Unter IIS ist es möglich, für jeden Fehlertyp, der auf dem Webserver auftritt, eine benutzerdefinierte Fehlerseite festzulegen. Dies wird traditionell verwendet, um Endbenutzern eine aussagekräftige 404-Seite auf veröffentlichten Websites bereitzustellen. Wir können diese Funktionalität nutzen, um eine benutzerdefinierte Fehlerseite für einen 500-Fehler auf dem CMS WSMS-Server festzulegen. Darüber hinaus haben die Leute bei Microsoft ihren Weg frei gesehen, um auch ein Fehlerobjekt bereitzustellen, das nur ab einem 500-Fehler verfügbar ist und eine Reihe nützlicher Informationen über den Fehler zurückgibt. So können wir die Fehlerinformationen erfassen und in einer Datei protokollieren.

Der Prozess

Als erstes müssen wir einige Ordner erstellen.

  1. Erstellen Sie unter Ihrem CMS-WSMS-Ordner (CMS/ASP) einen Ordner mit dem Namen „PreExecute“.
  2. Erstellen Sie unter dem neuen Ordner zwei weitere mit den Namen „logs“ und „asp“. Das IUSR-Konto des Computers sollte Schreibzugriff auf beide Ordner haben.

Als nächstes müssen wir die Einstellungen RDExecute und PreExecute .

  1. Wählen Sie in Ihrem Projekt unter „Projekteinstellungen verwalten“ > „Projekt“ > „Allgemeine Einstellungen“ die Option „Einstellungen bearbeiten“ aus dem Aktionsmenü.
  2. Setzen Sie unter „RDExecute und PreExecute settings“ den „Physical path“ auf „C:\Program Files \ RedDot \ CMS \ ASP \ PreExecute\ asp“ (oder der Pfad zu Ihrem Ordner, wenn Ihre Installation anders ist) und das „Virtuelle Verzeichnis (IIS)“ zu „/ CMS / PreExecute / asp/“

Überprüfen Sie zu diesem Zeitpunkt, ob Ihre Vorausführung in Ihrem Projekt noch funktioniert.

Um nun den benutzerdefinierten Fehlerhandler zu erstellen.

  1. Erstellen Sie eine ASP-Datei in Ihrem Ordner CMS/ ASP/PreExecute/asp , nennen Sie sie wie Sie möchten, so etwas wie ASPError .ASP.
  2. Kopieren Sie den folgenden Code in die Datei: 
    <% ' Create the error object. Dim objASPError Set objASPError = Server.GetLastError ' Write the error information to a file (formatting of the second argument is for readability only). WriteToFile "C:\Program Files\RedDot\CMS\ASP\PreExecute\logs\PreExecuteErrors_" & Year(Now) & Month(Now) & Day(Now) & ".log", " Date/Time: " & Now() & vbCrLf & " ASP Code: " & objASPError.ASPCode & vbCrLf & "ASP Description: " & objASPError.Description & vbCrLf & " Category: " & objASPError.Category & vbCrLf & " Column: " & objASPError.Column & vbCrLf & " Description: " & objASPError.Description & vbCrLf & " File: " & objASPError.File & vbCrLf & " Line: " & objASPError.Line & vbCrLf & " Number: " & objASPError.Number & vbCrLf & " Source: " & objASPError.Source & vbCrLf & "############################################################" & vbCrLf, True Function WriteToFile(FileName, Contents, Append) On Error Resume Next If Append = True Then iMode = 8 Else iMode = 2 End If Dim oFs, oTextFile Set oFs = Server.CreateObject("Scripting.FileSystemObject") Set oTextFile = oFs.OpenTextFile(FileName, iMode, True) oTextFile.Write Contents oTextFile.Close Set oTextFile = Nothing Set oFS = Nothing End Function %>

Schließlich müssen wir IIS konfigurieren.

  1. Wählen Sie im IIS-Manager den Ordner unter „Standardwebsite“ (oder der für CMS-WSMS verwendeten Site) > „CMS“ > „PreExecute“ > „asp“ aus.
  2. Klicken Sie mit der rechten Maustaste auf den Ordner und wählen Sie „Eigenschaften“.
  3. Wählen Sie die Registerkarte „Benutzerdefinierte Fehler“. Scrollen Sie nach unten, bis Sie in der Spalte HTTP-Fehler „500; 100“ finden.
  4. Markieren Sie es und klicken Sie auf „Bearbeiten…“.
  5. Ändern Sie den „Nachrichtentyp:“ in „URL“ und setzen Sie „URL:“ auf „/CMS/PreExecute/asp/ASPError.asp“

Testen

Zum Testen ist es ziemlich einfach. Angenommen, Ihre Vorausführung funktionierte früher, sollten Sie in der Lage sein, Ihrer Vorlage fehlerhaften ASP-Code hinzuzufügen (z. B. <!IoRangePreExecute><%= functionThatDoesNotExist() %><!/IoRangePreExecute>) und Vorschau der Seite. Sie sollten die standardmäßige (unbrauchbare) CMS WSMS-Fehlerseite erhalten, aber Sie sollten auch eine Protokolldatei erhalten, die in Ihrem Ordner CMS / ASP / PreExecute / logs mit detaillierten Informationen über den aufgetretenen ASP-Fehler erstellt wurde.

Warnungen

Wenn Sie ein geclustertes CMS-WSMS ausführen, sollten Sie mit diesem Verfahren vorsichtig sein. Als ich versuchte, die Einstellungen vor der Ausführung in einer geclusterten CMS-WSMS-Umgebung zu ändern, funktionierte dies nicht nur nicht, sondern unterbrach auch die Veröffentlichung ALLER Projekte. Ich habe dies zu diesem Zeitpunkt nicht weiter untersucht, wenn und wann ich es tue, werde ich meine Ergebnisse veröffentlichen.

ASP.NET

Die oben beschriebene Methode funktioniert nur für klassisches ASP. Es wäre großartig, wenn jemand den äquivalenten Prozess für beschreiben würde ASP.NET . Irgendwelche Abnehmer?

Write a Comment

Deine E-Mail-Adresse wird nicht veröffentlicht.