2023年12月，正忙於年末最後一場iThome - Kubernetes Summit 2023的演講，心想，忙完這一場終於可以好好休息一下。但事情永遠不是傻子所想的那麼簡單。突然，信箱進來一封編輯邀約的信件，正想說，如果是翻譯工作，就再幫忙找其他新鮮的肝（新譯者），結果是翻譯也不是翻譯。出版社嘗試用了ChatGPT進行初譯，然後由專業編輯與譯者進行修潤與審校，想嘗試這樣的合作模式。快速瀏覽了主題與內容，我非常有興趣，立即回信說，我想接下這份工作。
口罩API系列(一)(二)(三)就資料面而言，已經處理的差不多了，不過，專案還有改善的空間。
以關注點分離來看，目前的 MaskController 工作有點雜且職責不夠單一。第一個問題，如果從 EF Core 下手，可能是實作 SeedData 方式來解決，但比較麻煩的事情是資料來源是網路上，而且資料內容不固定。第二點比較麻煩。正在構思時，剛好好友 Demo 貼文說 dotblogs 改版採用 Hangfire 來處理排程事件。疑，Hangfire 不就是這個需求的最佳解嗎！
「使用Hangfire處理ASP.NET MVC/Web API長時間與排程工作」多年前已經用的非常開心。這次讓我們在 ASP.NET Core Web API 來整合 Hangfire 來解決我們碰到的問題。
在進行一個 Visual Studio Core + Entity Framework Core 測試程式時，在新增套件時，不斷跑出「無法載入來源」的錯誤，然後停止安裝。
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
Writing C:\Users\BruceChen\AppData\Local\Temp\tmp1C89.tmp
info : 正在將套件 'Microsoft.EntityFrameworkCore.Sqlite' 的 PackageReference 新增至專案 'D:\Temp\EFCoreFirst\EFCoreFirst.csproj'。
info : 正在還原 D:\Temp\EFCoreFirst\EFCoreFirst.csproj 的封裝...
info : GET https://api.nuget.org/v3-flatcontainer/microsoft.entityframeworkcore.sqlite/index.json
error: 無法載入來源 https://xxxxxxxxxx.pkgs.visualstudio.com/_packaging/BestFeed/nuget/v3/index.json 的服務索引。
error: Response status code does not indicate success: 401 (Unauthorized).
在測試一段非同步程碼時，發現一個 ASP.NET Core 裡 Route 有趣現象。平常為了測試方便，習慣會修改預設路由規則，例如將
ASP.NET Core Web API Route("api/[controller]") 改為 Route("ControllerName/[action]")。
日前接手一個 ASP.NET Core 的專案，在本機開發與測試一切正常。但在進行發行時會出現一個 TransformWebConfig 錯誤，造成發行錯誤：
Severity Code Description Project File Line Suppression State
Error The "TransformWebConfig" task failed unexpectedly.
System.Exception: In process hosting is not supported for AspNetCoreModule. Change the AspNetCoreModule to atleast AspNetCoreModuleV2.
at Microsoft.NET.Sdk.Publish.Tasks.WebConfigTransform.TransformAspNetCore(XElement aspNetCoreElement, String appName, Boolean configureForAzure, Boolean useAppHost, String extension, String aspNetCoreModuleName, String aspNetCoreHostingModel)
at Microsoft.NET.Sdk.Publish.Tasks.WebConfigTransform.Transform(XDocument webConfig, String appName, Boolean configureForAzure, Boolean useAppHost, String extension, String aspNetCoreModuleName, String aspNetCoreHostingModel, String environmentName)
at Microsoft.NET.Sdk.Publish.Tasks.TransformWebConfig.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
同事回報，有一支 API 轉移至 Windows Container 之後，特定 Action 會產生 HTTP 500 錯誤，查詢容器日誌快速定位到問題：
fail: Microsoft.AspNetCore.Server.Kestrel[13]
Connection id "0HLHTEASOTJDP", Request id "0HLHTEASOTJDP:00000002": An unhandled exception was thrown by the application.
System.TypeInitializationException: The type initializer for 'ClosedXML.Excel.XLHelper' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Gdip' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'gdiplus.dll': The specified module could not be found.
at System.Runtime.InteropServices.FunctionWrapper`1.get_Delegate()
at System.Drawing.SafeNativeMethods.Gdip.GdiplusStartup(IntPtr& token, StartupInput& input, StartupOutput& output)
at System.Drawing.SafeNativeMethods.Gdip..cctor()
--- End of inner exception stack trace ---
at System.Drawing.SafeNativeMethods.Gdip.GdipCreateBitmapFromScan0(Int32 width, Int32 height, Int32 stride, Int32 format, HandleRef scan0, IntPtr& bitmap)
at System.Drawing.Bitmap..ctor(Int32 width, Int32 height, PixelFormat format)
at ClosedXML.Excel.XLHelper..cctor()
--- End of inner exception stack trace ---
公司有台 Disk I/O 與 Network I/O 量不小的 Server Core - Docker Host 伺服器，發現 Momery 被使用至 99%，雖然看起來(似乎)不影響 Container App 的運作，執行 Docker CLI 或 PowerShell 非常明顯的反應遲鈍鈍鈍，直覺不查不行。
ASP.NET Core 本身跨平台特性，使得他非常合適活在 Docker Container 裡。這裡試著把一個 github 專案先匯入 VSTS，然後在 VSTS Build 的 CI 服務進行 build image 和 pull image 的動作，pull image 我們採用 Microsoft Azure 的 Container Registry 服務來當私有庫。有了 image 之後，在使 VSTS Release 的 CD 服務將 image 送到 Web App for Container 去進行執行動作。
VS / VS Code <--> VSTS git <--> Build / Pull Image <--> ACR <--> Release <--> > Web App for Container <--> User
同事反應，ASP.NET Core 專案無法正常進行中斷點(breakpoint)偵錯。簽出專案，下中斷點偵錯取得以下資訊：
The breakpoint will not currently be hit. No symbols have been loaded for tis document.
如果這時你下關鍵字「asp.net core breakpoint」去搜尋，在第一筆你就能找到解決方案。
他的解決方案是叫你「關閉：Enable Just My Code」與「開啟：Microsoft symbols Server」。
如果這樣就解決了，那我還要寫這篇嗎？
這是一篇有感而發的短文。
最近又在做效能調教的工作，在單一個專案內我移除了近30個無用的NuGet套件。其實不用問，一眼就能看出，這是一個從預設專案範本開始寫的專案。用專案範本有錯嗎？嗯，沒錯，也有錯。原因，最後在說。我們先來看看之前 twMVC#22分享主題：「一個微信專案從0到000的效能調教」的幾張投影片。
在 .NET Core SDK 裡最重要的莫過於 dotnet.exe 命令，它提供一切 .NET Core 運行所需的基礎環境。
dotnet [command] [arguments] [--version] [--info] [-d|--diagnostics] [-v|--verbose]
dotnet [-h|--help]
dotnet 是進入點， dotnet 之後的 [command] 指定所要執行的命令，例如，dotnet build。也可以指定相容 .NET Core 的 DLL 來執行應用程式。
From:網路Microsoft Build 2017 已經落幕，但開發者的重點才要開始，數百堂的技術分享，要如何吸收。還好，Scott Hanselman 幫我整理好了 BUILD 2017 Conference Rollup for .NET Developers 。目前我只看了前二個，簡單做了點小筆記。如果你對 .NET Standard 2.0 / .NET Core 2.0 / ASP.NET Core 2.0 興趣，最少建議花點時間把這兩篇看完。
你是否有過邊看 MSDN Library 文件，不時浮現一個「x」字，心想：「這是在寫什麼鬼？」(台語)的疑問。
.NET 開發人員，你一定讀過 MSDN Library，早些年，MSDN Library 可說是 .NET 開發人員最好的朋友。但近年來，大量的機器翻譯，讓 MSDN Library 品質直線下降。其實，各位所提交的建議，原有一群義工人士，是"真"人工審核。後來不為何，義工人士不斷消失。小弟有幸加入這個消失中的義工團，就我而言，審核分專業和非專業，我不可能專精整個 MSDN Library 技術，在審核非專業內容時需要大量的時間。由於下班後時間有限，只能慢慢放低義工時間，最後，好像能瞭解，機器人造成大量的品質不良，要靠少數幾個人來改善是有難度的。
目前微軟新版文件庫叫 Microsoft Docs，這一個以開源為導向的文件庫，所有文件內容都開源開放在 Github 上，目前繁體中文化正在火熱進行中(但目前還有很大比例，你點擊後還是看到英文內容)，既然開源開放，那麼只要你有心，人人都能成為Microsoft Docs繁體中文貢獻者。目前有二種途徑可以參與：
如果你有跟著 ASP.NET Core (1)(2) 篇練習的話，會發現開發上有那麼些許的不方便，就是我們要不斷中斷dotnet程序，重覆dotnet build、dotnet run的流程。我們希望後端的 C# 也能像前端擁有 LiveReload 或 React Hot Loader 的功能，在 Visual Studio 我們介紹過 Reload 來解決此一問題，而在.NET Core dotnet watch 套件可以實現自動編譯的工作。
前篇：使用ASP.NET Core建立Web API服務，我們使用 VS Code 來開發了一個.NET Core(ASP.NET Core) 的 Web API 服務，接著我們要把開發好的服務發行至Microsoft Azure來執行。和前篇相同，如果是使用 Visual Studio 那麼發行動作只在點選之間就完成了，不過這篇，我們依然是不採用 Visual Studio 來實作，還是使用 VS Code 與指令來完成。
在 VS Code 切換至 git 圖示，點擊"初始化 git 儲存機制"並且在訊息輸入第一次簽入的資訊。
.NET Core(ASP.NET Core)與之前的 ASP.NET MVC / ASP.NET Web API 兩套不同的 Framework 不同，ASP.NET Core 中的 MVC 整合了 Web API，現在要建立 API 或 Web 都將更為簡單，因為整合後的 ASP.NET Core MVC 基於相同的程式碼與管線(pipeline)。
ASP.NET Core 的跨平台特性，使用開發工具與開發環境的選擇相當多元。
.NET Core SDK 安裝：
安裝頁面有各平台(Windows, Linux, Mac, Docker)的安裝指南，照步驟安裝即可。
開發工具方面：
使用 Windows 的開發者，地表最強的 Visual Studio 當然是最好的選擇，如果使用 MAC(Windows) 那 VS Code + C# 擴充套件後也不差。如果 Visual Studio 2015 Update 3 並安裝了最新的 .NET Core Tooling Preview 2 for Visual Studio 2015 ，那麼已包含 .NET Core SDK 的安裝。
如果 VS Code + C# 擴充套件，使用起來不是很順(例如，IntelliSense、提示加 using 等)，看一下 OmniSharp Log (檢視 → 切換輸出)是否正常。重開幾次 VS Code 看看。
測試工具：
兩套測試工具都行，挑喜歡的用即可。
範本工具：
安裝指令：
npm install -g yo
npm install -g generator-aspnet
這是延伸自 yeoman 的範本產生器，在不使用 Visual Studio 的情況下，它會很有幫助。
以下範例，讓我們使用 VS Code 來走一次建立 ASP.NET Core - Web API 的過程。相同的過程，使用 Visual Studio 的體驗與以前沒有太大差異，更重要的是，使用 VS Code 可以讓我們更瞭解 .NET Core 運作流程(因為要下指令)，所以選擇使用指令與 VS Code 來進行實作。