James's Tech & Life Blog

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

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

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

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…等。

Windows 上如果設定了時區(無論手動或自動)，透過 TimeZoneInfo 取出的時區識別碼，都是根據所設定的地區的時區，並且回應成 Windows 使用的 TimeZone 格式識別碼。

例如設定為 (UTC +08:00) 台北取出來的識別碼的值會為："Taipei Standard Time" 的字串資料。

但是…

這篇有提到：

在 macOS 上最主要就是要安裝 Xcode，而如果要安裝 Xcode 的管道，基本上有兩種：

1. 透過 macOS 上的 App Store 安裝。(登入 Apple 帳號後即能免費下載使用)
2. 透過 Apple Developers 網站來下載 .xip 安裝。(需要先有訂閱 Apple 開發者帳號才能下載使用)

本篇就來談談如何透過 .xip 來安裝 Xcode。

如果要順利在 Visual Studio 來連接 macOS 透由 .NET MAUI 開發 iOS 的話，對於要連接的 macOS 上是需要事先安裝好 Xcode 等 Apple 所設計的 iOS 開發工具的。

不然，就算有開啟遠端登入等功能讓 Visual Studio 能夠連線並自動安裝 mono 等軟體元件，那也沒有 iOS 的相關 SDK 供使用。

在 macOS 上最主要就是要安裝 Xcode，而如果要安裝 Xcode 的管道，基本上有兩種：

1. 透過 macOS 上的 App Store 安裝。(登入 Apple 帳號後即能免費下載使用)
2. 透過 Apple Developer 網站來下載 .xip 安裝。(需要先有訂閱 Apple 開發者帳號才能下載使用)

本篇介紹是使用第一種方式來完成唷~~~

在 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 進行開發上的處理，應該會是最輕鬆的方式。

而由於 .NET MAUI 是一套建置跨平台應用的開發技術，所以如果要在 上回 所建構出的 .NET MAUI 專案，直接切換建置 Android 出應用程式並不是什麼難事：

使用 .NET MAUI 開發 Windows 應用不是什麼難事：

看看如何透過 Visual Studio 的安裝來設定相關的開發環境囉~~

這不是一個什麼 .NET 的新特點了…只是一個犯蠢的紀錄。

只是近期常常發生這種犯蠢的事情，所以來我獨自筆記一下。

如果需要在 UI 上需要呈現統計圖表的話，LiveCharts2 是一套很不錯的統計圖表的套件，除了完全 OpenSource 外也如官網所提到的，對於 .NET 相關跨平台 UI Framework 都有支援。

https://livecharts.dev/#frameworks

如果考慮 UI 呈現的感覺與效果，個人覺得 LiveCharts2 實在稱的上是 .NET 跨平台開發者在統計圖表上的不二選擇！

.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 的版本來使用。

為了配合整體教育訓練的課程規劃，雖說 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。

LINQPad 是一套對於 .NET 開發者(多為使用 C#)不可多得的輕量化好工具。

雖然後來已經有 Visual Studio Code 了，但很多時候還是很直覺的會想到 LINQPad，而且在 Nuget 套件也可直接安裝使用的狀況底下，LINQPad 還是比較便利使用(截至 2021 年 11 月的消息，LINQPad 目前還是只有 Windows 版本)。