之前工作忙到沒時間寫筆記，每天不是加班，就是想要加班但心情煩悶導致沒加班，就更沒心情寫筆記了。最近離職，頹廢一陣子，情緒還沒調整過來，不過感覺還是要加減寫點東西，就稍微記錄一下。 前言 在過往，Entity Framework 有提供 Database First 的開發方式。但是在 Entity Framework Core 中只剩下 Code First。 雖然可以使用反向工程從資料庫產生 EF 程式碼來模擬 Database First 的效果，但此時會遇到兩個主要問題： 指令複雜：反向工程的指令不同，產生的程式碼會不太一樣，增加因操作錯誤造成程式碼差異的風險。 客製化限制：針對產生的程式碼能進行的客製化很有限。

操作步驟 步驟 1：準備 JSON 資料 複製你要轉換的 JSON 內容，例如： { "User": { "Id": "Wing", "Name": "小翼", "Dept": { "Id": "SAO",

最近開始想把 LOG 儲存在 Elasticsearch 裡，但這樣做需要有個方便查詢的 UI 介面，對我而言 Kibana 功能過於複雜，Postman 查詢又比較麻煩。後來發現了 Elasticvue 這個工具，選擇它的原因是它支援多種瀏覽器擴充套件及桌面應用程式版本。 Elasticvue 的查詢介面主要基於 query_string 語法，這是 Elasticsearch 中基於 Lucene 查詢語法的擴展版本。對熟悉 SQL 的使用者來說，query_string 比其他 DSL 語法更容易上手，因此我整理了一些常用的語法方便查閱。 可從 Elasticvue 官網 查看各個瀏覽器擴充套件，或是桌面應用程式的安裝檔案或連結。 基本語法 基本 API 結構 { "query": {

我去年從同事那裡聽到 Shadow Copying 這個名詞。Shadow Copying (陰影複製) 是一種機制，它會將應用程式的檔案複製到另一個暫存位置然後從那裡執行，而非直接從原始部署位置執行。這解決了 ASP.NET Core 在執行時的一個常見問題：當 Web 應用程式正在運行時，相關 DLL 會被鎖定，導致無法直接更新檔案，必須先停止應用程式集區才能進行更新。 起初，我查閱了保哥的「如何啟用 ASP.NET Core 6.0 部署到 IIS 的陰影複製 (Shadow-copying) 功能」文章，發現需要手動修改 web.config。然而，我一直秉持「發佈時就應該產出完整設定」的原則，不希望每次都要手動調整設定檔，因此一開始沒有採用這個機制。 後來我採取的方式是第一次發佈時手動修改 web.config 加入 Shadow Copying 功能，後續版本更新時則不再變動此設定檔。但這個做法仍然不夠理想，因為若在交接或佈版過程中出現疏失，不小心覆蓋了原有的 web.config，Shadow Copying 機制就會失效。這種作法特別不適合導入 CI/CD 流程，因為在自動化腳本中處理 web.config 的修改較為困難，容易出錯。 最近我發現了一個更好的解決方案：如果在 Web 專案根目錄預先放置一個 web.config 檔案，發佈後的 web.config 就會以此為基礎產生。這讓自動化部署變得更加簡單。 以下是正常發佈後的 web.config：

之前曾經寫過如何自行開發套件並發佈到 NuGet Server 上，詳情可參考使用 Visual Studio 發佈帶有預設檔案的 NuGet 套件。若想了解版本號控管，則可參考使用 MinVer 自動化 .NET 類別庫的版本號管理。 不過如果是開發公司內部使用的公用套件時，就不適合發佈到公開的 NuGet Server 上。 使用 GitLab Packages 作為套件庫 如果已經使用 GitLab 作為版本控制系統，便可以利用它的 Packages 庫作為套件來源。我通常建議創建一個專門的 GitLab 群組，將作為套件的專案放在此群組下，讓專案能夠使用該群組作為 Packages 庫。 不同於 NuGet Server，GitLab 並沒有提供直接上傳 nupkg 檔案的 UI 介面。不過既然使用 GitLab，我們可以充分利用 GitLab CI/CD 來實現自動發佈流程。 設定 GitLab CI/CD 自動發佈

年紀大了，記憶不好，每次安裝 Visual Studio 都要花時間查一下之前安裝了哪些套件，及套件功能是什麼，所以寫一篇文章記錄下來。 Visual Studio 的擴充套件 Productivity Power Tools：下列套件屬於「Productivity Power Tools」 同捆包的一部分。Double-Click Maximize 2022：點擊兩下來最大化 Visual Studio 視窗。 Fix Mixed Tabs：偵測程式碼是否同時有 Tabs 和空格，並提供轉換為其中之一。 Match Margin：Highlights 所有游標所指向的文字。 Middle Click Scroll：使用滑鼠滾輪來移動文檔。 Shrink Empty Lines：縮小空白行高度。 Solution Error Visualizer：在 Solution Explorer 顯示錯誤提示。 Time Stamp Margin：在 Debug 模式下，輸出視窗增加顯示時間訊息。

最早期，我是使用 Visual Studio 的 Automatic Versions 功能來管理套件版本號。 後來轉向使用 GitVersion 配合 Git 標籤進行版本號管理，但當 GitVersion.MsBuild 升級到 6.0.0 後，設定機制有所變更，導致原先的設定失效。雖然嘗試過多種方法，但始終無法正確配置，同時我也發現在功能分支上的版本號表現不如預期。 在尋找替代方案時，我想起之前在其他開源套件中見過 MinVer，因此決定改用它來處理版本號。MinVer 比 GitVersion 設定更為簡單直觀，主要依靠 Git 標籤進行版本控制，詳細說明可參考其 Github 頁面。 MinVer 版本號規則 基本運作原理 以下內容來源自 MinVer Github：

最近又開始研究 GitLab CI/CD，其實這項工作早就開始進行的，但因為一直斷斷續續地研究，導致我常常需要重新查某些語法的用途。乾脆讓 Claude 幫我把一些常用語法整理下來，方便日後查閱。 基本結構 GitLab CI/CD 的配置檔案是 .gitlab-ci.yml，這個檔案定義了你的專案在 GitLab CI/CD pipeline 中應該執行的任務。 一般檔案命名如下： 主要 CI/CD 配置檔案: .gitlab-ci.yml (固定名稱)。 包含檔案 (includes): 通常使用 .gitlab-ci-*.yml 格式，例如：.gitlab-ci-deploy.yml。 .gitlab-ci-build.yml。

前段時間在看 ChatRTX 時，我看到 Whisper 這個名詞。經查詢後發現，OpenAI Whisper 是 OpenAI 於 2022 年 9 月發布的語音轉錄和翻譯 AI 模型。如果想了解更多資訊可以參考 What is OpenAI Whisper? 這篇文章。 對於像我這樣的 AI 新手來說，要自己建立環境來運行這個模型有點困難。不過，有人開發出可以直接使用的離線版工具 WhisperDesktop。 下載與安裝 從 GitHub 儲存庫首頁右側邊欄的 "Releases" 區域點擊最新版本，目前版本是 Version 1.12。 在 Release 頁面的 "Assets" 區域下方，點擊紅框標示的 WhisperDesktop.zip 進行下載。 解壓縮後，會看到以下三個檔案：WhisperDesktop.exe：實際執行檔案。

紀錄等級 以下是根據在 C# 和 .NET 中進行日誌記錄所定義的各種等級及建議使用時機。其中 None 值最高，主要用於在 Filter 設定中完全停用所有 LOG。 等級 值 方法 描述 追蹤 (Trace) 0

一直常常忘記 thisisunsafe 的指令，所以寫一篇筆記。 SSL 憑證不安全的原因 當看到瀏覽器顯示 SSL 安全警告時，通常是因為以下原因： SSL 憑證是自簽名的，而非由受信任的憑證機構簽發。 SSL 憑證已經過期。 憑證與網站的網域名稱不匹配。 你的瀏覽器不信任發出此憑證的機構。 內部開發環境使用的測試憑證。

之前在 Windows 環境下的單節點 Elasticsearch 安裝指南 撰寫 Elasticsearch 的安裝筆記，之前研究了 2 ~ 3 天，終於成功把 Kibana 環境也架起來了，想說趁還有記憶，趕快也寫一份筆記，雖然後續 SSL 卡關，又拖稿兩週，才把這篇生出來。 下載與安裝 前往官方網站下載 Windows 版本的 Kibana。 網址：https://www.elastic.co/downloads/kibana。 下載 Windows 的 .zip 檔案。 目錄結構說明 bin：執行檔目錄。 config：設定檔目錄。

下載與安裝 前往官方網站下載 Windows 版本的 Elasticsearch。 網址：https://www.elastic.co/downloads/elasticsearch。 下載 Windows 的 .zip 檔案。 目錄結構說明： bin：執行檔目錄。 config：設定檔目錄。

hackmd-github-sync-badge 目前網路上的 Git Commit 規範多數來自於 Angular 團隊的格式，隨著時間延伸出許多版本。雖然這些資訊在網上隨處可見，為了防止遺失，我還是決定寫一篇文章紀錄，畢竟我五年前看到的文章現在也找不到了。目前的「[Angular Commit Format]」是這樣的。(https://github.com/angular/angular/blob/main/CONTRIBUTING.md)。 Commit Format Angular Commit Format 規範分為 header、body 和 footer 三個部分，各部分用空行隔開。其中 header 是必填的，body 視 header 的 type 而定（若 type 為 docs，則必填），footer 是選填的。 <header> <BLANK LINE> <body>

前言 本文只記錄在後端開發工作中，針對 Web API 檔案上傳處理方式的一些思考和經驗，不涉及具體實作程式碼。由於知識有限，不會涉及分片上傳等進階作法。 開發模式與資料接收方式 全端開發：在沒特別用 ajax 處理的情況下，大部分都是直接 Submit 表單資料，後端使用 [FromForm] 接收資料。 前後端分離：大部分使用 ajax 傳遞 JSON，後端使用 [FromBody] 接收資料。 兩種主要處理方法 方法一：使用表單 Submit 或 FormData 優點：

最近負能量太大了，檢討一下，決定寫筆記轉移一下注意力，順便來給徒弟留個紀錄。 前言 在現代網路安全環境下，越來越多的郵件伺服器正逐步停止支援使用應用程式密碼透過 IMAP 協議來存取電子郵件。 例如：Exchange Online 淘汰基本驗證 和 Gmail 對低安全性應用程式的存取控管。 上述兩篇文章都說明了服務供應商正在從應用程式密碼驗證方式轉移到 OAuth 驗證機制。目前我尚未研究如何實作 OAuth，Gmail 使用者仍可透過啟用兩步驟驗證後，繼續使用應用程式密碼來存取郵件。 IMAP 服務啟動

最近加班忙翻了，最近才比較有空補之前的筆記 orz，但有點懶，就不截圖了。 許多政府單位在系統開發時，都會要求 Excel 匯出功能必須同時支援 ODS 格式。在 .NET 生態系統中，處理 ODS 的套件大多是付費的，就算有免費版本也會有功能限制。因此，常見的解決方案是先產生 Excel 檔案，再透過 Microsoft.Office.Interop.Excel 來讀取主機上的 Office Excel，將檔案另存成 ODS 格式。 不過這個做法在本機開發時可能運作正常，但部署到 Server 環境後就會碰到一些問題。以下列出一些我遇到的問題。 dotnet publish 編譯異常 因為 COM 元件的特性，這種處理方式只能在 Windows 環境底下使用。 Visual Studio 的發佈功能跟 dotnet publish 指令都是以 MSBuild 為基礎，不過它們用的執行環境可能不一樣，所以會造成行為跟輸出結果有些差異。Visual Studio 是使用安裝在 Visual Studio 裡面的 MSBuild，而 dotnet publish 則是用 .NET SDK 裡面附的 MSBuild 版本。再加上兩邊在專案設定跟參數處理上可能有差異，這就會導致在 Visual Studio 可以正常編譯，但用 dotnet publish 的時候卻會跳出以下錯誤：

hackmd-github-sync-badge 在建立 ASP.NET Core Web API 專案時，透過「啟用 OpenAPI 支援」的設定，可自動安裝 Swashbuckle.AspNetCore 這套 Swagger 套件，但目前該套件尚不支援 Enum 的註解功能，這導致使用端難以準確理解如何傳遞參數和回傳值的含意，與回傳值含意。即使在具有 Enum 的屬性增加屬性的註解，也依然沒作用。 以下列程式碼作為範例： [ApiController] [Route("[controller]")] public class TestEnumController : ControllerBase { [HttpPost]

之前我一直無法理解 RESTful 的 PATCH 要如何實現。雖然我曾經嘗試使用 null 來區分是否要更新某個欄位，但這樣的做法只能適用於字串型別，因為在資料庫中，我會選擇存空字串。因此，只能將欄位的值更新為空字串，而不會將其更新為 null。不過，對於像 DateTime 這類的 struct 型別，當資料庫允許 null 值時，就會遇到無法辨識應該忽略欄位還是將其存儲為 null 的問題。 我是不清楚業界的普遍處理方式，我能想到的做法是前後端約定某個特定值來代表不更新該欄位，或者增加一個註記欄位來辨識是否需要進行更新。我個人比較偏好後者的方案。 我的想法是由後端來處理這個註記，而前端則依據是否傳遞指定屬性來判斷是否進行更新。這樣不論是需要可選更新還是必須傳入的屬性，都不會影響到資料結構。 要完成我的想法，需要針對以下幾個方面進行處理： 代表可選屬性的 struct 型別。 如果資料來源是 [FromBody]，則需撰寫該型別的 JsonConverter。

在開發套件的時候，為了確保建構子或方法的參數符合預期，通常會進行 null 或空字串等參數檢核，為了簡化操作與統一錯誤訊息，我通常會寫個 ExceptionUtils 的靜態類別來進行檢查，範例如下： public static class ExceptionUtils { public static void ThrowIfNull<T>(Expression<Func<T?>> expression) { _ = expression.Compile().Invoke() ?? throw new ArgumentNullException(GetMemberName(expression)); } public static void ThrowIfNullOrWhiteSpace(Expression<Func<string?>> expression) { string? value = expression.Compile().Invoke();