Reference Source 是一個非常方便的資源可以用來查看 .NET Framework 的程式碼，而這個網站是利用 SourceBrowser 所建立的。
對於我們自己開發的專案，雖然都有原始碼好像用不到這個工具，但很多時候想快速查看程式碼卻又不想耗費資源在執行 IDE 上的時候(尤其同時維護多專案的時候)，這個工具能提供一個不錯的介面來使用。
官方提供了基本的使用教學，但要開 Visual Studio 來編譯 SourceBrowser 專案，比較不方便，所以這邊會使用官方也有提供的 NuGet Package 來做，稍微紀錄一下過程，讓之後需要的時候能更快的使用。
當我們想要使用實作 IDisposable 的型別時，using 關鍵字通常是不二人選，但是其中卻包含一些小陷阱 (嚴格來說不是陷阱，是實作 IDisposable 的時候沒做好)。
背景知識:
using關鍵字就是 try-finally 加上呼叫IDisposable.Dispose()的語法糖，沒把握的話找個反組譯工具確認一下就知道了。
Hangfire 是很常用的定時排程工具，他會將排程和任務資訊紀錄在資料庫中，但是如果使用 Redis 做資料儲存時，就必須謹慎思考資料清理的問題，畢竟資料存放在記憶體中是不可能不去限制大小的。
很多時候我們需要從客戶端從透過 HTTP GET 發送 Reqeust 給服務端，但在之前的一個 ASP.NET Core 的專案中卻因為 Uri 過長而出現了 Invalid URI: The uri string is too long 這樣的錯誤訊息。
這個問題網路上幾乎都是改 Web Service (例如: IIS) 的設定來解決，這是最簡單方便的方法，但如果伺服器很多或是需要經常擴充伺服器時就會造成不小的困擾，即使伺服器不多也可能因為這些瑣碎的設定造成維護上的不方便，所以這邊提供另外一種解決方案。
擴充方法是很常用的技巧, 之前在使用 Entity Framework Core 的時候, 擴充了一個 IQueryable<T> 的擴充方法 WhereIf(), 後來想說這個方法也適用於其他衍生自 IEnumerable<T> 的型別, 且 IQueryable<T> 繼承了 IEnumerable<T>, 所以把 WhereIf() 方法改成 IEnumerable<T> 的擴充方法以求更廣的適用範圍, 沒想到一切都不一樣了, 要是當時沒及時發現就引爆了一個效能核彈了.
雖然標題是寫 Entity Framework Core, 但
IQueryable<T>本來就是設計給”資料查詢”的情境來說, 其他 ORM 八九不離十會遇到一樣的現象.
使用 Windows 內建的遠端連線工具 (Remote Desktop Connection) 如果需要支援雙螢幕的話需要做一些設定，這些網路上資源很多沒什麼好說的。
但是如果是想要只使用三個螢幕中的其中兩個螢幕呢?
最近的一個大專案剛好有機會重新打造基礎建設，於是便將常用與各種擴充功能做成套件發佈到內部的 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 來分辨的.