385 字
2 分鐘
NuGet 套件發布與本地測試實戰:從推送到驗證一次搞懂
結論
- 發佈後直接用「專案參考」測試,比重新下載套件更快、更可控。
適合用在哪裡
- 自建 NuGet 私服 / 公司內部套件
- 開發共用工具(Logging / Utils / SDK)
- 發佈後想快速驗證功能是否正常
- 避免反覆 push / install 浪費時間
流程步驟
1. 推送 NuGet 套件
- 將打包好的
.nupkg上傳到 NuGet Server - 確認 API Key 與 Server URL 正確
# 推送套件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
# 推送 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/