上一篇介紹了用 Azure AI Agent Service 來快速的建立 AI Agent，在發文後沒幾天，微軟在 Build 2025 大會上又公布了新的功能，也就是支援 Agent2Agent (A2A)，此功能讓我們可以快速的建立出一個 Multi-Agent，讓我們可以做出效果更好的 Agent，也可以重複利用 Agent，後面就來介紹如何實做。
日前幫同仁建立Linked Server的介接權限，設定完成後，同仁透過SSMS來展開該Linked Server，想檢視一下該Server的資料庫清單，但詭異的是她展開後發現SSMS UI沒有顯示任何的資料庫。
但用TSQL去抓取該Linked Server資料的確是OK的。這狀況不太符合以前經驗法則，印象中SSMS會列出該Linked Server中你有權限檢視的資料庫，故花了一點時間研究一下，終於可以重現該狀況，在此簡單紀錄一下。
pytest-bdd 是用 python 實作 cucumber 的框架，有在寫測試的開發者，肯定不能錯過
現在 LLM 越來越多，為了改善模型回應結果開始發展了透過 RAG 繼續來增加模型的知識或是透過 Function Calling 來增加功能，一直到現在發展的是 AI Agent，可以讓我們透過 LLM 完成更多的任務，而要開發 AI Agent 可以透過目前主流的各種 LLM 框架 (Langchain、Semantic Kernel 等) 來建立，上篇介紹了用 Azure AI Foundry 來部署 LLM，接下來介紹如何透過 Azure AI Agent Service 來建置和使用 AI Agent，可以透過微軟推出的這個服務來快速和測試我們的 AI Agent。
如果在 前篇 沒啥意外，應該要順利的能透過 Visual Studio 發佈經過簽署的 iOS 應用程式到 App Store Connect 當中。
不出意外的話…馬上就會出意外
，這是通則。
如果無法順利直接透過 Visual Studio 發佈經過簽署的 iOS 應用程式到 App Store Connect 當中的話，那該怎辦？
其實也別擔心，只要確定 Visual Studio 有產出經過簽署的 iOS 應用程式(*.ipa)，那就可以透過 Xcode 或是 Transporter 來發佈到 App Store 當中。
.NET MAUI 撰寫好 iOS 應用程式後，不外乎就是要發佈該 iOS 應用程式到 App Store Connect 當中，除非所寫的是專屬給企業內部使用的 iOS 應用程式。
而在 Xamarin 的時代就已經可以透過 Visual Studio 的介面操作，直接發佈 iOS 應用程式的 *.ipa 到 App Store Connect，詳情請看：
透過 Visual Studio 串接 App Store Connect 發佈 iOS App
https://dotblogs.com.tw/jamestsai/2020/06/05/Using-Visual-Studio-publish-iOS-App-to-App-Store-Connect
而微軟官方文件也有相關的撰寫：
上篇 使用 Memory 作為 Web API 的 Repository，這次改用 Postgresql 並搭配 DI Container，也包含了資料庫的操作驗證
在 前篇 中已經順利在 Visual Studio 登入 Apple Developer Account 並且透過 API Key 存取 Apple Developer 的相關資訊。
可是這時候注意到一件事情：
Status 顯示 Not In Keychain
這是 Visual Studio 裡的一個延伸模組 (Extension)，大約在四五年前在 Visual Stuidio 2019 時就已經發佈的一個工具，而我在過去帶新人教單元測試時都會介紹這個工具，透過這個工具取得測試的程式碼覆蓋範圍。
因為我平常的開發工具是使用 JetBrains Rider，已經有內建 Code Coverage 的功能，我只有在做教學或寫文件、找問題、重現別人問題情境的時候才會開啟 VS2022，在三月底四月初時這個工具產生 Code Coverage 的功能都還正常，但是卻在前幾天因為在整理文件時久違地開啟 Visual Studio 2022 並且要取得 Code Coverage 卻出現了異常，在找尋問題原因以及嘗試如何解決花了不少的時間，最後是順利地找到原因並且排除了狀況。於是就寫了這篇文章來介紹工具並說明要怎麼解決異常狀況。
若想要透過 Visual Studio 開發 .NET MAUI 並進行 iOS 應用程式的開發，勢必要在 Visual Studio 當中登入 Apple Developer Account，以利取得憑證等資訊。
取得相關資訊後，在進行 iOS 應用程式部署的時候(安裝到測試實機上) 或是打包發版(發佈到 AppStore Connect)的時候，都會相對簡便。
不過，現在不再支援直接使用登入帳號密碼的方式使用。
請改用 Apple Developer 的 API Key 來存取囉！
如果根據 前篇 操作後有發現 macOS 所建立的憑證不受信任的話，請參考此篇處理。
開發 Apple 的 iOS 應用程式，若在 Mac 裝置安裝好 Xcode 時，就可以透過 Xcode 直接建立該 Mac 裝置的機器憑證，送至 Apple 的 Developers 網站當中以利後續使用 "iOS 裝置" 開發或測試應用程式。
甚至，後續要將 iOS 應用程式發佈至 AppStore Connect 當中，無論是要先進行 TestFlight 測試；或是對自己的 iOS 應用很有信心要直接送審，也都是需要先有 Mac 裝置製作的機器憑證，作為 iOS 應用程式發佈憑證才行。
也就是說無論要用哪種開發技術，想要發佈 iOS 應用程式到 App Store 都必須處理這檔事。
微軟將 Azure AI Studio 以及 Azure Open AI 和其他 Azure AI 的服務整合之後推出了 Azure AI Foundry 這一個服務平台，讓我們在使用 Azure AI 服務的時候有同一個入口來管理和使用 Azure AI 的服務，而我們也可以在上面部署各式各樣的 LLM 模型，包含 Azure OpanAI 都可以在這邊部署並提供一個遊樂場讓我們可以免寫程式來測試部署好的 LLM 模型，後面就來介紹如何部署以及測試，最後也實做程式要來串接部署好的模型。
在開發系統時，如果測試情境的輸出會有許多資料類別並且要驗證很多欄位時，會利用 object graph 比對整個結果是否和預期一致。
現在我的專案裡有個 CustomerRootData 類別，裡頭屬性為十幾個不同型別的子集合，每個類別都有 UpdateTime、UpdateUser 這兩個欄位，但這兩個欄位是在程式執行當下才寫進去的，不屬於測試驗證的重點，在寫測試的時候常常陷入重複設定的地獄。
於是在 AwesomeAssertions / AwesomeAssertions Object Graphs 的架構下，想辦法在做比對時去做到比較方便省事的設定方法，讓我輕鬆地去排除指定的欄位。
在找尋資料、解決方法的同時，也讓我得知不一樣的處理方式，將這些處理方式用文章記錄下來，也提供給大家做個參考。
其實這也不是新聞了，早在今年 1/15 時大家就已經知道並且被商業授權的費用給嚇了一大跳（每個人 $129.95 USD）。
現在特地寫一篇是因為上週因為 AutoMapper 將要變成商業化授權而寫了兩篇文章介紹替代套件，就想到好像並沒有對於 Fluent Assertions 轉變為商業授權去寫一篇文章與替代方案，於是就以 Fluent Assertions 從 v8.0.0 起轉為商業授權，簡單寫了這篇去說明授權限制、專案應對策略，以及替代的 Assertion Library，提供給大家做個參考。
調整設定搭配命令列模式 , 快速進行 SQL Server 安裝
Mapperly 在以前找尋替代 AutoMapper 的時候就有看過，但當時著重在與 AutoMapper 設定與操作習慣相近的替代套件，所以對於 Mapperly 就沒有太多的關注。
直到寫了「替換映射工具 - 使用 Mapster」這篇文章後才稍微去看看 Mapperly，發現到它和 AutoMapper, Mapster 雖然都是屬於 Mapping 工具，都是做物件對映轉換的處理，但設定與使用上就有蠻大的差別，所以寫篇文章做個簡單的紀錄。
整合 GitHub Action 在 Self Host Runner - 不分平台篇
整合 GitHub Action 在 Self Host Runner - Android 篇
整合 GitHub Action 在 Self Host Runner - iOS 篇
建立 GitHub Action Self Host Runner
其實四年前就已經將手邊專案由原本所使用的 AutoMapper 以 Mapster 取代了。
起初的原因是效能考量，因為 AutoMapper 的效能一直被人詬病，但也因為 AutoMapper 的優點在於功能豐富、配置設定靈活，能夠處理複雜的 Mapping 需求，以致於我在帶新人的時候還是以 AutoMapper 為主，但是前些日子得知 AutoMapper 在之後也將走上商業化（跟 Fluent Assertions 一樣），所以就藉此來寫篇文章簡單介紹 Mapster。
在 python 利用 FastAPI 建立 API 非常的簡單，同樣的，要測試它也非常地容易，這裡我會使用一個簡單的例子，演練 pytest 測試 API (FastAPI)
今天 (2025-04-06) 早上在 Facebook - 台灣 .NET 技術愛好找論壇裡看到 Will 保哥轉貼了一則 X 貼文，
要檢查一個集合物件是否有元素在內，會使用哪一種語法來檢查 …
在 C# 開發中，經常需要判斷一個集合是否有包含任何元素。雖然這是一個簡單的判斷，但其實背後有不少值得探討的細節。就來瞭解這四種常見的做法，並分析它們的優缺點與適合的使用情境。
對於階層式的資料，除了利用紀錄父階層的 Id 之外，SQL Server 可以使用其特別專屬的 hierarchyid 來做處理
