James's Tech & Life Blog

GetCreationTimeUtc / GetCreationTime 其實都會有同樣的問題。

更正確地說 .NET 對檔案的 CreationTime 在 Windows 與 Unix-like (macOS、Linux…等，後面都統一稱呼 Linux) 的 OS 上定義不同。

目前手上常用來建置與發佈程式的 CI/CD 服務與架構系統，大略可簡化為 "GitLab 的雲端服務 + 地端主機上所運作的 Docker"。

要完全地端也當然不是不行，畢竟可以自行架設 gitlab 的 Server 在地端的環境內運作。

目前手上常用來建置與發佈程式的 CI/CD 服務與架構系統，大略可簡化為 "GitLab 的雲端服務 + 地端主機上所運作的 Docker"。

要完全地端也當然不是不行，畢竟可以自行架設 gitlab 的 Server 在地端的環境內運作。

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

HW/FW ←→ CLI ←→ GUI

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

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

也就是 .NET 一直強調的： 

Write once, run multi-platform.

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

隨著作業系統的升級或發展過程，在當前安全威脅日益高張的年代，當然作業系統的相關安全性與設計也會隨之強化。

硬體的驅動程式是會跟作業系統 (OS) 直接作動的，所以從安全性的角度來看，隨著時間的推進而造成一些外部裝置的驅動程式過於老舊，沒有跟著新版作業系統的安全性設計而改版，產生與新版作業系統發生不相容問題，也不難理解。

但是就這樣把問題都推給微軟，說通通都是 Windows 11 的錯，這就很難令人理解了🤔

反觀果粉就不會有這種心態…很妙😏

在 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 自動化流程奠定一定程度的基礎。

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

• Socket
• Pipe

以下列出對照：

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

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

如果需要在 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 當中。

發文的今天，微軟也正好發布 Visual Studio 2022 v17.3 的正式版🙈。

所以…

要使用 .NET MAUI 的話，必須安裝 Visual Studio 2022 Preview 的版本來使用。

如果按照標題的概念來看，其實網卡的 DNS 設定錯誤，仍然是可以上網的…

But…

所有的連線都要轉成 ip 位址的方式。

But… 

不會有人去記住要使用的網站 ip 吧! 

好，就算記住了，Android 系統的相關連線服務也還是靠 DNS 才能正確連線使用阿…所以還是來知道一下怎麼處理吧!

由於近期線上工作、會議、課程的需求激增，要讓公司/組織/團體在 Teams 當中加入外部的來賓帳號(就是大眾常用的免費 email 服務帳號，如: gmail、outlook/hotmail、yahoo...等)，來一起加入協同工作、會議或課程，該怎麼辦呢?

而如果使用時其實是可以透過各款主流的網頁瀏覽器，登入 "微軟帳號" 後進入到受到邀請的團隊，就可以直接使用 Teams 服務了。

如果要直接在瀏覽器使用 "微軟 Teams 服務"，可透過下面連結:
https://www.microsoft.com/zh-tw/microsoft-teams/log-in

or

https://teams.microsoft.com/

Skype 這個服務在網路開始能利用語音通訊後，就在剛進入 Y2K 年代左右時奇蹟般地出現在大眾的眼前，別忘了在網路頻寬還不夠大、網路速度還不夠快、通話載具也不是這麼便利的時代，要雙方都直接用網路進行語音通訊，根本還沒辦法很簡便的進入到平常大眾的使用範疇中。

但 Skype 的服務在當時，並不冀求雙方都是利用網路進行語音通話，而是從 Skype 端撥打語音通話到電話當中，甚至是能透過電話回撥到 Skype 端的部分。

而透過收取比一般撥電話還便宜的費用，來做為 Skype 服務的營利基礎。

在那個年代要進行一通跨國通話，基本上雙邊都由各國的電信業者把持，所費不貲(就算是現在國際電信通話費也仍不便宜…)。

Microsoft Teams 在建立一場遠距會議時有幾種模式供要召開會議的人選擇。

1. 不驗證帳號透過連結參與。

2. 需驗證組織成員帳號參與。

3. 使用註冊表單填寫後參與。

如果是比較臨時發起的遠距會議，通常會比較傾向不驗證使用者帳號，而直接透過 "會議連結" 來讓 "與會者" 參與會議，也就是上述所列的 1 的形式。

為了配合整體教育訓練的課程規劃，雖說 Web API 不是自己最專業領域，但仍是需帶點撰寫 Web API 的教學，才能讓學員們對 App 如何去介接後端資料有所了解，因此就開啟了一段 ASP.NET Core 6.0 的 Minimal Web API 教學。

畢竟 ASP.NET Core 6.0 的 Minimal Web API 使用了極簡的 Code，很適合給初心者在認識之初，不用了解太多特殊的設定就能快速上手，打造出一套含有 CRUD 功能的 Web API。

但若要完整透徹的了解 ASP.NET Core 6.0+ 所設計的 Minimal Web API 的整體概念(可參考文末的參考文件)，仍是需要花上很多心力去摸索其基礎觀念與設計的，請務必釐清。 

在教學時也希望能夠帶給初心者的學員有正確開發觀念，所以過程中除了撰寫 Web API 外，也同時讓學員去撰寫 Integration Test 來測試自己產出的 Web API，在這邊則是選擇使用了 xUnit 來做為 Web API 的 Integration Test 所使用的 Framework。

恩…什麼是 WebRTC 在本篇就不多做討論了，請到下列官方網站了解:
https://webrtc.org/

而在測試 Client 端使用 Web-RTC 之間連線的時候，要先自己弄一個 WebRTC 的 Server-side 服務，在目前看起來好像有點彆扭😑

所以神通廣大的 GitHub 上，總是會有厲害的網民們寫了一些放上來的 Repo 就能滿足麻瓜的使用，例如這個 node-dss 就能讓麻瓜們能夠比較簡易上手些。

而這篇就是 node-dss 的測試使用，開始囉!