- Mastering Microsoft Forefront UAG 2010 Customization
- Erez Ben-Ari Rainier Amara
- 548字
- 2021-08-20 15:46:53
Reading, editing, and debugging ASP code
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
Tip
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.
- 中國新股民必讀手冊(2015年最新版)
- 審計學
- Splunk:Enterprise Operational Intelligence Delivered
- 審計綜合模擬實訓
- 財務審計實務指南
- Microsoft System Center Data Protection Manager 2012 SP1
- 中國政府統計問題研究
- 2016年度注冊會計師全國統一考試專用輔導教材(圖解版):審計
- Microsoft Dynamics NAV
- 新編統計學
- 陜西國家統計調查市、縣優秀報告集萃(2006—2015)(上下)
- 中國審計市場:制度變遷與競爭行為
- Big Data Analytics with R and Hadoop
- Oracle E-Business Suite Financials R12:A Functionality Guide
- Microsoft Dynamics CRM 2016 Customization(Second Edition)