軟體主廚的程式料理廚房

在前一篇文章 [料理佳餚] ASP.NET Core 的虛擬目錄哪去了？中有提到，傳統 ASP.NET 的 HTTP Handler 及 HTTP Modules 的工作在 ASP.NET Core 是由 Middleware 來負責處理，這篇文章就來介紹撰寫 Middleware 的幾種方式。

在傳統 ASP.NET 的年代，我們別無選擇，寫好的 ASP.NET 應用程式只能 Host 在 IIS 上執行，其中虛擬目錄的服務是由 StaticFile 這個 HTTP Handler 來負責處理。

而 ASP.NET Core 內建就有 Kestrel 這個輕量化的網頁伺服器，不需要再依賴 IIS，但是脫離 IIS 之後，我們要怎麼設定虛擬目錄？

ASP.NET Core 內建的 DI Container 稍嫌陽春了一點，讓我懷念起 Autofac 提供的多種花式註冊方式，我決定把它召喚回來攜手共創未來，ASP.NET Core 2.2 到 3.1 有一些 Breaking Changes，設定方式會有一點不一樣，這邊做個記錄。

在 .NET Core 專案中，如果我們按照過往的習慣，使用服務參考（Service Reference）要參考 WCF 或 Web Service，我們會發現跳出來的畫面很陌生。

會想說 .NET Core 不支援開發 WCF 或 Web Service，該不會微軟連參考的功能也拿掉了？　其實沒有，它只是換了位置。

以往服務參考（Service Reference）只能參考 Web Service 或 WCF，但是在把玩 gRPC 服務的過程中，意外地發現，原來在 Visual Studio 2019 已經可以透過服務參考的方式，為 gRPC 服務自動產生客戶端的程式碼，甚至是 Web API 也可以。

這幾天在把玩著 ASP.NET Core 的 gRPC 服務，正當思索著要怎麼實作 AOP（Aspect-Oriented Programming）時，我就看到了 GrpcServiceOptions 有一個 Interceptors 屬性，看到 Interceptor 這個關鍵字就知道 gRPC 服務天生就支援 AOP 的實作。

身為一名程式設計師，打開瀏覽器 Google 一些資料，或是開啟 IDE 寫點程式是常有的事，而當事情做到一半必須被打斷時，「睡眠」這個功能就可以讓電腦在下一次開機的時候，快速地回復到前一次的工作狀態，但是 Windows 10 自從更新了 1903 之後，電腦卻經常在清晨被喚醒，等到我發現的時候，早就不知道運轉了多久、浪費了多少電，甚至直到最近我也更新了 1909，問題依舊還在。

gRPC 服務預設會使用 HTTPS，不過這個只有針對 localhost 這個網域名稱，這天我想要將自己的區域網路 IP 指定為 gRPC 服務的端點，好做一些驗證跟測試，於是我就動手修改了 Kestrel 監聽的 IP，使用的是 HTTP 協定，然後就在客戶端收到了這個錯誤訊息。

IOException: The response ended prematurely.

自從更新了 Windows 10 1903 之後，事件檢視器就經常爆出 ESENT 事件識別碼 455 的錯誤，是不影響平常的操作，但是這個錯誤實在太多了，多到整個事件檢視器有三分之二的空間都是這個錯誤，影響到查找其他錯誤的效率。

gRPC 服務底層使用 Protocol Buffers 做為序列化的格式，與我們經常使用的 JSON 格式相比之下，其大小已經小非常多了，如果我們還覺得不夠，想要再更進一步地減少傳輸量，可以啟用 gRPC 服務的壓縮（Compression）機制，讓傳輸的資料量再更少一些。