Asp.Net MVC Model Validation:Custom Validation – 以 Required If 為例

在前篇「Asp.Net MVC Model Validation:Remote validation」的介紹之下,想必大家對於 .Net MVC 的 Model Validation 運作機制都有一定程度的了解,接下來將進一步介紹如何在 .Net MVC Model Validation 的運作機制加上自訂驗證規則(前、後端,使我們專案的表單驗證機制更加完善

繼續閱讀 “Asp.Net MVC Model Validation:Custom Validation – 以 Required If 為例”

透過 WinDbg 來找出 ASP.NET CPU 100% ASP.NET 程式的問題

問題

我們有一個 ASP.NET 的系統部署到 IIS 上(Windows 2012, .NET 4.x),有時候會導致 w3wp.exe 吃掉所有的 CPU 資源,一直要等到應用程式回收後,程式再重新啟動後就正常了。這種狀況不定期會發生。

解法

我們可以使用 WinDbg 來找出導致 IIS CPU 100% 的原因,方法如下,

  • 透過「工作管理員」來「建立傾印檔案」
    當發生 IIS 導致 CPU 100% 時,開啟「工作管理員」,按右鍵選取「建立傾印檔案」。要依 Web 應用程式的平台(x86/x64)來開啟「工作管理員」(x86的工作管理員在 C:\Windows\SysWOW64\taskmgr.exe )。
  • 安裝 WinDbg
    請參考 Debugging Tools for Windows (WinDbg, KD, CDB, NTSD) 來安裝對應的版本。
  • 設定 Symbol Path
    先建立一個 C:\RTX64_SYMBOLS 目錄(依您自行定義),然後開啟 Command 設定 _NT_SYMBOL_PATH 的環境變數,如下,

    set _NT_SYMBOL_PATH=srv*C:\RTX64_SYMBOLS*https://msdl.microsoft.com/download/symbols

    set _NT_SYMBOL_PATH所以在 command 中,輸入 set 後,就可以看到 _NT_SYMBOL_PATH 的設定值哦,

    _NT_SYMBOL_PATH當然,如果常常會用到的話,就直接設定到 環境變數之前,下次 debug 時,就不用再設定一次了哦! 詳細請參考Set up your system to use Microsoft’s public Symbol Server

  • 在 WinDbg 中找問題
    • 載入 sos.dll
      WinDbg 有 x86/x64 的版本,我是使用 x64 的版本,所以 sos.dll 的路徑是 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll,您輸入如果發生錯誤的話,請使用 C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll 。
    • 設定 Symbol 檔目錄
      !sym noisy
      .cordll -ve -u -l
    • 透過 !runaway 顯示Threads所佔的時間
      輸入 !runaway 後,會顯示各 Thread 所花費的時間,花最多的會在最上面,如下圖,

      !runaway

      !runaway

    • 透過 ~[thread]s 切換到該 thread 的位置
      由上圖所示,Thread 40 佔最多時間,所以我們切到它的位罝去,

      ~40s

      ~40s

    • 透過 !clrstack 來查看呼叫堆疉
      !clrstack

      !clrstack從上圖可以發現,應該是有關 Dictionary 操作的問題,而它是由我們系統中 TemplateCfg.initial() 這個 Method 所引起的。

  • 檢視並調整程式碼
    開啟 TemplateCfg 程式碼,在 initial 這個 Method 之中會建立 Dictionary 物件,Clear 它,並 Insert 資料,但這些 Dictionary 的變數卻又設定成 static 。TemplateCfg.initial()即然這些 Dictionary 是 static 的,而且它們值又都是相同的,就沒有必要每次 request 時,就重新建立並 insert 這些資料。
    所以將 initial 裡面的 Code 搬到 static constructor 。
    調整完程式碼後,從去年觀察到目前,已經沒有再發生 CPU 100% 的狀況。

參考資料

Debugging in Production Part 1 – Analyzing 100% CPU Usage Using Windbg
WinDBG 應用實例:找出 ASP.NET CPU 100% 原因
Debugging Tools for Windows (WinDbg, KD, CDB, NTSD)
Set up your system to use Microsoft’s public Symbol Server
High CPU Hangs – 05
中小型研发团队架构实践:生产环境诊断利器WinDbg帮你快速分析异常情况Dump文件
Intro to WinDBG for .NET Developers
.NET Debugging Demos Lab 4: High CPU Hang – Review

簡介 .NET 的 Server 端資料驗證機制: DataAnnotation Validation

就一個應用系統而言, 對資料格式或資料正確性的驗證是保障系統能正常運作的重要基本動作.  目前大部份應用系統都是 Web-Based, 因此在使用者輸入資料的驗證部分, 可以選擇在 Client 端 (即 Browser 或 App) 做驗證, 也可以在 Server 端做驗證, 或是兩者都做.  在 Client 端的資料驗證, 一般比較常見.  在 Visual Studio (VS) 的開發環境中, 提供有資料驗證的控制項, 可以直接拉到頁面上來驗證使用者輸入的資料.  在 Client 端的資料驗證, 基本上都是透過 JavaScript 程式來進行, 這種方式雖然可以比較不影響 Server的效能, 但是主要缺點是瀏覽器上面的 JavaScript 有可能會被關掉, 導致沒辦法做資料的驗證.

繼續閱讀 “簡介 .NET 的 Server 端資料驗證機制: DataAnnotation Validation”

ASP.NET MVC架構下如何防範表單偽造(CSRF)

首先,何謂CSRF?CSRF是Cross-Site Request Forgery的簡稱,簡單來說就是惡意駭客為竊取資訊用script創造成的假表單。詳情請參考OWASP官網解說:Cross-Site_Request_Forgery

那麼在ASP.NET MVC底下,其實要防範這個問題相當簡單,只要在Razor Ajax.BeginForm或是Html.BeginForm,甚至是一般傳統Html

內加上@Html.AntiForgeryToken,就會在表單Submit的時候產生2個相同值的Token。 繼續閱讀 “ASP.NET MVC架構下如何防範表單偽造(CSRF)”

【Asp.Net MVC】使用 ContextBoundObject 搭配 Attribute 實現 BLL 層及 DAL 層的 AOP Logging 機制

我曾經有發表過一篇「透過 Asp.Net MVC Filter 實作 Controller 層級的 Action Logging 機制」文章,
想必大家也跟我一樣好奇,
如果想更進一步得在 Controller 以外的 BLL 層(Service, 商業邏輯層)或 DAL 層(Repository, 資料訪問層),
掛載能 Logging 傳入 Action 參數值的攔截器到底該如何實作?

繼續閱讀 “【Asp.Net MVC】使用 ContextBoundObject 搭配 Attribute 實現 BLL 層及 DAL 層的 AOP Logging 機制”