Simple Is Not Easy

.NET 提供的 RSACryptoServiceProvider 用來做 RSA 加解密與驗簽非常方便, 相關的網路資源也很多, 本來是沒什麼好寫的畢竟隨便 google 一下都有, 但是最近發現不知道為什麼用一次查一次然後忘一次, 想想還是稍微紀錄一下用法方便以後速查好了.

C# 的版本最近幾年更新的越來越頻繁, 雖然官方有提供版本歷程以及各版本的新特性, 但是還是想整理起來, 在官方提供的語言特性說明外多一點思考並紀錄自己使用上的想法.

本篇是 C# 6.0

這篇是要稍微記一下 Web API 回傳資料的幾種方式與格式, 會想要記這一篇是因為以前碰過的 Web API 專案都有統一的回傳 (response) 格式, 但是最近碰到一些專案的 Web API 在回傳資料時是沒有規範的, 例如直接就 return true, 所以就稍微整理一下回傳資料的幾種方式與優缺點.

在 Web API 中, 例外處理是一定會遇到的問題, 以前常常見到一些專案為了怕出現 unhandled exception 就地毯式的將所有方法都加上 try-catch, 但是這樣使用 try-catch 會有很大的副作用, 一來無差別的吃掉所有例外會導致程式不易除錯, 二來到處散布的 try-catch 和相關的 log 在維護上的成本也很高, 尤其是大型專案更是明顯, 第三也會使得商務邏輯跟這些例外處理混雜在一起 (try-catch 不是不能用, 但是他是有使用時機的).

而 ASP.NET Web API 2 中其實提供了很多種全域的例外處理方式, 例如: ExceptionFilterAttribute, ExceptionLogger, ExceptionHandler, 能將攔截未處理的例外的任務抽離出來, 讓我們開發時能更專注在重要的商務邏輯上, 這篇主要紀錄一下這三種全域例外處理的方式與差別.

DocFx 是一個很方便的專案文件製作工具, 能將 XML 文件註解轉換成靜態網頁, 也可以轉化其他另外寫的 Markdown 格式的文件, 這篇主要的目的是紀錄如何將 DocFx 與 Visual Studio 整合, 在編譯後產出專案文件並佈署到 GitHub Pages.

順便提一下, 適用情境是在 visual stuiod 上開發 .NET 專案, 並且希望能統一管理, 其他情境不一定適合這樣整合.

Stopwatch 經常被用來觀察程式的運行時間, 在開發階段能協助我們抓出一些效能的問題, 不過他的基本使用方式不是很漂亮, 在程式碼中插入一堆 Stopwatch 會干擾開發或是不小心沒移除而 commit 上版控也不好.

另一方面, 如果有需要用他來觀察 production 環境的運作效能的時候, 這些穿插在主要程式碼中的 Stopwatch 就更加干擾了, 所以找了兩個方法來將 Stopwatch 封裝成小工具.

有時候我們會需要用到 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 的文章很早之前就寫過, 但是當時剛開始寫部落格, 所以雖然寫了三篇但內容沒有編排又很亂, 因此最近想說稍微重寫一下, 留下重點就好.