答客問:ASP.NET Core Web API簡單型別無法正常取值問題背後的問題
教學上,我一直認為沒有爛問題。只有懂與不懂。實務問題都是好問題。
原始問題是,他想要對一個簡單型別進行取值的動作,我們快速打造出第一版原型ASP.NET Core Web API程式碼:
教學上,我一直認為沒有爛問題。只有懂與不懂。實務問題都是好問題。
原始問題是,他想要對一個簡單型別進行取值的動作,我們快速打造出第一版原型ASP.NET Core Web API程式碼:
近期,我們有意將 Windows Container 升級至最新半年通道 Windows Server 2004,從 1709、1803、1809、1903、1909 一路被虐過來,總覺得會越走越輕鬆,結果沒有。前面,在解決了 VMTools 造成容器服務會被中斷的問題之後。馬上又碰到第二個問題。
話說,工作電腦突然得到好人哭哭卡一張。重開機後用 BlueScreenView 去看了一下,原因是:SYSTEM_SERVICE_EXCEPTION,嗯,好吧,這好像不是我能處理的。
重開機之後,想說繼續之前被中斷的工作,其中一項是更新 Visual Studio 2019,結果:
公司新筆電,怎麼用不到半年整個 C: 就快滿了。當初 C: 給了約 220GB,雖然安裝一些開發工具會佔一些空間,但也不應該會把 C: 吃到快滿的狀態。
在某個時間點之後,我們的 Docker for Windows 服務測試區進入了非常不穩定期。一開始不容易發現的原因是,預設執行中的容器(Container)有下 --restart=always
而且又是在測試區,也就是說,當你部署新的容器服務時,會有10-15鐘很正常,然後中間會有個有個瞬斷。容器被中止後,因為 --restart=always
參數的關係, Docker 服務會用最快的時間重啟一個容器還給你用。所以總會覺得怎麼最近寫的容器應用程式怎麼過一段時間就卡卡的。在某次下 docker ps
時看到才發現到這些容器的啟動時間怪怪的。
教學上,我一直認為沒有爛問題。只有懂與不懂。
平常我們在課程上設計的範例為求簡單好懂,通常都會盡量簡化。但回去之後的實務問題,在我眼裡都非常有價值。API 的開發可以很簡單,也可以很複雜,例如,只是單純從後端資料庫取資料,資料表與Model的對應關係通常都是一對一(1:1)的,輸出入也很單純只會有一層,除非你導入了如 Entity Framework 之類 ORM,產生了一對多(1:n)或多對多(n:n)的情境。
{
"filter":{
"name":"bruce",
"currentPage":1,
"pageSize":5
}
}
以同學提問的情況,感覺比較像 Front-End First(或稱 JSON First),也就是 JSON 規格是由前端定義。我們一步一步來解決。
近來,我們的 Docker Build 主機上經常過一段時間就會出現以下的錯誤造成 docker build
失敗。
口罩API系列(一)(二)(三)就資料面而言,已經處理的差不多了,不過,專案還有改善的空間。
以關注點分離來看,目前的 MaskController
工作有點雜且職責不夠單一。第一個問題,如果從 EF Core 下手,可能是實作 SeedData 方式來解決,但比較麻煩的事情是資料來源是網路上,而且資料內容不固定。第二點比較麻煩。正在構思時,剛好好友 Demo 貼文說 dotblogs 改版採用 Hangfire 來處理排程事件。疑,Hangfire 不就是這個需求的最佳解嗎!
「使用Hangfire處理ASP.NET MVC/Web API長時間與排程工作」多年前已經用的非常開心。這次讓我們在 ASP.NET Core Web API 來整合 Hangfire 來解決我們碰到的問題。
前篇提過,因為某些 Module (模組)的關係而無法升級使用 PowerShell Core,這問題在 PowerShell Core 7 提供了一個 -UseWindowsPowerShell
的相容模式可以解決。但說歸說,沒有親手驗證的東西要放到正式區執行總有些不安。剛好手頭有個 SFTP 的案子,就簡單寫一支 PowerShell Core 7 + posh-ssh 腳本實際測試一下:
先點唱一首:調調調(誤)追追追。
在調整完 PowerShell Core 7 的樣式之後,又對 Windows Terminal 發出黃牌。用起總是卡手,但內心有個聲音:我不想回去!還好,Windows Terminal 保留了相容彈性的組態空間,讓我們客制自己想要 Windows Terminal。
在升級 PowerShell Core 7 之後,還是發現一些問題。安裝 PowerShell Core 7 後的原始指令視窗輸入指令還是有跳動問題,還有字型支援度不佳等等。在改用 Windows Terminal 之後雖然改善一些,但是不滿意。有了之前改造 WSL 指令列的經驗,這次我們來改 PowerShell 指令列。
前篇說明加入 PowerShell Core 6 的原因。而 PowerShell Core 7 在 2020/3/5 GA 了。如果你已經安裝 PowerShell Core 6 的話,那一定要快點升級為 PowerShell Core 7,可以取得大量的好處。
前篇,我們展示使用 ASP.NET Core Web API 來快速提供口罩剩餘數量查詢API,但這個展示專案有二個較大缺點,我們持續來改進它。
我們會先處理第二點,這裡我選擇利用 EF Core 整 SQLite 來當暫存資料的儲存點,因為原始資料約 6000 筆上下,這樣的處理量 SQLite 非常合適,而且它的特色是帶著就走且免費,發行部署也相當方便。在未超過更新間隔時前,就由 SQLite 裡去取資料,以減輕資料源的壓力。在處理第二點時,會隨便處理第一點,在取回政府資料開放平臺的口罩剩餘數量資料並儲存前,我們利用 Model 裡的一點小技巧來轉換資料源到英文欄位,並以英文欄位來輸出。
以下利用一個ASP.NET Core Web API範例來說明如何在ASP.NET Core撰寫一支去串接政府資料開放平臺的口罩剩餘數量,並提供為API讓人家使用。
資料來源:健保特約機構口罩剩餘數量明細清單
在進行一個 Visual Studio Core + Entity Framework Core 測試程式時,在新增套件時,不斷跑出「無法載入來源」的錯誤,然後停止安裝。
dotnet add package Microsoft.EntityFrameworkCore.Sqlite
Writing C:\Users\BruceChen\AppData\Local\Temp\tmp1C89.tmp
info : 正在將套件 'Microsoft.EntityFrameworkCore.Sqlite' 的 PackageReference 新增至專案 'D:\Temp\EFCoreFirst\EFCoreFirst.csproj'。
info : 正在還原 D:\Temp\EFCoreFirst\EFCoreFirst.csproj 的封裝...
info : GET https://api.nuget.org/v3-flatcontainer/microsoft.entityframeworkcore.sqlite/index.json
error: 無法載入來源 https://xxxxxxxxxx.pkgs.visualstudio.com/_packaging/BestFeed/nuget/v3/index.json 的服務索引。
error: Response status code does not indicate success: 401 (Unauthorized).
在測試一段非同步程碼時,發現一個 ASP.NET Core 裡 Route 有趣現象。平常為了測試方便,習慣會修改預設路由規則,例如將
ASP.NET Core Web API Route("api/[controller]")
改為 Route("ControllerName/[action]")
。
我們先在本機進行 Redis for Windows 的 Master-Slave-Sentinel 架構測試。由於微軟官方已經不再繼續維護 Redis for Windows,目前還有一位 tporadowski fork 後持繼在更新與維護。讓我們謝謝他。
因工作所需,且沒有測試區可以玩,就自己註冊了一個 AWS 免費帳戶,需要有 Email、手機、信用卡三項。基本上都是填完資料後按「下一步」,不過,最後驗證手機門號時,我只有按「撥打電話」才成功,其他 SMS 之類的我都沒有成功。
在 安裝 PowerShell - Active Directory Module 解決 AD 大小事 裡有介紹 Windows 10 如何安裝 RSAT 工具,以取得 Windows 10 的 PowerShell - Active Directory Module 的功能,不過,按照原始連結你會發現,只取能得 Windows 10 1709、1803 版本安裝檔,在新的筆電 Windows 10 v1903 上,下載的安裝檔都無法使用,找了一會兒在「安裝需知」才看到:
Starting with Windows 10 October 2018 Update, RSAT is included as a set of "Features on Demand" right from Windows 10. Do not download an RSAT package from this page. Instead, just go to "Manage optional features" in Settings and click "Add a feature" to see the list of available RSAT tools. Select and install the specific RSAT tools you need. To see installation progress, click the Back button to view status on the "Manage optional features" page
原來 RSAT 工具在 Windows 10 1809 之後的安裝有所改變。文件可參考:Available Features on Demand。
在某些時間,在進行 Docker 與 Container 偵錯時,真的已經查到完全沒有頭緒時,總會把問題定位「是否是 Docker 本身的蟲呢?」在導入 Docker 之後,真的碰過幾次 Docker 本身的問題,都是查了很久才在 Github Issue 上查詢到一些線索,最久等超過一年以上才放出修正。當我們想知道 Docker 本身狀態時,你會發現,就 Docker CLI 都是偏 Container 的操作,docker logs
、docker events
…好像沒有可以取得 Docker 本身偵錯資訊的 CLI。
如果要取得 Docker 本身的偵錯訊息,有兩種方式,一是使用指令進行 Debug Mode,一是使用 daemon.json 組態指定 Debug Mode。
在使用 multi-stage builds 進行建置 .NET / .NET Core 應用程式時發現一個有趣的事,在 docker build
內進行 nuget.org 還原時可正常還原套件。但如果是使用到 Private Nuget Service 時,例如,我們採用的是 Azure Artifacts - NuGet 服務,就會取得一堆紅色的錯誤訊息:
Errors in packages.config projects
Unable to find version '2018.8.2.3' of package 'KingXXXX.YYYYYYYYYYor'.
https://api.nuget.org/v3/index.json: Package 'KingXXXX.YYYYYYYYYYor.2018.8.2.3' is not found on source 'https://api.nuget.org/v3/index.json'.
Unable to find version '2017.10.17.1' of package 'KingXXXX.YYYYYYYYYYYYYYFramework'.
https://api.nuget.org/v3/index.json: Package 'KingXXXX.YYYYYYYYYYYYYYFramework.2017.10.17.1' is not found on source 'https://api.nuget.org/v3/index.json'.
Unable to find version '2018.7.24.2' of package 'KingXXXX.PPPPService'.
https://api.nuget.org/v3/index.json: Package 'KingXXXX.PPPPService.2018.7.24.2' is not found on source 'https://api.nuget.org/v3/index.json'.
NuGet Config files used:
C:\Users\ContainerAdministrator\AppData\Roaming\NuGet\NuGet.Config
Feeds used:
https://api.nuget.org/v3/index.json
在受管制的網路環境,需要在 Windows 容器內去安裝 MSBuild 工具,MSBuild 工具大約區分二個版本,Build Tools 2015 與 Build Tools for Visual Studio (2017, 2019)。
公司新開發機筆電明顯卡頓,而且時常出現螢幕閃黑數十秒後還原。原先不太在意,但頻率明顯增加的趨勢。一段時間過後發現,此現象在啟動 Docker for Windows 之後非常明顯。在啟動 Windows Container 失敗的錯誤訊息:The paging file is too small
引發我的好奇。
首先,這台開發機有 24 GB RAM,啟動 Docker for Windows 後整體使用率約 7 成(Windows Container 因為有機會開 SQL Server 容器,所以習慣設定 4096 MB),也就是使用約 16 - 17 GB 左右,剩下也還有接近 7 GB 的記憶體空間。我知道 Paging 是指分頁檔,但通常分頁檔應該是實體憶體體不足才會產生與使用。怎麼會說不夠呢?
看過就好,請不要跟著做。
在處理一個 Docker 問題時,發現 Windows 系統日誌裡有非常大量的 disk 警告:
PS C:\> Get-EventLog -LogName System -EntryType Warning -Source disk -Newest 10 | fl
Index : 636983
EntryType : Warning
InstanceId : 2147745950
Message : Disk 19 has the same disk identifiers as one or more disks connected to the system. Go to Microsoft's support website (http://support.microsoft.com) and search for KB2983588 to resolve the issue.
Category : (0)
CategoryNumber : 0
ReplacementStrings : {\Device\Harddisk19\DR368, 19}
Source : disk
TimeGenerated : 11/29/2019 3:15:49 PM
TimeWritten : 11/29/2019 3:15:49 PM
UserName :
訊息說明,有大量的 disk 有著相同的 identifiers,請參考 KB2983588 來決解問題。
當我們採用含 IIS 功能的 Windows Container 後(例如,Windows IIS、ASP.NET等),有時需要查詢或操作 IIS,未經組態的 IIS 容器並無法直接使用如 IIS 管理員等 GUI 工具來連線管理。還是可以透過內建 iisreset.exe 與 appcmd.exe 來進行查詢與管理。
某一批新 VM 主機在安裝了 Microsoft Monitoring Agent(MMA)之後,出現奇怪的現像,在 Log Analytics 裡,除了 Perf (效能計數器) 項目,其他查詢都很正常。本來方向一直在 MMA 打轉,查了許久,終於找出原因:
Get-Counter -ListSet * | Sort-Object -Property CounterSetName | Format-Table -AutoSize
Get-Counter -ListSet * | Where-Object -FilterScript {$_.CounterSetName -eq "Process" -or $_.CounterSetName -eq "Memory" -or $_.CounterSetName -eq "LogicalDisk"}
在公司 Windows 10 開發機上,當 Docker 採用 Process Isolation 執行時,畫面停止不動,無法繼續往下執行。
在公司 Windows 10 開發機上進行 Windows Container for GPU 測試時,在進行 docker build
DirectX 範例時,不斷出現 timeout 的錯誤。連指定容器 DNS 都用上了,還是不行。
偵錯了好久才想到,公司網路環境特別,內部設備上網需包含一張特別的憑證。原本開發機已包含此憑證,上網正常,本以為容器只是透過本機 NAT 出去,應該只是借道而行,結果是不得其門而入。