軟體主廚的程式料理廚房

在之前的一篇文章中，說明了我們如何用 WSDL 檔案產生代理類別，現在目標的 Web Service 有一個需求是要加入一個 Http Header，網路上可能會找到覆寫 GetWebRequest() 的解法，但我們會發現，用 dotnet-svcutil 所產生的代理類別無法覆寫 GetWebRequest()，該怎麼辦？

以往我們要呼叫 ASMX Web Service 的服務，大多透過 Visual Studio 的「加入 -> 服務參考」的程序，自動產生 Reference.cs 程式碼檔案，裡面就有我們要用的服務代理。但現在因為開發環境無法連線 Web Service，所以無法使用這個方式，我們手上有的是一個 *.wsdl 檔案，要改用手動的方式建立服務代理。

過去在 .NET Framework 想要取得執行檔所在位置，我都是用 System.Reflection.Assembly.GetExecutingAssembly().Location 搞定，很少有無法正常運作的時候，但是到了 .NET Core／.NET 的時代，這個方法已經不再適用於多數情境了。

即使 Unicode 發佈第一個版本至今已經超過了 30 年，現在我們還是得處理 Big5 編碼的文件，一個我們經常會遇到的情境，就是使用者上傳的 CSV 檔案是 Big5 編碼，而當我們使用 .NET Core 預設編碼讀取檔案的時候，會讀到亂碼。

使用 .NET 5 開起來的專案，預設就能使用 C# 9 的語法，那麼 .NET 5 以前的 .NET Core 2/3、.NET Framework 4.x 專案是不是就不能用 C# 9 的語法？　非也非也，只要調整幾個小地方，.NET 5 之前的專案一樣可以使用 C# 9 的語法。

以往用 .NET Framework 開發的時候，都是用 TopShelf 來建置 Windows 服務，現在 .NET Core 弄了一個叫 .NET Generic Host 的東西，我們可以直接將服務透過它來 Host 成背景服務，而且它是跨平台的，不只可以部署在 Windows 上，Linux 上也行得通，ASP.NET Core 應用程式就是用它來讓服務可以長時間執行。

以往我們都是透過組態（Debug|Release）來輸出不同環境的設定，這件事情到了 ASP.NET Core 則改由環境變數（Environment Variables）來控制，至於 Console App，網路上查到的資料也都是教我們用環境變數來控制設定的輸出居多，難道我們不能跟以前一樣使用組態來控制嗎？

微軟官網有一篇 .NET Core 應用程式部署的文章在介紹 .NET Core 的部署模式，只是裡面都是文字，再加上有一些新的詞彙，什麼 FDD、SCD、FDE，看了也懂了，但是實際操作還是有點霧煞煞，我這邊就直接用 Visual Studio 2019 的發佈設定視窗，來說明不同的發佈設定會對發佈結果造成什麼影響？

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

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