While ASP is not difficult, you may find that the UAG code files may still be a bit challenging to read because every script links to several other files, most of which link to others as well. This means you may often have to hunt through a handful of files to find a certain function and what it does. Some people prefer the use of advanced tools such as Visual Studio, and others are just fine with Notepad, but keep in mind that installing additional software on UAG is not supported. Some stuff is more benign, but be careful not to jeopardize server stability, and if you really feel you MUST install additional stuff, try to at least limit it to non-production servers.
Out of the box, UAG is not set up for easy debugging, but there are a few things you can do to make things work your way. The first step is to enable verbose output of ASP errors, which can be done by executing the following command from an elevated command prompt on a UAG server:
cscript %systemdrive%\inetpub\adminiscripts\adsutil.vbs set w3svc/AspScriptErrorSentToBrowser true
Note
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com. If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.
You will then also need to set up the browser on the client to not Show friendly HTTP error messages, so make sure that this box is not selected, as shown in the following screenshot:
 |
If you are debugging a production server, keep in mind that the errors may reveal sensitive info to the end user, so be sure to turn the verbosity back off when finished by running the same script with the keyword FALSE.
Naturally, you can add more output to the ASP code with the response.write method and that's probably the easiest way to know what the server is doing and to isolate issues. In cases where the processing is in the background, or too fast to read, you might be able to use a tool such as HTTPWatch or FIDDLER to record the client-side activity, and then go over the source to find your messages. In case where even this is not suitable or to debug production servers, another tool at your disposal is the TRACE functions that are part of UAG's code.
UAG has a code file named trace.inc, which has several functions that integrate with the ASP code to collect data. To use them, all you have to do is add a line of code into your customization using the following format:
light_trace "what I gotta say"
You will see no visible output, but if you turn on a server trace, the resulting trace will show the text. Naturally, to make it helpful, be sure to put the right data in the trace text. For example:
light_trace "Custom PostPostValidate.inc: Entering function 'Read Lips' at " & now & " for user " & username
Once you have implemented such trace instructions, turn on UAG tracing, with InternalSite tracing, and you should see your messages in the decoded trace data.
For more information, see the following blog post:
http://blogs.technet.com/b/ben/archive/2011/08/08/enhanced-tracing-for-asp-debugging.aspx.