鳥毅的Blog

今天幫同事把 他用到的最短路徑套件修復多執行緒問題，原本是 .net 4.0，我改成 .net 10，讓AI修復整個套件。  原本的 YanQi 演算法是用 Java 版改過來，.Net版 裡有 bug，所以後來我再去抓原始的 Java 程式，結果 Java 程式裡又是用別人的 Jar， 所以再去找原始 YanQi Jar 的原始碼來修。現在 AI 很強，直接找出他改錯的地方，再用其他方式修正原本 Dictionary 不是 Thread Safe 的問題。 原本的演算法及語法都修復，並且從 nUnit 改為 xUnit。 至於到底修了多少，請自行去看 git log。 https://github.com/tenyi/adapters-shortest-paths-dotnet

  由於被同事質疑在某專案中引用的 Library 太多未使用到的方法，決定自行開發一個減肥程式。

最近有個新專案，由於資料表的欄位很多，還要Call Stored Procedure，所以請DBA將資料表做成User-Defined Table Type，沒想到我呼叫Stored Procedure更新時發生一個錯誤：    將 nvarchar 資料類型轉換成 datetime 資料類型時，產生超出範圍的值。 資料表值參數 "@MyUDT" 的資料不符合參數的資料表類型。SQL Server 錯誤為: 242，狀態: 3 陳述式已經結束。   使用User-Defined Table Type(以下簡稱UDT)做為參數非常簡單大概就是 SqlParameter parameter = new SqlParameter("@MyUDT", SqlDbType.Structured); parameter.Value = dataTable; 乍看之下會以為是資料內容錯誤，但這次我的內容人工出對後完全沒錯，欄位名稱也對。經過一天一夜的試誤，終於發現問題出在： 欄位順序 ! 以前我自己寫ADO.Net呼叫時，都會利用資料表先做出一個XML Schema(xsd)，利用DataTable.ReadXmlSchema 產生結構，這樣Data Table裡的欄位順序絕對不會錯；而這次首度使用 List to DataTable 的公用程式自動產生DataTable，不用另外去產生XSD，整個程式變很順，不需要一個一個欄位塞值。 以上提供也使用UDT 做為SqlParameter的朋友參考。 後記：最近在測試時又發生過一次錯誤，是UDT屬性裡某個Not Null的欄位在DataTable裡缺值為null，也會造成呼叫UDT時錯誤。

在用SonarQbue 做原始碼掃描時，某一個專案出現 "The main branch of this project is empty."。 原本還在懷疑是不是檔案編碼造成，全部改成有BOM的UTF-8後還是不行；最後用另一個成功專案的csproj改名字後，就可以正常掃描。 所以只好一個一個選項去比對修改再用Sonar-Scanner去掃，最後發現和選項無關，是 Microsoft.NET.Test.Sdk 這個package造成，猜想應該是在Nuget套件管理主控台更新套件時，不小心把測試元件加到主專案，先把這個package從 csproj移掉就解決。

最近編某一個專案，用OpenApi一直出現「Microsoft.OpenApi 1.2.3 不支援任何目標架構」，這樣奇怪的錯誤。猜想是某個設定檔錯誤，於是產生新專案來測試： 我用的是2021/5最新的dotnet 5.0.203，到另一臺電腦測試完全沒問題。所以想應該是元件註刪之類的問題，結果我錯了，在偉大的 StackOverFlow找到答案 ，清除NuGet快取：   nuget locals all --clear 清空快取後，就恢復正常，可以回來工作，繼續爆肝。