在防範 XSS 攻擊時，常常教導同事，要將輸出的字串 Encode, 例如
在Web Form的寫法實在太長了，而MVC 的寫法稍為短了一些，但也好不到哪裡去。
因此，在 ASP.NET 4 中介紹了新的語法 <%: … %>
上述的後兩個範例就可以簡寫成
<%: myString %>
大幅地縮短了 coding 時間。真是好設計。
在 master page 中使用資源，如 image, js 等，需要更多的技巧。
舉例來說，在 aspx 中引用 image 是相當簡單的事
<td background=”./imgs/a.jpg”>
只要該頁面與 a.jpg 的相對位置是固定的即可。
而 master page 是要給每個頁面 (aspx) 來套用版型的，在 master page 中引用 image 會面臨相對位置不固定的問題。
解決方法是：
<td background='<%=ResolveUrl("~/imgs/a.jpg") %>' >
如果要使用在 css block 時，可使用如下的寫法
<style>
.def02 {
background-image: url(<%= Page.ResolveUrl("~/imgs/a.jpg") %>);
}
</style>
繼上一次 CAT.NET 初用後，又使用不少次。原因當然還是要幫同事找出 Sql Injection 的問題。
找出 Sql Injection 漏洞根本不是人做的，因為我們無法像父母親照顧小孩一樣，隨著專案不同階段來檢查專案的程式碼是否有 Sql Injection 問題。
而 CAT.NET 除了可以幫我們找出該類的問題外，更可以與開發工具結合，直接與顯示出問題發生的路由。
可惜的是，CAT.NET 工具非常秏記憶體，而一個 32 位元的程式，預設只能吃到 2GB。又與 Visual Studio 結合後，最多只能吃到 1.2 GB 左右而已。
為了解決這個問題， CAT.NET 出了 64 位元版，該版本就是要解決記憶體不足的issue。但，Visual Studio 並沒有 64位元版。換句話說，CAT.NET 64 bit version 無法與Visual Studio 結合，這是該版本的一大不方便的地方。
使用 64 位元版，只能使用 command line 的方式來執行。說明文件，則可以解壓縮後找到 CAT.NET.chm。該說明相當詳細了，不必在這裡重複。
我最常用的指令，如下。意思是找到 c:\dll 下所有的 dll ，分析後將報告輸出成 c:\dll\report.xml。
CATNETCmd64 /file:C:\dll\*.dll /report:c:\dll\report.xml
最後，將該 xml 改套用 \CATNETx64CTP\CAT.NET\Config\report.xsl ，即可看到輸出的報表。也就是加入 xml-stylesheet 這一行於 xml 檔。
<?xml version="1.0" encoding="utf-8"?> <?xml-stylesheet type="text/xsl" href="report.xsl" ?> <Report xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <Analysis>
後記:
讀者問到：「如果專案是以網站(WebSite)的型式建置開發，因此建置時不會產生dll」時該怎麼辦？
由於CAT.NET的運作原理， 是「看」assembly 的運作方式是否有問題，然後再將問題對後到原始程式碼，顯示出問題的path。因此必須有 assembly 才能運作。
解決方法，是先使用ASP.NET 編譯工具 (Aspnet_compiler.exe)將WebSite compile 成 dll後，再執行 CAT.NET 進行分析。
試著使用 VS2010 的新測試功具 Coded UI Test 時，發現在WPF應用程式上無法建立 Assertion。
為何呢？如下圖，原因出在 「An update for windows Automatin API 3.0 must installed to enable…」
原來，WPF 的Coded UI 測試，要使用 Assertion 功能時，需要安裝一個 Update，見 Description of the Windows Automation API 及安裝對應的版本即可
減重的十件必須知道的事
在幫別人除錯 asp.net 時，發生了如下的錯誤。
Type : System.Web.HttpException, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Message : File does not exist.
Source : System.Web
Help link :
ErrorCode : -2147467259
Data : System.Collections.ListDictionaryInternal
TargetSite : System.IO.FileInfo GetFileInfo(System.String, System.String, System.Web.HttpResponse)
Stack Trace : at System.Web.StaticFileHandler.GetFileInfo(String virtualPathWithPathInfo, String physicalPath, HttpResponse response)
at System.Web.StaticFileHandler.ProcessRequestInternal(HttpContext context)
at System.Web.DefaultHttpHandler.BeginProcessRequest(HttpContext context, AsyncCallback callback, Object state)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
但，這是如何發生的呢？並沒有指明是哪一個 page 發生錯誤。
首先，這是有故事的。
我幫同事做了 exception 的 log，也就是發生錯誤時會例外資訊記錄到檔案上。後來發現只要登入後，一到網站首頁，記錄檔就會看到這樣的錯誤資訊。
再來，我發現該專案是使用 Web Development Server 開發的，而不是使用 IIS。這一點我一直不信任 Web Development Server，因為該模式是使用開發人員的權限，而不是真正的 IIS 的權限。未來在正式機器上部署後，還會有權限不正確的變數。
更奇妙的是，我發現只有使用 Web Development Server 才會發生這種現象，而host 在IIS 時是不會發生的。
最後，我在記錄的 handler 上，再寫出HttpContext.Current.Request.FilePath 。令人不解的是，FilePath 竟然是 “/images/default_12.jpg”！！
我的解讀如下：
當使用 IIS 6.0 時，IIS 一遇到 jpg 檔時，就直接找 jpg 檔案後輸出。所有過程與 asp.net 無關。
而使用 Web Development Server , 則所有的檔案皆使用 asp.net 來處理。當遇到 jpg 檔時，會使用 StaticFileHandler 來處理。
因此，不要使用 Web Development Server 來開發。因為畢竟與 IIS 的運作不一樣。
