Replacing the Error 500 ASP Page - SourceSafe Integration
(Page 6 of 7 )
One of the more interesting aspects of adding a text editor to the web page itself is the way in which source-control fits in to the equation. At first glance, it would seem that editing in this manner would break many guidelines and best practices on source-control.
When examined in more detail, it is actually quite an appealing option. Although Source Safe is used as an example below, a source-control provider could potentially be used.
Firstly, as a file can be checked out, edited, and checked back in in quick succession, there is less likelihood of preventing other users from editing a file than is normally the case. Secondly, changes are often made to code to test it without actually checking the file out of SourceSafe.
When this is the case, there is potential for any changes made to be lost if the source-controlled version is checked out over the top of this file. The final, and possibly the biggest benefit is the ability to add comments to the file.
Whenever a change is made, the error message that the user is trying to correct, along with which machine the error was on, the server configuration, and so on, could all be stored as comments, providing in-depth auditing of bug-fixes to a system.
To achieve this functionality, there are two possibilities - either using the command-line SourceSafe tools, or using the SourceSafe object-model.
In the included source-code, the object model has been used for three reasons. Firstly, it is simply a COM object like any other, it’s designed just for automating tasks such as this, and provides greater functionality than the command-line version.
Secondly, running executables on unattended servers is never a wise thing to do as feedback via a UI may be required at some point, locking processes on the server until interaction is given. Finally, the IIS user must be given permissions to invoke executables if the command-line option is to be used.
This would create a potential security risk, giving more permissions than are strictly necessary to a guest user account.
Performing operations using the SourceSafe object-model requires only a couple of method calls. The code below gives an example of how to check out a file using this method:
Set objSS = Server.CreateObject("SourceSafeTypeLib.VSSDatabase")
objSS.Open INI_PATH, USERNAME, PASSWORD
objSS.VSSItem("c:\sslocal\test.txt").Checkout "", "", VSSFLAG_USERROYESAs can be seen from this code, in addition to knowing what file the action is to be performed on, there are four pieces of information that are required:
| VSSFLAG_USERROYES | This is constant informing SourceSafe that the ReadOnly flag on the file should be utilized |
| INI_PATH | This is the path to the srcsafe.ini file that contains the configuration data for the SourceSafe database |
| USERNAME | This specifies the username that all actions should be carried out under |
| PASSWORD | This parameter contains the password for the specified username. |
Using these values, and other methods, such as CheckIn and UndoCheckout, all of the necessary functions can be carried out on the file being edited. Unfortunately, some users may have problems instancing this object, with an error being raised of "Invalid Class String".
This error is generally due to permission problems with the anonymous user. If this is the case, then Read/Execute NTFS rights should be given to the user on the SSAPI.DLL file located in the folder "...\Program Files\Microsoft Visual Studio\Common\VSS\win32". Further information on this error can be found at the referenced URL given at the bottom of this article.
Alternatively, a couple of lines of text such as the following could be used to invoke the command-line version:
strCommand = "c:\...\Win32\ss.exe Checkout """ & strFileName & """ -GWR"
Set objShell = Server.CreateObject("WScript.Shell")
objShell.Run strCommand, 0, TrueThe ellipsis ("...") should be replaced with the path to SourceSafe's folder (usually "C:\Program Files\Microsoft Visual Studio\Common\VSS"), and the "Checkout" sub-string can be replaced with other command such as "Checkin" and "UndoRollback". For the command-line version to function correctly, several environment variables such as SSUSER and SSDIR should be set. For more information on this, see the reference towards the bottom of this article.
Multiple Platform SupportTo developers creating application with ASP that aren't targeting an HTML client, the standard error page regularly provides no real use at all, and can cause problems if the data it provides is not in the correct format.
For instance, an alternative use for ASP is the creation of WAP sites, where the target language is WML. Whilst the syntax of this language is similar to HTML, several errors will be generated if the standard HTML error page was sent to the client.
The first of these errors would be due to the size of the page -WML pages are limited to just a couple of kilobytes. Although this could be easily remedied with the error page displaying a reduced amount of information, this wouldn't solve the more important issue - the document would have the wrong content type, and would not be a valid WML compliant document.
To add support for WML (and potentially for more languages), the error page must detect the client that is requesting the information. This can be achieved by making use of the HTTP_ACCEPT Server-Variable. This value stores a comma-separated list of data-formats that are accepted by the client. For IE (and most other HTML browsers), this list includes "*/*". If this value occurs, then the HTML error page can be displayed, otherwise the WML error page can be rendered instead. In more complex systems, the supported formats of the individual browsers can be checked.
The ASP required to support the WML error page would be something similar to:
If InStr(Request.ServerVariables.Item("HTTP_ACCEPT"), "*/*")>0 Then
DisplayHTMLErrorPage
Else
Response.Write "<?xml version='1.0'?>"
Response.Write "<!DOCTYPE wml PUBLIC '-//WAPFORUM//DTD WML 1.1//EN'
'http://www.wapforum.org/DTD/wml_1.1.xml'>" & vbcrlf
Response.Write "<wml>" & vbcrlf
Response.Write " <head>" & vbcrlf
Response.Write " <meta http-equiv='cache-control' content='must-revalidate'/>" & vbcrlf
Response.Write " <meta http-equiv='pragma' content='no-cache'/>" & vbcrlf
Response.Write " </head>" & vbcrlf
Response.Write " <card id='Error' title='Error'>" & vbcrlf
Response.Write " <do type='prev' label='Back'><prev /></do>" & vbcrlf
Response.Write " <p>" & objASPError.Category & "</p>" & vbcrlf
Response.Write " <p>" & objASPError.Description & "</p>" & vbcrlf
Response.Write " <p>" & objASPError.ASPDescription & _
": Line " & objASPError.Line & "</p>" & vbcrlf
Response.Write " </card>" & vbcrlf
Response.Write "</wml>" & vbcrlf
End IfRather than providing one-off implementations such as this, an XML document describing the error that has occurred could be generated. The type of document that the client accepts could then be detected, with a specific XSLT transformation being applied for each. This would allow for debugging of systems developed for CHTML and iMode browsers amongst others.
Further ExtensionsAs described earlier, the e-mail functionality could be extended to provide support for full development teams - sending messages to the relevant developers, and creating entries into a bug-tracking system automatically, and adding comments to source-controlled files.
To do this, meta-information would need to be stored in the source-file, containing such information as the developer's name/username, which application the code was part of (this could probably be calculated from the IIS application name), etc.
Although the text editor makes quick-fixes very easy to carry out, it is less functional than the most basic implementation of Notepad. The addition of a go-to-line function would certainly help a lot, and the ability to set tab-indents, highlight the code, and so on would make this a viable second-choice development environment when it is known that there are several errors that all need correcting across a site.
To implement such features, it would be necessary to replace the Textarea element with an Active-X edit control, Flash/Java applet, or other program based on a richer language than HTML. There are several editors on the market that have Active-X interfaces - enabling them to be embedded in compliant environments (e.g. Delphi, Visual Basic, C++).
These can also be embedded into web pages, and a simple piece of DHTML to set the content of a hidden field to the value of the Active-X control's text before posting the form back would ensure the remainder of the implementation would still function as before.
A further issue that could be addressed by this page is in the transmission of error codes to client browsers. Internet Explorer v5.0 and above has settings that are enabled by default to "Show Friendly HTTP Error Messages". These messages over-ride error pages that are sent from the server, replacing their content with fairly generic information regarding errors.
These "friendly" pages are only displayed if an error code (a status other than 200) is sent to the client with the web page. If no call is made to Response.Status in the error page to specify an error code, then the browser will always display the content that is returned from IIS.
Next: Conclusion >>
More ASP Articles
More By Wrox Team
