dotnet 在 macOS 安裝後，要能完全移除其實需要一點 CLI 的知識外，也要多研讀一下 Microsoft Learn：
如何移除 .NET 執行階段和 SDK 的介紹。
或是使用 ".NET 解除安裝工具" 來進行。
但如果不介意統一用 brew 來安裝 dotnet 的時候；再加上一點點小技巧，那其實管理、使用與解除安裝時都會相對方便的。
在 iThome 舉辦的 iTHelp 2025 鐵人賽當中發表了 "莫名其妙就跟世界等級的 OpenSource 專案攪和了!?" 系列文。
其中 "EP 30 - .NET + AvaloniaUI + GStreamer 跨平台" 裡，有展示了在 macOS 當中使用 GStreamerPlayer 的應用程式 (透過 .NET + Avalonia UI + GStreamer 的技術)，來透過 GStreamer 的技術播放影片。
如果不是很能接受 Homebrew (或稱 brew) 只能在 "Terminal (終端機)" 當中透過指令操作 (CLI) 的話，可以試試看 WailBrew 這套軟體。
雖然是一套滿近期才推出的軟體，但實際安裝操作後看起來開發作者是還挺用心的。
值得一用~~~
GStreamer 是一個開源、跨平台的多媒體框架，最初由 Erik Walthinsen 於 1999 年開發，目前由 GNOME 社群與多方貢獻者持續維護。它的主要目標是提供一個高度模組化且可擴展的架構，方便開發者在不同平台上處理涵蓋：音訊 (Audio)、影像 (Video)、字幕 (Subtitles) 以及串流傳輸 (Streaming)...等類型的多媒體資料流。
(圖片取自 gstreamer 官網)
在 macOS 上可以透過直接在 GStreamer 官網下載 *.pkg 或是透過 Homebrew 來安裝。
如果在 前篇 沒啥意外，應該要順利的能透過 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
而微軟官方文件也有相關的撰寫：
在 前篇 中已經順利在 Visual Studio 登入 Apple Developer Account 並且透過 API Key 存取 Apple Developer 的相關資訊。
可是這時候注意到一件事情：
Status 顯示 Not In Keychain
若想要透過 Visual Studio 開發 .NET MAUI 並進行 iOS 應用程式的開發，勢必要在 Visual Studio 當中登入 Apple Developer Account，以利取得憑證等資訊。
取得相關資訊後，在進行 iOS 應用程式部署的時候(安裝到測試實機上) 或是打包發版(發佈到 AppStore Connect)的時候，都會相對簡便。
不過，現在不再支援直接使用登入帳號密碼的方式使用。
請改用 Apple Developer 的 API Key 來存取囉！
開發 Apple 的 iOS 應用程式，若在 Mac 裝置安裝好 Xcode 時，就可以透過 Xcode 直接建立該 Mac 裝置的機器憑證，送至 Apple 的 Developers 網站當中以利後續使用 "iOS 裝置" 開發或測試應用程式。
甚至，後續要將 iOS 應用程式發佈至 AppStore Connect 當中，無論是要先進行 TestFlight 測試；或是對自己的 iOS 應用很有信心要直接送審，也都是需要先有 Mac 裝置製作的機器憑證，作為 iOS 應用程式發佈憑證才行。
也就是說無論要用哪種開發技術，想要發佈 iOS 應用程式到 App Store 都必須處理這檔事。
Windows 上如果設定了時區(無論手動或自動)，透過 TimeZoneInfo 取出的時區識別碼，都是根據所設定的地區的時區，並且回應成 Windows 使用的 TimeZone 格式識別碼。
例如設定為 (UTC +08:00) 台北取出來的識別碼的值會為："Taipei Standard Time" 的字串資料。
但是…
這篇有提到：
在 macOS 上最主要就是要安裝 Xcode，而如果要安裝 Xcode 的管道，基本上有兩種：
- 透過 macOS 上的 App Store 安裝。(登入 Apple 帳號後即能免費下載使用)
- 透過 Apple Developers 網站來下載 .xip 安裝。(需要先有訂閱 Apple 開發者帳號才能下載使用)
本篇就來談談如何透過 .xip 來安裝 Xcode。
在 Nuget 的相依協助下，已經某種程度上可以是協助擺脫 dll hell 的一大工程(功臣?)
但是如果在一個解決方案當中有多個專案要引用相同的 Nuget 套件時，可能會發生各個不同的專案有各自使用不同 Nuget 套件的版本(套件相同版本不同)。
而每次要更新某個 Nuget 套件時就會要針對不同專案要處理更新，就會顯得相當繁瑣。
在 .NET 6.0 的設計中，開始可以使用中央的套件管理 Central Package Management (CPM) 的處理方式來處理這個問題。
在使用 .NET MAUI 的時候可以透過 Google 推出的 Android Emulator 來建立 Android Virtual Device (AVD)，以便進行基本的 Android App 開發與前期的測試。
雖然在 App 的開發到後期通常會直接使用 實際的裝置 進行測試會比較恰當，但不可質疑的 AVD 在 Android App 很多開發情境當中仍是扮演著測試環節中很重要的部分。
而 Google 所推出的 Android Emulator 可以透過 Visual Studio 當中的 "Android 裝置管理員" 來使用，並且建立所需的 AVD 環境。
續接前篇，趕緊來看看怎達成下圖效果吧！
在 Visual Studio 要透由 .NET MAUI 來開發 iOS 應用，連接 macOS 的環境並且使用 iOS Simualtor 進行開發上的處理，應該會是最輕鬆的方式。
由於 Visual Studio 在安裝 .NET MAUI 的工作負載時，只會安裝 "基本" 的 Android 所需的開發與執行環境。如果有遇到一些狀況需要其他的進階使用時，那對於 Android SDK 的元件安裝就必須再進一步的調整。
例如在 前篇 的介紹當中，要啟動所建立的 Android Emulator 時就 "可能" 會有看到類似的提示畫面：
可以怎樣進一步嘗試調整呢？
可以看看本篇介紹。
而由於 .NET MAUI 是一套建置跨平台應用的開發技術，所以如果要在 上回 所建構出的 .NET MAUI 專案，直接切換建置 Android 出應用程式並不是什麼難事：
使用 .NET MAUI 開發 Windows 應用不是什麼難事：
看看如何透過 Visual Studio 的安裝來設定相關的開發環境囉~~
這不是一個什麼 .NET 的新特點了…只是一個犯蠢的紀錄。
只是近期常常發生這種犯蠢的事情，所以來我獨自筆記一下。
