以往我們在 .Net Fx 可以透過 Transforms 來切換不同的組態，而在 .NET Core 開始，則改用 Microsoft.Extensions.Configuration 來處理組態，上篇 也針對 Microsoft.Extensions.Configuration 進行了介紹，這篇將針對 .NET 應用程式注入環境的做法做一個簡單的介紹
當你的服務需要隱藏真實的訊息給調用端時，除了在每一個 Action 各自處理，Middleware 也是選擇之一，本想這應該是很簡單的操作，沒想到碰了一鼻子灰，以下是我複寫 HttpContext.Response.Body 的步驟，希望對正觀看的你有幫助。
以往，在 ASP.NET Fx / ASP.NET Core 我會先寫好 Controller(Server Code) 再搭配 NSwag、Swashbuckle.AspCore 產生 Swagger / OpenAPI Specification Doc，一旦要修改它(Spec.)就必須要重新編譯專案，只是要改文件的錯字，也沒有動到 Server Code 的邏輯，卻要重新 Build Server，幾次下來發現這樣似乎不是很聰明。也常常發生過於關注 Server Code 忽略 Specification ，導致兩邊跟不一致。
現在，我先寫 Specification，然後再透過它產生 Controller (Server Code) 讓 Specification 不再強制依賴 Server Code，解除強依賴關係，編寫規範時再也不需要重新建置專案，目前運作起來挺順暢的，接下來，我分享我是怎麼做的
驗證替使用者建立身分識別，授權則是用來判斷使用者能不能使用某一個功能，ASP.NET Core 提供許多的授權 Role、Claims、Policy 等，老實講 Policy 授權使用上有一點門檻，分享一下我的實際用法，也給需要的人參考
ASP.NET Core 提供了許多身分驗證的 Middleware，內建的 AuthenticationMiddleware (app.UseAuthentication) 需要搭配 AuthenticationHandler，這裡我將介紹如何使用自訂的身分驗證跟 AuthenticationMiddleware 的串接，驗證成功後替使用者建立身分識別
在 ASP.NET Core 的整合測試我們可以使用 WebApplicationFactory、TestServer，這我前面幾篇已經提過了需要的可以參考之前的文章 WebApplicationFactory、TestServer。Middleware 用上述的步驟肯定是沒有問題的，但是需要的環境、步驟也比較多，可能還會因為其他 Middleware 順序所帶來的影響，今天我還要分享 ASP.NET Core內建 Mock HttpContext 做法，讓我們可以快速的針對某一個 Middleware 進行單元測試
C# 9 開始就可以不用在主控台程式包含 main 方法(Top-level statements)，在 .NET 6，ASP.NET Core 6 也支援了 Top-level statements 專案範本，已經直接套用此功能，我用 WebApplicationFactory 寫整合測試時，碰到一點小問題，以下是解決問題的經過
現在的工作大都是使用微軟內建的 Json 序列化套件 System.Text.Json，為什麼要用可以參考 黑大這一篇，在尋求 Json Compare/Diff 解決方案時大都是看到 Newtonsoft(Json.NET) 的 JsonDiffPatch 做法，經同事分享 System.Text.Json 已經有人實作出來了，知道後立馬套用
一旦 Web API 部署並開始使用後，它應該是可靠的，並且不應該因任何原因而中斷。另一方面，隨著需求的變化，我們需要更新 Web API 代碼，但這應該不破壞目前 API 的情況下完成，因此新舊版本的 Web API 都將處於活動狀態，功能也要正常。這時候就要靠 Web API 版本控制，我們靠它用於處理不同版本的Web API。微軟的 Microsoft.AspNetCore.Mvc.Versioning 可以讓我們輕易的完成此項目，但我在整合到 Swagger UI / Swashbuckle.AspNetCore 的時候碰到了一些關卡，所幸順利的解決了，以下是我的實作筆記。
前幾年編寫了 [Swagger] 一些 Swagger 編寫文件的技巧和 Client Code Gen ，不過，已經不適用 ASP.NET Core 6，正好，團隊正在重視 API 文件，正好趁這機會更新 Swashbuckle.AspNetCore 使用