BenchmarkDotNet 是一個很熱門的工具可以用來簡單的量測與比較程式碼的效能，但是有時候我們只是想要快速測試一段程式碼的執行時間，這時候還要開 IDE 使用 BenchmarkDotNet 就覺得有點厚重 (除非 BenchmarkDotNet 專案已經建好在方案中可以一邊開發一邊實驗)。
這時候就想要在 RoslynPad 或 LinqPad 中使用基準測試工具，偏偏因為 RoslynPad 的限制而無法支援 BenchmarkDotNet，所以只能另外找一個替代方案 - MeasureIt。
一般來說在 WebAPI 的專案中, 我們會偏好使用 Model Binding 的機制來綁定請求內容, 但是之前在一個特殊需求上卻遇到在 Model Binding 後仍然要讀取 Request.Body (型別是 Stream) 的內容.
而問題在於, Form Post 的情境中, 在Model Binding 後 (在 Action 中) 讀取Request.Body 時會得到空的內容, 但是資料長度又是正確的 (而神奇的是 JSON 和 XML 情境是沒問題的).
這邊 Form Post, JSON 和 XML 情境是依 Content-Type 這個 Header 來分辨的.
寫 C# 也好幾年了, 對於物件和集合初始設定式的使用也很習慣, 也知道那是語法糖, 但是前陣子看到自訂類別要套用物件和集合初始設定式時, 才發現其實沒有想像中的熟, 所以想稍微再整理一下一些細節.
以前在處理字串的時候, 不管是反轉或是取字元都沒考慮到有些語言的一個字母可能是由多個字組成的, 直到遇到問題.
舉個越南文的例子, ơ 是由 o 和 ̛ (%cc%9b) 組成的, 所以處理的時候就容易有預料外的結果, 以字串反轉來說, ơa 反轉後變成 a̛o
幾年前因為需要將”不固定格式且不可預期”的 JSON 字串轉換成 Dictionary<strin, string> 而做了擴充方法, 但後來發現實作得太複雜了.所以想記錄一下比較簡單的做法.
之前在 WebAPI 安全的取得 Request Body 這篇文章有提到讀取 Request Body 的方式, Response 的部分其實大同小異, 且在 ASP.NET Core 中也是相同邏輯(即使實作可能不同), 但有個不同的地方是 ASP.NET Core 中的 request body 預設是讀完無法回捲的(也就是讀完後指標會在 stream 最後面, 無法重複讀取), 且 response body 是唯寫 (WriteOnly) 的, 所以無法讀取, 就需要一點小技巧.
為了降低多個專案間的複雜度, 我們通常會謹慎的控制專案之間的依賴, 但在最近新開案的 .NET Core 一系列的新專案中發現傳遞依賴會讓專案之間產生預期外的依賴.