Simple Is Not Easy

有時候我們會需要用到 C# 的前置處理器指示詞(Preprocessor Directives) 中的 #if 等相關指示詞, 最常見的就是用來區分 Debug 和 Release 的編譯模式.

也有另外一種方式 (ConditionalAttribute) 可以達到類似的效果, 但兩種方式的運作機制是不一樣的.

.NET 內建的 RSA 加解密相關元件可以用讀取憑證檔或是 XML 格式的金鑰的方式來初始化, 之前的專案都是用讀取 XML 的方式來操作, 讓管理者能夠方便的從後台來管理金鑰.

而在 PEM 檔中, 金鑰的格式是 base64 字串, 這用 JAVA 是可以正常讀取的, 但卻不是 .NET 接受的 XML 格式, 因此用了一個第三方套件 Bouncy Castle 來幫忙轉換, 但是在一個少見的情境下 (其實也沒有多少見, 我用 OpenSSL 隨機生 500 組, 就有 10 組觸發), 轉換出來的 XML 是錯誤的, 且只有私鑰有發生過.

之前在寫 AES 加解密用的工具方法的時候, 意外發現某個特殊的情境, 會導致解密時因為沒有 Key 而拋出例外 (但 Key 確實有設定).

XSD 的文章很早之前就寫過, 但是當時剛開始寫部落格, 所以雖然寫了三篇但內容沒有編排又很亂, 因此最近想說稍微重寫一下, 留下重點就好.

在開發的過程, 常常有一些需要改進但現階段沒時間做的部分, 我們在上面加上一個 // TODO: 的註解來標註, 甚至依照特性的不同會用不一樣的語彙(Token)來標註, 例如: // BadSmell: 等等, Visual Studio 已經有內建幾個常用語彙, 除了這些內建語彙外我們也可以自己新增團隊內部使用的語彙.

另一方面, 這些工作清單慢慢累積後就會變得不好管理, 這部分也可以通過 Visual Studio 提供的相關功能來協助我們管理.

很多 .NET 開發人員對於 StyleCop 應該是不陌生, 它能有效地協助我們讓程式碼的風格保持一致, 預設的規則其實已經足夠了, 但有些團隊可能有自已的特殊編碼規範, 這些編碼規範甚至是跟預設的規則是衝突的, 這時候就需要自己寫規則來套用.

這篇主要是針對自訂規則可能會面臨的問題所記錄的, 尤其是要怎麼測試這些規則沒寫錯, 所以對於一些 google 就可以很容易找到的部分只會簡單帶過, 另外由於 StyleCop 也滿大的, 所以有些太細的設定或是內部運作這篇也不打算深入探索, 等之後有需要或是有興趣再根據各個主題或面向來專題探討.

XmlSerializer 提供許多序列化和反序列化相關的多載, 都有各自的優缺點, 例如有些方式在某些編碼下會因為 BOM(byte order mark) 出現在開頭而導致反序列化出現 Exception 或是序列化出含有 BOM 的字串導致接收端無法成功解析, 而各種方式的彈性與易用性都略有不同, 所以稍微記錄幾種序列化和反序列化的方式與特徵.

標題下的有點奇怪, 框架預設提供 Model Binding 來將請求內容(request body)綁定到參數中, 其實一般情境不需要手工去讀取它的. 但是之前遇到一個情境是需要在 ActionFilterAttribute 中取得請求內容並紀錄到日誌 (log) 中, 這時候問題就來了.

最近在寫一個比較方便使用的工具方法來做 XML 的序列化的時候, 發生了一個神奇的問題, XmlWriterSettings.Encoding 預設應該是 UTF-8, 但是轉出來的 XML 卻是 UTF-16, 這就奇了怪了…

ASP.NET WebApi 2 提供了三個好用的 FilterAttribute 讓開發者可以擴充後將這些 FilterAttribute 套用在 Controller / Action 上面, 也可以在 WebApiConfig.cs 或 Global.asax 裡面註冊 , 並在一個 API request 生命週期中的特定時間被執行.
這樣做的好處是可以將跟 API 主業務邏輯無關, 卻又是大部分 API 都要做的事收斂起來, 只需要將 Attribute 套用在正確的地方就能一體適用, 開發者就能更專注在 API 的主要商務邏輯層面.

在了解 FilterAttribute 的運用之前, 必須先知道 Attribute 是什麼以及如何使用 Attribute.