在 .NET 中使用 PgVector 构建向量搜索,開發者指南
.NET 10 已於 2025 年 11 月作為長期支持版本發佈,其支持將持續至 2028 年 11 月。如果您仍在 .NET 8 或 .NET 9 上,有一個值得在日曆上記下的日期:兩者的支持將於 2026 年 11 月結束。這就是為什麼現在就開始計畫遷移的實際原因,以免在您的應用程式運行時的環境停止接收安全和質量更新。
這是我們希望在一開始就誠實以對的部分。 對於大多數團隊而言,升級本身並不是最困難的部分。
我們構建和維護從 .NET Framework 4.6.2 到 .NET 10 的文件處理程式庫,因此我們會看到許多這樣的升級。在大多數情況下,IronPDF、IronXL、IronOCR、IronWord,以及整個套件的其餘部分在您從一個支持的 .NET 版本移至下一個版本時,無需任何程式碼更改即可工作。 您更改目標框架,恢復程式包,您的PDF 仍能渲染,您的電子表格仍能處理,您的OCR 仍能運行,以及您的Word 文件仍能生成。
所以如果資訊僅僅是"升級到 .NET 10 並向我們購買支持",誠實的開發者反應將是:為什麼? 程式庫應該已經可以運行。 而這是公平的。
更有用的討論是關於相容性和優化的區別,以及即使在沒有任何問題的情況下,持續產品更新的重要性。
相容性與優化不是同一回事
當 Microsoft 發布新的 .NET 版本時,程式庫支持通常會以兩個階段到來。
第一階段是相容性。 該程式庫在新運行時上可正確運行。您的應用程式可以編譯、運行、生成文件,並按預期行事。 這是基準,而對於 Iron 套件來說,它已經到位。 Iron Software 的當前包直接針對 .NET 10 與早期運行時。
第二階段是優化。 新的 .NET 發布帶來了真正的性能和記憶體改進,而 .NET 10 尤其專注於運行時:更好的 JIT 內聯和去虛擬化,更多的堆棧分配,改進的迴圈優化,以及更廣泛的硬體指令支持。 一個程式庫可以在第一天就完全相容,但仍然在後續版本中有工程上的空間以更充分地利用這些收益。 相容性意味著它有效。 優化意味著它能更好地工作,並且這項工作在初始發布後仍在繼續。
為什麼即使在什麼都沒有壞掉的情況下,產品更新仍然重要
一個平台不會在 .NET 版本發佈的那一刻停止改變。 運行時服務更新、依賴性變更、雲平台更新、ARM64 的進展,以及容器基礎映像的變化都會不斷到來。 您的已安裝版本可能在大多數情況下依然可以正常運行。 保持最新的產品更新的價值在於,當平台在您不知情下變化時,修復已經準備好。
來自我們自己的調整日誌中的一個具體例子:最近 IronPDF 版本糾正了其對 Linux 和 Docker 依賴性自動配置,以便在 Ubuntu 24.04 上為 .NET 9 和 .NET 10 環境安裝正確的音訊程式庫 libasound2t64。 這不是你的程式碼造成的。 基礎映像和運行時組合變了,相容性更新在後來的補丁中發佈。 這就是縮微的模式:平台演變,一個持續的產品發布攜帶著調整,以便它永遠不會成為生產事件。
更改目標框架,移動到當前的包版本,恢復,然後一切完成。
如果您想確認這對您自己的工作流程適用,最簡單的路徑是直接測試。 您可以從 NuGet 中拉取最新的IronPDF或套件中任何程式庫,並使用免費的試用金鑰在 .NET 10 上運行您現有的文件程式碼,然後再承諾進行遷移。 這是將"應該可行"轉變為"確實可行"的最快方式,適用於您的特定程式碼庫。
實際上支持的作用
支持並不真的是回答"我該如何從 .NET 8 升級到 .NET 10"的問題。Microsoft 自己的遷移指導很好地涵蓋了這一點,我們更願意指引您去它,而不是假裝其他。
當某些東西在遷移後不符合預期時,支持才是有價值的。 運行時特定的異常、部署和容器差異、平台特定的不相容性、意外渲染差異以及環境特定的回歸是需要維持支持關係的案例。 在這些情況下,我們可以調查問題,提供替代方案,將真正的相容性問題升級,並在需要時在未來版本中提供修復。
遷移的實際順序
如果您計劃遷移到 .NET 10,合理的操作順序是:
- 早測試,使用真實的構建而不是樣品專案。
- 驗證每個文件工作流程,而不僅僅是常見流程。
- 查看您的部署目標:Docker、Linux、Azure 和 ARM64。
- 在進行中保持最新的程式庫釋放,而不是批量它們。
- 如果對您的業務來說,向前相容運行時是重要的,則保持積極的產品更新。
結束
.NET 的大多數遷移都是平穩無事的,這就是重點。 保持最新的價值並不是說您的應用程式會在 .NET 10 到來的瞬間中斷。 而是說,隨著平台的不斷演變,您擁有相容性更新、修復和持續的工程工作,讓您的文件處理堆棧平穩運行,而不會成為您需要解決的問題。
