Dorlon Notes

除Worker以外還有另一種Windows Service 的開發方式 透過Console Application(主控台應用程式)搭配Topshelf套件即可建置Windows Service 使用傳統開發 Windows Service 方式時，必定會面臨到如何在開發時期進行偵錯的問題 當然利用一些小技巧是可以達成 (ex. 參考 如何對 Windows Service 進行除錯 文章) 但到底還是要手動切換。 透過 Topshelf 這個套件可以讓開發者直接使用 Console 方式進行開發 編譯出來就是一隻 console 程式且可以獨自運行 又可以透過命令列指令將這個 console 執行檔安裝成為 Windows Service 服務 達到易於開發、偵錯及靈活使用的優點。 (若要佈署在Linux環境另有Topshelf.linux套件可使用) 1.建立Console Application(主控台應用程式) 專案 2.透過NuGet安裝Topshelf 套件 3.建立一個新類別 MainService，內容只有簡單印出目前系統時間(每秒執行一次) 4.於Program.cs中使用HostFactory掛載 MainService執行主要工作 5.可直接偵錯/運行，執行畫面如下 6.發佈後進行Windows Service安裝 於命令提示字元輸入 「執行檔名稱 install」，後面還可帶一些參數 例： ConsoleApp1.exe help  (可查詢相關參數使用方式) ConsoleApp1.exe install (安裝Windows Service) ConsoleApp1.exe uninstall (移除 Windows Service)

Worker Service基本的範例功能太過陽春，可搭配Coravel 套件強化工作排程的設定 Coravel提供非常豐富的排程時間設定，以下介紹基本的使用方式 1.安裝 Coravel 套件 2.Program.cs加入引用 Coravel 3.加入排程項目Worker2、Worker4 4.設定排程執行時間 基本排程時間設定說明： Method Description EverySecond() 每秒執行 EveryFiveSeconds() 每5秒執行 EveryTenSeconds() 每10秒執行 EveryFifteenSeconds() 每1 5 秒執行 EveryThirtySeconds() 每30秒執行 EverySeconds(3) 每 n 秒執行 EveryMinute() 每1分鐘執行 EveryFiveMinutes() 每5分鐘執行 EveryTenMinutes() 每10分鐘執行 EveryFifteenMinutes() 每15分鐘執行 EveryThirtyMinutes() 每3 0 分鐘執行 Hourly() 每小時執行 HourlyAt(12) 每小時12分執行 Daily() 每1天執行 DailyAtHour(13) 每一天下午1:00執行 DailyAt(13, 30) 每一天下午1:30執行 Weekly() 每週執行 多條件式時間設定： 1.每週一、三、五半夜1點執行 scheduler.Schedule<TodoJob>()     .DailyAtHour(1)     .Monday()     .Wednesday()     .Friday(); 2.週未每5分鐘執行 scheduler.Schedule<ReportJob>() ...

一般來說 Worker Service 會被用來執行需要長時間處理或定期需要做的事情 .NET Core 3.0 提供了 Worker Service，用來建立系統服務的基本專案。 目前資源太少，網路上大都只提供最簡單的範例，還沒有找到可以靈活操作各個排程的方法。 在.Net Core的環境下不論是Worker Service或Console Application都是基本的應用程式，一樣都是透過套件就能轉換為Windows服務。 以下先介紹Worker Service基本的範例及Windows Service建置 [建立Worker Service專案] 建立好的專案一開始就附有基本的範例 (每秒執行並印出時間) [轉換為 Windows Service] 1..加入 Microsoft.Extensions.Hosting.WindowsServices 套件 2.於Program.cs 的CreateHostBuilder加入 UseWindowsService 2.完成的Worker Service需手動安裝至Windows 服務 於命令提示字元輸入指令 安裝：sc create WindowsServiceName binPath=執行檔位置 啟動：sc start WindowsServiceName 停止：sc stop WindowsServiceName 移除：sc delete WindowsServiceName [轉換為 Linux Daemon Service] 1. 於專案新增 Microsoft.Extensions.Hosting.Systemd 套件 2.在 Program 類別 CreateHostBuilder 處加上 UseSystemd()

專案的API可能包含所有客戶的API接口 如果我們不想在API文件中提供所有API接口內容 可以 增加過濾器移除不想被看到的API接口 被隱藏的API接口在Swagger文件中看不到，但還是可以被使用的。 在Startup.cs 啟動中修改，增加文件過濾器 以下新增名稱為 AllowAPIDocumentFilter 來過濾未在允用清單中的API接口 自己建一個APISetting.json 允用清單(字串陣列)

1.專案中有些不想公開的口，可設定隱藏 (IgnoreApi = true) 2.輸出的Response可指定特定資料格式 3.利用註解標籤定義API的名稱、傳入參數、各參數的說明。

透過簡單的Swagger套件安裝即可產生Swagger頁面 1.將現有專案加入Swagger套件 2.在啟動檔Startup.cs加入Swagger設定，設定中指定XML檔名 3.為了讓Swagger取得相關註解標籤，專案需設定產出XML檔

目前.NET已有內建Help Page 能呈現足夠豐富的API文件內容 另一個產生自動API文件的服務 [Swagger] 1.介面比較漂亮 2.功能更強大 3.可直接線上執行API 並取得回傳結果 [API測試工具] 不需透過其它軟體或工具，直接可以在Swagger頁面帶入相關參數，執行並傳回結果。

System.Text.Json 特色 強調效能 主要是啟用了 .NET Core 的祕密武器 - Span   低記憶體耗用量 效能比較 System.Text.Json 吞吐量(PRS)明顯都高於JSON.NET (Newtonsoft.Json)   撰寫方式的差異 JSON.NET (JObject) dynamic md = JsonConvert.DeserializeObject (strJSON); if (md != null) query.VipNo = md["VipNo"] == null ? "" : md["VipNo"].ToString(); System.Text.Json (JsonElement) dynamic md = JsonSerializer.Deserialize (strJSON,); if (md.ValueKind != null) { JsonElement TMP = new JsonElement(); if (Source.TryGetProperty(Name, out TMP)) query.VipNo = TMP.GetString(); }   撰寫方式的差異 JSON.NET (JObject) dynamic md = JsonConvert.DeserializeObject (strJSON); if (md != null) query.VipNo = md["VipNo"] == null ? "" : md["VipNo"].ToString(); System.Text.Json (JsonElement) // 自定義轉換器   var options = new JsonSerializerOptions { AllowTrailingCommas = true }; dynamic md = JsonSerializer.Deserialize (strJSON, options ); if (md.ValueKind != null) { JsonEle...

Razor Page  Razor Page是一個輕量化的框架，較 接近MVVM架構 。 它延續 WebForm 的簡約精神，是開發網頁的另一種選擇 WebForm 以單一網頁為核心的精神並非一無可取 對一些超小型應用而言，硬要拆分 Model、View、Controller 反而讓事情複雜化。 WebForm 的組成單純，靠一個 .aspx 放 HTML/CSS/JavaScript、一個 .aspx.cs 寫按鈕的 Server 端事件 兩個檔案搞定網頁完整流程 有些功能Razor Page實現不了，MVC更為靈活，但也更複雜 Razor Page的優勢就是它的簡單， Brazor - ASP.Net Core的新前端框架 Brazor為 Angular/React/Vue 的可能替代方式 讓.NET 的開發者使用原本熟悉的 C# + Razor 與 HTML Blazor是一種框架，可以讓我們 使用C#或.NET建構Web UI ，而不需要使用JavaScript開發前端的Web UI 使用 C# 而不是 JavaScript 來建立豐富的互動式 UI Mobile Brazor  以開發網頁的方式來開發APP，目前屬於 實驗性質 。 開發者可以使用網頁程式開發模式， 使用C#和.NET，建置iOS和Android原生行動應用程式 以Razor語法定義UI元件以及應用程式行為 UI元件是利用Xamarin.Forms原生UI控制元件作為基礎，因此可開發出精美的原生行動應用程式 TEST

跨平台類別庫 .NET Standard .NET Standard 的核心使命在於解決 .NET 跨平台時 基礎程式庫不一致的問題 此標準寫出來的程式庫可以在 .NET Framework、.NET Core、Mono、UWP、Xamarin.iOS、Xamarin.Android 等不同平台使用 各版本的對應 從 .NET Standard 2.1 開始，NET Framework 4.8 不再表列之中 不同版本的.NET Standard對應不同版本的平台

.NET Core 現況 Core 1.0、Core 2.0均聚焦於跨平台與 Server-Side(ASP.NET)的支援 Core 3.x 開始轉移開發焦點至 Desktop部分，可以取代 NET Framework來進行 Windows GUI的開發， GUI 的部分依舊是維持在 Windows平台上，不具備跨平台的能力 。 目前看起來移轉到 .NET Core 上好處不多，.NET Framework 再戰十年也沒問題 畢竟 Microsoft 已經將重心移轉到 .NET Core 上 ，是時候該認真考慮改用 .NET Core 寫新專案，並評估將現有專案移植到 .NET Core。 .NET 5 - 下一代的 .Net Core 統一.NET的命名，目標就是只有一個.NET 利用.NET Core和Mono，建立了一個單一平臺 使開發者可以在任何地方，執行所有現代的.NET程式碼，統一執行行為和開發者的體驗。 .Net Core 特色 開源且免費 取得了更快速的發展 目前有來自超過3,700家企業的1.9萬開發者在為.Net Core做貢獻 達到真的跨平台 (Windows、Linux、macOS) 讓您能夠在多個平台上做開發，在Windows、Linux、Mac上執行 更可部署到Docker上執行 輕量化(快速啟動、佔用空間小、記憶體使用率低) 基本上.Net Core是一個更加模組化的平台，換句話說整體的速度和使用的資源更少。 發佈模式的不同 效能優勢 傳統的ASP.NET 受限於 IIS，功能豐富但較笨重， 在一些評測中 ASP.NET Core搭配Kestrel Web Server 的效能至少嬴過 ASP.NET on IIS 3-4 倍。 ASP.NET Core 內建就有 Kestrel 這個輕量化的網頁伺服器，不需要再依賴 IIS 也可透過IIS、Nginx 或 Apache 等網頁伺服器運行 .Net Core 、.Net Framework 該如何選擇?  NET Core偏向以微服務跨平台的程式開發 NET Framework則以Windows為主的架構 .NET Framewo...