因為 Windows 10 IoT Enterprise 的 2016 LTSB 推出至今將滿 10 年了，除了在今年 7/31 會 EOL 之外，也將會在今年的 10/13 正式 EOS。
手上的機台還是運作 Windows 10 IoT Enterprise 的 2016 LTSB 的怎辦呢？可以的話請把目光放向 Windows 11 IoT Enterprise LTSC 會是最長治久安的打算：
| - - - - - - | Win10 IoT Enterprise | Win11 IoT Enterprise | |
|---|---|---|---|
| - - - - - - | 2016 LTSB | 2021 LTSC | 2024 LTSC |
ASP.NET Framework 的 Session 預設使用排他鎖（Mutex），同一個使用者的 Request 會排隊等待，嚴重影響效能。而 ASP.NET Core 的 Session 雖然不會排隊，但底層是 IDistributedCache，不支援 HybridCache，每次存取都直接打 Redis，沒有 L1 記憶體快取，高流量時有快取擊穿的風險。
這篇想要演練的是用 HybridCache + Cookie 實作一個 SessionCacheProvider，讓開發者用起來跟原本的 Session["key"] 幾乎一樣，同時支援 ASP.NET Framework 4.8 和 ASP.NET Core (.NET 10)。
如果真要推薦近期偏 AI-driven 而生的 IDE 開發工具，目前比較有 "獨立" 精神的是 OpenCode "Desktop"。
雖然個人覺得 OpenCode 是 CLI 主打，但 OpenCode 後來也推出了 OpenCode Desktop 可以直接在 macOS / Windows 安裝使用：
如果你今天是 .NET 開發人員，那使用 Visual Studio 應該不陌生；如果你今天是開發人員，那使用 Visual Studio Code 應該不陌生。
自 Visual Studio 2026 起，Visual Studio 幾乎可以算是直接內建 "GitHub Copilot Chat"：
當然 Visual Studio 2022 也能裝 GitHub Copilot Chat 的，但不知道是不是個人的心理作用，感覺用起來沒有 Visual Studio 2026 的順。
Visual Studio Code 也不用太多說什麼，在 Visual Studio Code 的延伸模組的市集當中搜尋一下 "GitHub Copilot Chat" 就可以安裝。
在 AI 流行起來後，CLI (Command Line Interface) 又躍升為比較主流的操作方式，所以如果只能在 IDE 當中操作 GitHub Copilot 就似乎稍嫌不足。
GitHub Copliot CLI 的安裝當然也就要介紹一下囉！
截至目前 (2026Q1) 為止，在 macOS 上的專武 IDE：Xcode。
要幫忙上 Buff (GitHub Copilot) 的方式，仍得靠傳統的 *.dmg 安裝方式來疊：
上一篇 用 IDistributedCache + MemoryCache 做了一個簡單版本的冪等，適合單節點演練。但在多 Pod / Container 部署的環境下，MemoryCache 各自獨立，不同 Pod 看不到彼此的快取，冪等保護會直接失效。
這篇換用 Redis 來實現分散式冪等，目標是能跑在 Kubernetes / Docker Swarm 這類環境。
Harmony Library 補丁方式的最終章，Reverse Patch。
Transpiler 是 Harmony Library 的重量級功能，相較於 Prefix 或 Postfix 是在原始方法前後插入程式碼，Transpiler 直接操作 IL 指令，讓你在程式執行前就重新改寫方法本身，威力驚人。
已經有一段時間沒開 Android Studio 起來用，看到 GitHub Copilot 有說可以在 Android Studio 當中使用 GitHub Copilot Chat 的 Plugin (對，已經腿很久了)，就不假思索的打開電腦上已經安裝的 Android Studio 來試試看。
在 Android Studio 中點開 Plugins 找到 Marketplace：
這一篇談論終結器補丁 – Finalizer。
持續介紹 Prefix 和 Postfix 的其他使用方式。
系列：從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案（5/10）
系列：從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案（4/10）
續上篇，繼續來實作不同情境的 Prefix 與 Postfix。
前篇簡單介紹了 Harmony Library，這篇開始介紹補丁的實作，因為 Prefix 與 Postfix 常常會搭配，所以就併在一起說明。
系列：從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案（3/10）
想要讓 GitHub Copilot 串其他 AI 平台的 model 到 GitHub Copilot 在 Organtization 來使用，行不行？
行，當然行！
看 GitHub 設定 API key 的選項：
基本上主流的幾家 AI 平台都支援了！
記錄把本地 Terraform State 文件轉移到 AWS S3 的過程與注意事項
Harmony 是一個 .NET 的開源 Runtime Patching 函式庫，由 Andreas Pardeike 開發，這個函式庫能夠在不具有原始碼的狀況下動態修改任何 .NET 方法的行為。這系列文章記錄一些關於這個函式庫的使用方式。
系列：從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案（2/10）
系列：從鐵人賽到 Agent Orchestration — AI 自動建立 .NET 測試的完整方案（1/10）
2025 年 8 月到 9 月，我參加了 iThome 鐵人賽，花了 30 天寫完「重啟挑戰：老派軟體工程師的測試修練」這個系列。一直沒有在部落格這邊正式介紹過，趁這個機會寫一篇導讀，讓大家在還沒有把 30 篇全部看完也能瞭解裡面在講什麼。
30 天的內容從最基本的「為什麼要寫測試」一路寫到 Testcontainers、.NET Aspire 整合測試、TUnit，每一篇都有技術介紹說明、程式碼範例，以及我自己在專案裡踩過的坑。如果你對 .NET 測試有興趣但不確定要從哪裡開始看，這篇可以幫你省點時間。
另外，完賽之後我把這 30 天的測試知識重新整理成了 29 個 Agent Skills，讓 AI 可以直接拿來用。後續會有一系列文章介紹 `dotnet-testing-agent-skills` 這個專案 — 從 Agent Skills 到 Agent Orchestration 的完整方案。所以這篇鐵人賽導讀也算是後續系列的起點，先從源頭說起。
Vibe Coding 課程的繁榮與隱憂：當非技術出身的人開始販售「人人都能寫軟體」的夢想，轉職者與初階工程師該如何判斷？
GetCreationTimeUtc / GetCreationTime 其實都會有同樣的問題。
更正確地說 .NET 對檔案的 CreationTime 在 Windows 與 Unix-like (macOS、Linux…等，後面都統一稱呼 Linux) 的 OS 上定義不同。