正常情形下，不應該出現需瀏覽目錄的錯誤訊息
如遇此錯誤，檢查IIS的IP位址及網域限制設定是否跑掉。
 
  
 

 開啟TCPIP
 

重啟SQL Server
 
注意連線可能有port要記得設定
 



 

發現了一個很新奇的東西 Parallel
他可以做到平行處理迭代這件事
只要迴圈邏輯上不需要有先後順序的情況就可以使用來大幅度提高效能!


輸出值


需要特別注意如果於非同步中使用lock應使用SemaphoreSlim
如果要使用Dictionay應使用ConcurrentDictionary

由於在使用Await時，系統的Thread並不保證會與該function使用同一個Thread。
因此使用lock將單一Thread鎖住會導致出現 'Cannot await in the body of a lock statement'的錯誤

將Lock物件改成使用SemaphoreSlim，於function起始與結束加入WaitAsync與Release即可達到Lock的效果。

SemaphoreSlim完整介紹 : 用 SemaphoreSlim 來做 async/await 的鎖定
使用如下圖↓

 
 

 
在註冊Swagger時如圖中
1. 將各自action名稱代用不同編碼，避免名稱相撞導致swagger不能正確辨識。
2. 將專案XML輸出改為專案名稱($(AssemblyName))供註冊時指定反射用
↓ (對專案點擊右鍵 => 屬性 => 生成(Build) => 輸出(Output) => XML 文件名稱(XML documentation file path))
 
 

錯誤訊息：
dotnet : 因為找不到指定的命令或檔案，所以無法執行。
位於 線路:1 字元:1
+ dotnet ef dbcontext scaffold "Host=xxxxxxxxxxxxx;CommandTimeout=500 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (因為找不到指定的命令或檔案，所以無法執行。:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError
 
可能的原因包括:
  * 內建 dotnet 命令拼寫錯誤。
  * 您預計要執行 .NET 程式，但不存在 dotnet-ef。
  * 您預計要執行全域工具，但在 PATH 上找不到此名稱且開頭為 dotnet 的可執行檔。
 
解決方法：
重新安裝套件，安裝指令：dotnet tool install --global dotnet-ef


 

參考：
dotnet ef 找不到指定的命令
 

Console主控台的輸出，只要是非英文，都會是亂碼呈現



情況：
 
解決方法：
輸入：[Console]::OutputEncoding = [System.Text.Encoding]::UTF8



 
 
參考：
一次解決CONSOLE主控台輸出中文亂碼的編碼問題
【茶包射手日記】PowerShell 串接 EXE 輸出中文變亂碼

改用 NSwag 時直接 Copy 舊專案，發現找不到 AddOpenApiDocument 和 UseOpenApi 以及 UseSwaggerUi3 如下圖:

 
 

找了一些文件，要求安裝套件，都沒有用，後來發現在 Dependencies 的 Packages 直接新增 NSwag.AspNetCore 即可 





 
不要用 NuGet Package Manager 哦...

比較方式: 對相同的資料表讀取 1000 次，來比較速度。
資料庫為 MS SQL

這裡做了 4 個 Case:

Case 1: 
使用 Entity Framework，DbContext 為每次 new 一個。

Case 2:
使用 Entity Framework，使用同一個 DbContext。

Case 3:
用 DAO，轉為 Data Table 的格式 (使用 DtFromSql)。

Case 4:
使用 Dapper。

專案啟動時的記憶體使用量約為:  123 MB



測試一:
第一次讀取
Case 1, 時間: 3673.0303 ms, 記憶體: 566 MB

Case 2, 時間:  3889.9379 ms, 記憶體: 304 MB  (這個時間有時會測試到 3000 ms)

Case 3, 時間:  1665.7748 ms, 記憶體: 205 MB

Case 4, 時間:  1639.7211 ms, 記憶體: 193 MB

讀取五次
Case 1, 時間: 1984.6395, 記憶體: 544MB (有發生 GC)


Case 2, 時間:  2367.9792 ms, 記憶體: 627 MB (沒有發生 GC)


Case 3, 時間:  1395.1132 ms, 記憶體: 280 MB (有發生 GC)



Case 4, 時間:  1531.3555 ms, 記憶體: 271 MB


結果: Dapper 看來完勝，速度上和直接使用 DAO 轉進 Data Table 的速度相近。但 Dapper 傳回的結果已經轉換為物件 List， 操作上會更為方便。

Entity Framework 一如預期的較慢，且花費較多的記憶體。但和想像中最大的差異是，使用同一個 DbContext 比 new 1000 個 DbContext  的速度還要慢， 花費的記憶體在 GC 之後，差異不大。

所以不一定要用 DI 注入 DbContext, 在各 function 中一直傳遞 DbContext. 在 Static 的 function 中，可以安心的 new 一個 DbContext 出來使用吧，只是要記得用 using 哦，否則可能會有 connection 沒有關閉的問題。


 

 
於VS Web中建立虛擬目錄，導致Swagger Handler出現重複錯誤
主要原因是因為跟網站與子網站指向同一個資料夾，而父子網站的web.config有繼承關係導致。

解決方式:
1. 前往 根目錄 / .vs / 專案 / config / applicationhost.config

2. 將site中設定的子網站移除或變更虛擬目錄位置

 
3. 回到網頁重新整理就完成囉!

參考: 【茶包射手日記】怪異的web.config HttpHandler重複錯誤