軟體主廚的程式料理廚房

PowerShell 目前是開源的，而且跨平台，做為一位長期在微軟技術生態圈打滾的碼農，面對要撰寫 Script 做自動化工作的場景，怎麼可以不用呢？　馬上來將上一篇文章用 Shell Script 實現藍綠部署，改用 PowerShell 來實現。

在過去，發佈 Web 應用程式到 IIS 上，只要把新發佈的檔案覆蓋掉線上的檔案，IIS 就自動幫我們處理好新舊版的切換，現在搬到 Linux，這個新舊版切換的程序就得自己來了，第一個想到的工具就是 Shell Script。

微軟官方文件「在 Linux 上使用 Nginx 裝載 ASP.NET Core」使用的作業系統是 Ubuntu，我個人是偏好號稱萬年不掛的 CentOS，Linux 不同陣營之間的風格是有一點差異的，所以如果照著微軟官方的步驟套到 CentOS 上，一定會在某個地方覺得拐手，我就把到可以成功瀏覽網頁之前需要注意地方做個記錄。

在前一篇文章 [料理佳餚] 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，設定方式會有一點不一樣，這邊做個記錄。

以往服務參考（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 的實作。

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

IOException: The response ended prematurely.

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