James's Tech & Life Blog

(圖片取自 Gogoro 官網活動)

2026/1/26~2026/2/1 有到 7-ELEVEn 換電站交換電池的 Gogoro 車主，可獲得一點小確幸唷！

先回顧一下在 "前一篇" 當中有提到基本的使用架構：

+--------------------+                          +--------------------+
|   Server Process   |         Named Pipe       |   Client Process   |
|                    | <----------------------> |                    |
|   NamedPipeServer  |       \\.\pipe\demo      |   NamedPipeClient  |
+--------------------+                          +--------------------+

當前手上接觸到的一個系統專案，其整體的程式架構概念可以簡化成：

HW/FW ←→ CLI ←→ GUI

HW/FW 的程式，大多是透由 C/C++ 撰寫，這部分有專業的人員處理開發；而系統中的 CLI 與 GUI 這兩部分的程式，是仰賴 .NET 來進行開發的。

也因此隨著 .NET 的跨平台發展，便得以讓這兩部分的程式，除了既保留在 Windows 上的順利運作，也能逐步有序地從轉移至 Linux 當中運作。

也就是 .NET 一直強調的： 

Write once, run multi-platform.

^{(原文為 Write once, run everywhere. 在此做些文字改動)}

在電腦的 Process 與 Process 之間要相互通訊（IPC, Inter-Process Communication），粗略的來分可以有兩種方式：

• Socket
• Pipe

以下列出對照：

透過 .NET API 的 Process 所提供記憶體資訊的屬性運用，可以自我監測 .NET 應用程式佔據記憶體的狀況。

以下列舉三個屬性來介紹：

在前篇這樣的兩個應用程式的撰寫在 Windows 上執行時是可以順利完成所需的要求。

但一旦放到 "非 Windows" 上的環境執行時，卻發生了異狀：
應用程式 A 居然找不到應用程式 B 所建立的 Mutex。

發生了執行 30 次(每次等待 1 秒後再找) 後，直接結束應用程式 A 的情況。

難道？？？

名詞定義：
Process - 已被載入到記憶體中執行的 Program 。

應用程式 A 需要等待應用程式 B 完成動作 C 之後，才能繼續執行；換句話說，在 B 執行完 C 之前，應用程式 A 必須被 blocked（阻塞）或 paused（暫停）。

這樣的需求，在現代化的作業系統的設計中，有很多種方式可以完成，例如：signal、pipe、mutex、semaphore…等。

在 iThome 舉辦的 iTHelp 2025 鐵人賽當中發表了 "莫名其妙就跟世界等級的 OpenSource 專案攪和了!?" 系列文。

其中展示了： 

1. 在 Windows 
2. 在 Ubuntu (透過 WSL)
3. 在 macOS

三種桌面環境中的 .NET 裝置端應用程式，並使用了 GStreamer 的技術來播放多媒體資訊，而其中 Samples 底下共有兩個專案。

一個是純 Console 的專案；一個是使用 Avalonia 的 UI 專案。

如果在 WSL 中已安裝 Ubuntu - 22.04 的環境，要如何升級到最新 LTS 版本呢？

在 Microsoft Store 的 Ubuntu 的描述當中，看到了這樣的設定：

sudo do-release-upgrade

在 iThome 舉辦的 iTHelp 2025 鐵人賽當中發表了 "莫名其妙就跟世界等級的 OpenSource 專案攪和了!?" 系列文。

其中 "EP 30 - .NET + AvaloniaUI + GStreamer 跨平台" 裡，有展示了透過 WSL 在 Ubuntu 的環境中使用 GStreamerPlayer 的應用程式 (透過 .NET + Avalonia UI + GStreamer 的技術)，來透過 GStreamer 的技術播放影片。

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 來安裝。

https://brew.sh/

Homebrew 或稱 brew 是一套在 macOS 上簡易且方便使用的套件管理工具。

還記得 "在 Apple 的 App Store Connect 建立 App 準備使用 TestFlight 測試 - 外部 (a.k.a 公測)" 當中，最後有產生一個 TestFlight 的連結嗎?

那這個連結可以怎麼使用呢？

本篇文章在介紹從 Apple 的 App Store Connect 中為 iOS App 建立 TestFlight 外部測試群組；並且將 App 加入測試建置版本、填寫 Beta App 審查資訊、建立公開連結，並在版本通過審查後讓外部測試人員安裝測試的完整流程。

透過先建立 testflight 專用的外部測試連結後，再等待 Apple 將送至 Beta 審查的 App 審查完成後，就能把已核准的建置版本正式提供給外部測試人員開始進行外部測試。

本篇文章主要是要介紹在 AppStore Connect 中為 iOS App 建立 TestFlight 內部測試流程的幾個關鍵點。

從建立內部測試群組、指定內部測試人員，到綁定建置版本並填寫測試內容。

整體流程就像替 App 啟動一條路，並先把測試團隊放到正確位置，再把可測試的 App 版本送到 AppStore Connect 後，標示一些測試訊息，也能替參與的測試者理解到此版本的測試方向。透過這些指引畫面，可以清楚掌握 TestFlight 內部測試的準備步驟。

讓 App 在正式上架前可以先進行一輪有秩序、可追蹤、也更安心的 TestFlight 的內部測試。

這次要操練的對象是 Apple 的 App Store Connect，並且在其中建立一個 App 可供上傳：

也就是讓 App Store Connect 則成為 App 正式亮相前的後台舞台，從 App 名稱、語言、Bundle ID 到 SKU，都必須與前面建立好的資料互相呼應。整個流程的核心不是單純填表，而是替 App 建立一條可信任、可追蹤、可發佈的路徑。

如果在 前篇 沒啥意外，應該要順利的能透過 Visual Studio 發佈經過簽署的 iOS 應用程式到 App Store Connect 當中。

不出意外的話…馬上就會出意外，這是通則。

如果無法順利直接透過 Visual Studio 發佈經過簽署的 iOS 應用程式到 App Store Connect 當中的話，那該怎辦？

其實也別擔心，只要確定 Visual Studio 有產出經過簽署的 iOS 應用程式(*.ipa)，那就可以透過 Xcode 或是 Transporter 來發佈到 App Store 當中。