385 字
2 分鐘
瀏覽次數
NuGet 套件發布與本地測試實戰:從推送到驗證一次搞懂
2025-07-25
2026-04-10

結論#

  • 發佈後直接用「專案參考」測試,比重新下載套件更快、更可控。

適合用在哪裡#

  • 自建 NuGet 私服 / 公司內部套件
  • 開發共用工具(Logging / Utils / SDK)
  • 發佈後想快速驗證功能是否正常
  • 避免反覆 push / install 浪費時間

流程步驟#

1. 推送 NuGet 套件#

  • 將打包好的 .nupkg 上傳到 NuGet Server
  • 確認 API Key 與 Server URL 正確
Terminal window
# 推送套件
dotnet nuget push -s <https://xxx.yyy.zzz/v3/index.json> -k KEYXXX1234 AppLogger.1.0.0.nupkg
  • 為什麼:
    • 讓其他專案可透過 NuGet 安裝
    • 作為正式版本發佈來源

2. 使用「專案參考」進行測試#

  • 不直接安裝 NuGet 套件

  • 改用本地專案測試 操作:

  • 方案右鍵 → 加入現有專案(套件專案)

  • 專案 → 相依性 → 新增專案參考

  • 選擇你的套件專案

  • 為什麼:

    • 修改後立即生效(不用重包)
    • Debug 更方便(可直接追進套件)

3. 驗證功能是否正常#

  • 執行主專案
  • 確認:
    • API / Method 是否正常
    • DI / 設定是否正確
    • 相依套件是否缺漏
// 範例:測試 Logger 套件
var logger = new AppLogger();
logger.Log("測試訊息");

補充#

  • 不要每次測試都 push 套件 → 會拖慢開發節奏
  • 專案參考測試 OK 再重新打包發布
  • 注意版本號,不然 NuGet 可能抓舊版本

指令 / 範例整理#

Click to expend
Terminal window
# 推送 NuGet 套件
dotnet nuget push -s <https://xxx.yyy.zzz/v3/index.json> -k KEYXXX1234 AppLogger.1.0.0.nupkg

收尾#

  • 測試階段用專案參考,發佈再用 NuGet,節奏會乾淨很多。
NuGet 套件發布與本地測試實戰:從推送到驗證一次搞懂
https://joyceowo.github.io/posts/23ba78ea09fa815bab31cd64e4ab15c2/
作者
JoyceOwO
發佈於
2025-07-25
許可協議
CC BY-NC-SA 4.0