Microsoft Teams 一直有著很令人詬病的兩大問題：
似乎在近期似乎有改善多了？不過，這兩個問題不是這篇文章想討論的。
由於近期配合上微軟總部想透過辦 GitHub Copilot 的活動：GitHub Copilot Dev Days 推廣 GitHub Copilot，就想說來搞一場 GitHub Copilot Dev Days | Taipei 的 線上 活動。
而幾年前有好幾次利用 Microsoft Teams 整合 NDI 技術並透過 OBS 進行直播的一些經驗。
隨著作業系統的升級或發展過程，在當前安全威脅日益高張的年代，當然作業系統的相關安全性與設計也會隨之強化。
硬體的驅動程式是會跟作業系統 (OS) 直接作動的，所以從安全性的角度來看，隨著時間的推進而造成一些外部裝置的驅動程式過於老舊，沒有跟著新版作業系統的安全性設計而改版，產生與新版作業系統發生不相容問題，也不難理解。
但是就這樣把問題都推給微軟，說通通都是 Windows 11 的錯，這就很難令人理解了🤔
反觀果粉就不會有這種心態…很妙😏
GetCreationTimeUtc / GetCreationTime 其實都會有同樣的問題。
更正確地說 .NET 對檔案的 CreationTime 在 Windows 與 Unix-like (macOS、Linux…等，後面都統一稱呼 Linux) 的 OS 上定義不同。
目前手上常用來建置與發佈程式的 CI/CD 服務與架構系統，大略可簡化為 "GitLab 的雲端服務 + 地端主機上所運作的 Docker"。
目前手上常用來建置與發佈程式的 CI/CD 服務與架構系統，大略可簡化為 "GitLab 的雲端服務 + 地端主機上所運作的 Docker"。
在 GitLab.com 申請好的帳號與建立第一個專案的 Repo 之後，就可以進行 Pipeline 的使用。
根據 ChatGPT 對 GitLab 中的 Pipeline 其定義是：
在程式碼變動時，自動執行 CI/CD（Continuous Integration / Continuous Delivery）流程。
技術一點的說：
當程式碼有異動的時候時，GitLab 會依照 .gitlab-ci.yml 的設定，根據 Pipeline 中所設計的 Stages (階段)，如: 建置、測試、部署…等，來自動化的執行一連串 Jobs (工作)。
在使用 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 的記憶體數字 |
如果需要在 UI 上需要呈現統計圖表的話，LiveCharts2 是一套很不錯的統計圖表的套件，除了完全 OpenSource 外也如官網所提到的，對於 .NET 相關跨平台 UI Framework 都有支援。
https://livecharts.dev/#frameworks
如果考慮 UI 呈現的感覺與效果，個人覺得 LiveCharts2 實在稱的上是 .NET 跨平台開發者在統計圖表上的不二選擇！
在前一篇 "Avalonia.MAUI Hybrid 之使用 .NET MAUI Essentials 實作篇 - I" 所完成的基礎下，在此篇就能繼續加入相關的 .NET MAUI Essentials 的使用。
不過，還是要提醒一下，如果未完成 Visual Studio 所提供的 .NET MAUI 開發，並完成 Android 、 iOS 環境所需的建置。
那將無法完成本篇所講的部分測試結果。
Avalonia.MAUI Hybrid 之使用 .NET MAUI Essentials 介紹篇 提到的相關部分，如果是沒有接觸過 Avalonia UI 跟 .NET MAUI 一段時間的話，感覺要實際使用會有點難。
雖然 Avalonia.MAUI Hybrid 的 Repo: Avalonia.MAUI Hybrid 中有提供 Sample Code，但不知道為啥直接要使用時搞了一陣子都沒辦法成功。
最後只好自己實際來操作一次，透過 Avalonia UI 所提供的 Visual Studio 2022 所建立的專案範本開始建立起。
看看怎一步一步的完成囉~~~
在跨平台開發技術上若單就 UI 層面的跨平台的話，在 .NET 技術上有三套廣為人知的使用 .NET MAUI、Avalonia UI、Uno Platform。其各有千秋，在此就不多談相關比較(若有興趣可參考文後所推薦閱讀連結)。
近期則有比較特別的部分是 Avalonia UI 官方的 GitHub 推出了一個 Repo: Avalonia.MAUI Hybrid
雖然支援有其作業系統上的限制性(目前只支援 iOS、Android 兩套手機作業系統)，但仍對 Avalonia UI 來說是一件相當有吸引力的事。
.NET 6 去年 11/8 正式發佈至今已經屆滿半年，而在今年的 Build 大會上也正式發佈 .NET MAUI (a.k.a. 下一代的 Xamarin.Forms，原 Xamarin.Forms 會持續維持在 5.x.x)。
而正常來說 GA 後的技術都會加到 Visual Studio 的 "Release Channel" 當中，但稍微弔詭的地方是 .NET MAUI 仍是被放在 "Preview Channel" 的 Visual Studio 當中。
所以…
要使用 .NET MAUI 的話，必須安裝 Visual Studio 2022 Preview 的版本來使用。
如果按照標題的概念來看，其實網卡的 DNS 設定錯誤，仍然是可以上網的…
所有的連線都要轉成 ip 位址的方式。
不會有人去記住要使用的網站 ip 吧!
好，就算記住了，Android 系統的相關連線服務也還是靠 DNS 才能正確連線使用阿…所以還是來知道一下怎麼處理吧!
由於近期線上工作、會議、課程的需求激增，要讓公司/組織/團體在 Teams 當中加入外部的來賓帳號(就是大眾常用的免費 email 服務帳號，如: gmail、outlook/hotmail、yahoo...等)，來一起加入協同工作、會議或課程，該怎麼辦呢?
而如果使用時其實是可以透過各款主流的網頁瀏覽器，登入 "微軟帳號" 後進入到受到邀請的團隊，就可以直接使用 Teams 服務了。
Skype 這個服務在網路開始能利用語音通訊後，就在剛進入 Y2K 年代左右時奇蹟般地出現在大眾的眼前，別忘了在網路頻寬還不夠大、網路速度還不夠快、通話載具也不是這麼便利的時代，要雙方都直接用網路進行語音通訊，根本還沒辦法很簡便的進入到平常大眾的使用範疇中。
但 Skype 的服務在當時，並不冀求雙方都是利用網路進行語音通話，而是從 Skype 端撥打語音通話到電話當中，甚至是能透過電話回撥到 Skype 端的部分。
而透過收取比一般撥電話還便宜的費用，來做為 Skype 服務的營利基礎。
在那個年代要進行一通跨國通話，基本上雙邊都由各國的電信業者把持，所費不貲(就算是現在國際電信通話費也仍不便宜…)。
Microsoft Teams 在建立一場遠距會議時有幾種模式供要召開會議的人選擇。
如果是比較臨時發起的遠距會議，通常會比較傾向不驗證使用者帳號，而直接透過 "會議連結" 來讓 "與會者" 參與會議，也就是上述所列的 1 的形式。