Skip to content

MS_NuGetPrivateRepository

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

NuGetプライベート・リポジトリ

概要

ファイル共有と HTTP（NuGet.Server）の、
NuGet プライベート・リポジトリが比較的容易に建てられるもよう。

補足（なぜプライベート・リポジトリが要るか）: 社内で作った
ライブラリを共有したいが、nuget.org に公開はできない、
という要求に応えるための仕組みである。

【プライベート・リポジトリが無い場合】
   共有 DLL をファイル サーバに置き、各自がコピーして参照設定
     → 版が分からない／古い DLL が残る／依存関係が管理されない

【プライベート・リポジトリがある場合】
   dotnet add package MyCompany.Common --version 2.1.0
     → 版と依存関係が [NuGet](MS_NuGet) の仕組みで管理される

加えて、上流（nuget.org）のミラー／キャッシュとしての用途もある
（オフライン環境、ビルドの安定化、サプライ チェーン対策）。

詳細

ファイル共有による方法と、HTTP（NuGet.Server）による方法がある。

ファイル共有

補足（最も手軽な方法）: フォルダを 1 つ用意して、
.nupkg を置くだけでリポジトリとして機能する。

<!-- nuget.config -->
<configuration>
  <packageSources>
    <add key="local" value="\\fileserver\nuget-packages" />
  </packageSources>
</configuration>
dotnet nuget push MyLib.1.0.0.nupkg -s \\fileserver\nuget-packages
dotnet add package MyLib --source local
長所 短所
ファイル共有 サーバ不要。すぐ始められる 認証が SMB 頼み。検索が遅い（全走査）
HTTP 認証・検索・API が使える サーバの構築と運用が要る

数十パッケージ程度まではファイル共有で十分である。
数が増えると復元のたびに全ファイルを走査するため遅くなる。

HTTP（NuGet.Server）

補足（現在の選択肢／最新化）: 原文が挙げる NuGet.Server は
.NET Framework + IIS 向けのパッケージで、
現在はほとんど使われていない（更新も停止している）。

現在の主な選択肢は次の通り。

種別 名称 特徴
SaaS Azure Artifacts Azure DevOps に同梱。上流ミラーが強力
SaaS GitHub Packages GitHub の権限モデルをそのまま使える
SaaS MyGet 古参の NuGet ホスティング
自前（OSS） BaGet .NET 製・軽量。Docker で 1 コンテナ
自前（OSS） Sleet 静的サイトとして生成（S3 / Azure Blob に置ける）
自前（商用） Artifactory / Nexus 多言語のリポジトリを一元管理 
# BaGet を Docker で立てる例
docker run -d -p 5555:80 \
  -e ApiKey=SECRET \
  -v /var/baget:/var/baget \
  loicsharma/baget:latest

dotnet nuget push MyLib.1.0.0.nupkg -s http://localhost:5555/v3/index.json -k SECRET

判断の目安:

  • 既に Azure DevOps / GitHub を使っている → Azure Artifacts / GitHub Packages
    （認証が既存のアカウントで済むのが最大の利点）
  • 閉域網・オンプレのみ → BaGet（軽量）／ Artifactory（本格運用）
  • 静的ホスティングだけで済ませたい → Sleet

補足（実運用での要点）: プライベート・リポジトリを立てる際、
設定を誤るとセキュリティ事故につながる点に注意する。

① 依存関係かく乱（Dependency Confusion）への対策

複数のソースを登録していると、NuGet は
すべてのソースに問い合わせ、より新しい版を選ぶ。
このため、

社内パッケージ  MyCompany.Common 1.0.0（社内リポジトリ）
                       ↓
攻撃者が nuget.org に MyCompany.Common 99.0.0 を公開
                       ↓
ビルドが nuget.org 側を取得してしまう ← 任意コード実行

という攻撃が成立し得る。対策は packageSourceMapping（NuGet 6.0+）。

<packageSourceMapping>
  <packageSource key="nuget.org">
    <package pattern="*" />
  </packageSource>
  <packageSource key="private">
    <package pattern="MyCompany.*" />   <!-- 社内前置は社内からのみ -->
  </packageSource>
</packageSourceMapping>

② nuget.config に API キーを平文で書かない

# 暗号化して保存（Windows）
dotnet nuget add source https://... -n private -u USER -p PAT
# CI では環境変数・シークレット ストアから渡す

③ 上流ミラーで nuget.org への直接依存を断つ

Azure Artifacts や Artifactory の上流ソース機能を使うと、
一度取得したパッケージがリポジトリ側に保持されるため、

  • nuget.org 障害時もビルドできる
  • 公開側で削除されたパッケージが消えない（再現性）
  • 取り込むパッケージを審査・監査できる

という利点が得られる。

参考

Microsoft Learn

Tags: 移行, .NET開発, デプロイ, NuGet

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally