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

dotnet 在 macOS 安裝後，要能完全移除其實需要一點 CLI 的知識外，也要多研讀一下 Microsoft Learn：
如何移除 .NET 執行階段和 SDK 的介紹。

或是使用 ".NET 解除安裝工具" 來進行。

但如果不介意統一用 brew 來安裝 dotnet 的時候；再加上一點點小技巧，那其實管理、使用與解除安裝時都會相對方便的。

如果不是很能接受 Homebrew (或稱 brew) 只能在 "Terminal (終端機)" 當中透過指令操作 (CLI) 的話，可以試試看 WailBrew 這套軟體。

雖然是一套滿近期才推出的軟體，但實際安裝操作後看起來開發作者是還挺用心的。

值得一用~~~

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

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

但是…

在 Nuget 的相依協助下，已經某種程度上可以是協助擺脫 dll hell 的一大工程(功臣?)

但是如果在一個解決方案當中有多個專案要引用相同的 Nuget 套件時，可能會發生各個不同的專案有各自使用不同 Nuget 套件的版本(套件相同版本不同)。

而每次要更新某個 Nuget 套件時就會要針對不同專案要處理更新，就會顯得相當繁瑣。

在 .NET 6.0 的設計中，開始可以使用中央的套件管理 Central Package Management (CPM) 的處理方式來處理這個問題。

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

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