NuGet の復元には、フォワード プロキシのアカウントとプライベート フィードのアカウントの両方が必要になることがあります。どちらの構成を確認すべきかは、応答で判断します。

観察ここから始める
プロキシが 407 を返すフォワード プロキシに到達するための経路とアカウント
パッケージ ソースが 401 を返すフィードの認証構成
応答の前に接続または TLS が失敗するエンドポイント、トランスポート、証明書の根拠

フィードのトークンはプロキシの 407 には答えられません。同様に、応答前の接続や TLS の失敗は、どのパスワードが間違っているかを示すものではありません。

プロキシをフィードとは別に構成する

NuGet のプロキシ エントリは config の下に置きます。資格情報を埋め込まない経路の場合:

<configuration>
  <config>
    <add key="http_proxy" value="http://proxy.example:8080" />
  </config>
</configuration>

この例は、適切な既存の構成にマージしてください。パブリックな中間プロキシが許可される公開フィードでは、HTTP プロキシ リストがこの資格情報なしの経路の候補になります。パッケージ ソースは独立したセクションに保ちます。フィードの URL を汎用のプロキシ アドレスに置き換えると、中間プロキシにパッケージを要求することになります。

文書化されている http_proxy.password の値は暗号化されています。平文をそのフィールドに書いたり、別のマシンから暗号化されたように見える値を可搬な資格情報形式であるかのようにコピーしたりせず、サポートされている構成ツールを使用してください。

実際に失敗している復元を確認する

クライアント、ユーザー、起動環境を特定し、その有効な構成階層を突き止めます。ユーザー、マシン、ソリューションの設定が関与することがあります。古い devenv.exe.config の修正は特定の Visual Studio プロセスに関するものであり、コマンド ラインの復元やビルド サービスが何を読むかを示すものではありません。古いプロキシ エントリを探す間も、動作しているパッケージ ソースとポリシーは維持してください。

認証が通ったら、その後に失敗する URL を追跡します。フィードのメタデータとパッケージの内容は異なるエンドポイントを使うことがあるため、1 回の要求が成功しても復元経路の全体を示すわけではありません。修正する間も、通常のパッケージ署名と TLS の検証は維持してください。

関連記事