- RedDot CMS Blog
- 15.11.2019
- PL
rdb: debugowanie Pre-Executed (classic) ASP
Problem
jestem pewien, że prawie każdy programista RedDot CMS Web Solutions Management Server napotkałby pewne pre-executed ASP w swoich szablonach, które nie powiodły się. Wynikająca z tego frustracja na brak wbudowanej metody debugowania, a nawet po prostu uzyskanie jakiegoś znaczącego Komunikatu o błędzie z CMS WSMS jest jedną z najczęściej omawianych irytacji produktu. Oczywiście, istnieje Pre-Execute Debugger plug-In, ale aby go użyć, należy wprowadzić zmiany w RDServer.plik ini. Zmiany te mogą sprawić, że projekt stanie się bezużyteczny lub nawet zawiesi serwer zarządzania rozwiązaniami webowymi RedDot CMS …err… server (wielokrotnie doświadczyłem obu scenariuszy). To ostatnie oczywiście można naprawić przez restart, ale jeśli jest to zajęty system produkcyjny, to po prostu nie jest praktyczne.
na pewno musi być jakiś sposób na pozbycie się tych błędów z systemu i powrót do programisty?
rozwiązanie
Nie wiem, czy jestem pierwszą osobą, która o tym myśli, ale nie widziałem tego wcześniej omawianego, więc mam nadzieję, że to przydatne informacje.
niektóre Tło
Wstępnie wykonane ASP jest renderowane przez CMS WSMS przed przekazaniem do IIS do uruchomienia. Otrzymany kod jest przekazywany z powrotem do WSMS CMS w celu włączenia na stronie. Chociaż nie widzisz go, jeśli ASP nie powiedzie się, błąd 500 jest generowany przez IIS. Niestety, ta informacja o błędzie 500 jest tracona, ponieważ dane są przekazywane między CMS WSMS a IIS iz powrotem.
wejdź na stronę błędu niestandardowego
w ramach usług IIS można ustawić stronę błędu niestandardowego dla każdego typu błędu występującego na serwerze WWW. Jest to tradycyjnie używane, aby zapewnić użytkownikom końcowym znaczącą stronę 404 w opublikowanych witrynach internetowych. Możemy wykorzystać tę funkcję, aby ustawić niestandardową stronę błędu dla błędu 500 na serwerze CMS WSMS. Oprócz tego ludzie w firmie Microsoft widzieli, jak wyraźnie udostępniają obiekt błędu, który jest dostępny tylko z błędu 500 i zwraca kilka przydatnych informacji na temat błędu. W ten sposób możemy przechwycić informacje o błędzie i zalogować je do pliku.
proces
pierwszą rzeczą, którą musimy zrobić, to utworzyć kilka folderów.
- w folderze CMS WSMS (CMS/ASP) utwórz folder o nazwie „PreExecute”.
- w nowym folderze utwórz dwa kolejne o nazwie „logi” i „asp”. Konto IUSR urządzenia powinno mieć dostęp do zapisu do obu folderów.
następnie musimy ustawić ustawienia RDExecute i PreExecute.
- w swoim projekcie, w sekcji „Administruj ustawieniami projektu” > „projekt” > „Ustawienia Ogólne”, wybierz „Edytuj ustawienia” z menu Akcja.
- w „Ustawieniach RDExecute i PreExecute” Ustaw „ścieżkę fizyczną” na „C:\Program Files \ RedDot\CMS \ ASP \ PreExecute \ asp „( lub ścieżka do folderu, jeśli instalacja jest inna) i ” Virtual directory (IIS)” do ” / CMS / PreExecute / asp/”
w tym momencie sprawdź, czy Twoja wstępna realizacja nadal działa w Twoim projekcie.
teraz, aby utworzyć niestandardową obsługę błędów.
- Utwórz plik ASP w folderze CMS/ASP/PreExecute/asp, nazwij go jak chcesz, coś w rodzaju ASPError.asp.
- skopiuj następujący kod do pliku:
<% ' 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 %>
na koniec musimy skonfigurować usługi IIS.
- w Menedżerze internetowych usług informacyjnych (IIS) wybierz folder w obszarze „Domyślna witryna internetowa” (lub dowolna witryna używana do CMS WSMS) > „CMS” > „PreExecute” > „asp”.
- kliknij prawym przyciskiem myszy folder i wybierz „Właściwości”.
- wybierz kartę” błędy niestandardowe”. Przewiń w dół, aż znajdziesz „500;100” w kolumnie błędów HTTP.
- zaznacz go i kliknij ” Edytuj…”.
- Zmień „Message type:” na ” URL „i ustaw” URL: „na” / CMS / PreExecute/asp / ASPError.asp”
testowanie
aby przetestować, jest to dość proste. Zakładając, że Twoje wstępne wykonanie działało wcześniej, powinieneś być w stanie dodać trochę zepsutego kodu ASP do szablonu (np. <!IoRangePreExecute> < % = functionThatDoesNotExist() %><!/ IoRangePreExecute>) i Podgląd strony. Powinieneś uzyskać standardową (Czytaj bezużyteczną) stronę błędu CMS WSMS, ale powinieneś również uzyskać plik dziennika utworzony w folderze CMS/ASP/PreExecute/logs ze szczegółowymi informacjami o błędzie ASP, który wystąpił.
Ostrzeżenia
jeśli używasz klastrowego CMS WSMS, możesz być ostrożny z tą procedurą. Kiedy próbowałem zmienić ustawienia pre-execution w klastrowym środowisku CMS WSMS, nie tylko nie działało, ale także usunęło publikację wszystkich projektów. Nie zbadałem tego dalej na tym etapie, jeśli i kiedy to zrobię, opublikuję moje wyniki.
ASP.NET
metoda opisana powyżej działa tylko dla klasycznych ASP. Fajnie by było, gdyby ktoś opisał proces równoważny dla ASP.NET jacyś chętni?
