最近的一個大專案剛好有機會重新打造基礎建設，於是便將常用與各種擴充功能做成套件發佈到內部的 NuGet 儲存庫，但有一個問題是因為套件上傳後就不應該再重新佈署同一個版本，如果新的套件開發初期有頻繁的設計變更會經常引發 breaking change，造成版本號增加的很快，即便不是設計變更，一有小 bug 或是小變更就急著跑流程發新版也是很浪費時間。
所以就有了一個想法，如果能在本機上建立 NuGet 套件儲存庫，這樣就能先在本機上試用確認設計適當且品質夠好，再將正式版發佈到真正的 NuGet 儲存庫上。
前陣子在 依字位 (grapheme) 處理字串 這篇文章中有以越南文為例提到 grapheme 的問題，後來覺得 TextElementEnumerator 提供的方法不夠多，所以基於他另外封裝了一個仿 String 的類別，折騰了幾天常用的都寫得差不多了才發現繞遠路做了不少原本 string 就有提供的功能。
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) 的, 所以無法讀取, 就需要一點小技巧.