Microsoft Teams 一直有著很令人詬病的兩大問題：
似乎在近期似乎有改善多了？不過，這兩個問題不是這篇文章想討論的。
由於近期配合上微軟總部想透過辦 GitHub Copilot 的活動：GitHub Copilot Dev Days 推廣 GitHub Copilot，就想說來搞一場 GitHub Copilot Dev Days | Taipei 的 線上 活動。
而幾年前有好幾次利用 Microsoft Teams 整合 NDI 技術並透過 OBS 進行直播的一些經驗。
"對 GitHub 的 Organization 中的成員設定 GitHub Copilot : 解釋篇" 所提到的 Organization 請理解為：
群體
這個 "群體" 可能會是：
…等這樣的詞彙解釋。
在 AI 盛行起來後，在數位世界中的任何一個 "單位" 中有可能存在多個 "人類" 或 "Agent" 的個體，那就適用這個 "Organization" 的觀點。
在 GitHub Copilot (以 2026Q1 這時間點瞭解到) 所設計的各種 Plans 來看，在使用上分成兩大區塊：
如果你就是只有一個人，基本上都是 Individuals (個人/獨立個體商)。
這樣的使用情境大概就是，想要自己放飛自我寫程式或是整間公司就只有你一個人，不用跟其他任何 "人類" 或 "Agent" 有交流與互動就能完成工作，那可以選的 Plan 有：
GetCreationTimeUtc / GetCreationTime 其實都會有同樣的問題。
更正確地說 .NET 對檔案的 CreationTime 在 Windows 與 Unix-like (macOS、Linux…等，後面都統一稱呼 Linux) 的 OS 上定義不同。
目前手上常用來建置與發佈程式的 CI/CD 服務與架構系統，大略可簡化為 "GitLab 的雲端服務 + 地端主機上所運作的 Docker"。
目前手上常用來建置與發佈程式的 CI/CD 服務與架構系統，大略可簡化為 "GitLab 的雲端服務 + 地端主機上所運作的 Docker"。
在使用 GitLab 進行專案管理時，透過範本建立專案可以大幅減少初始化設定的時間。
這篇來介紹一下如何在 GitLab 中使用 .NET 專案範本 (dotnet template) 建立第一個專案，從建立 GitLab Project、套用範本，到完成基本的專案結構與設定。
這樣可以快速建立標準化的 .NET 專案環境，為後續的版本控制與 CI/CD 自動化流程奠定一定程度的基礎。
先回顧一下在 "前一篇" 當中有提到基本的使用架構：
+--------------------+ +--------------------+
| 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），粗略的來分可以有兩種方式：
以下列出對照：
| Pipe | Socket | |
|---|---|---|
| IPC | ✔ | ✔ |
| 跨電腦 | ✔ (需在 Windows 透過 SMB 服務) | ✔ |
| 效能 | ⭐⭐⭐ | ⭐ |
| 跨網路通訊 | ❌ | ✔ |
| 使用難易 | 易 | 難 |
透過 .NET API 的 Process 所提供記憶體資訊的屬性運用，可以自我監測 .NET 應用程式佔據記憶體的狀況。
以下列舉三個屬性來介紹：
| 屬性 | 意義 |
| PagedMemorySize64 | 可被分頁到磁碟的記憶體數字 |
| PrivateMemorySize64 | 程式跟系統請求使用的專用記憶體數字（不會跟其他行程共用的部分） |
| WorkingSet64 | 實際駐留在 RAM 的記憶體數字 |
在前篇這樣的兩個應用程式的撰寫在 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 專案攪和了!?" 系列文。
其中展示了：
三種桌面環境中的 .NET 裝置端應用程式，並使用了 GStreamer 的技術來播放多媒體資訊，而其中 Samples 底下共有兩個專案。
一個是純 Console 的專案；一個是使用 Avalonia 的 UI 專案。
在 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 來安裝。
