プロキシの背後にあるNuGet

NuGetでは、1.4バージョン以降、プロキシ設定を構成できることがわかりました。しかし、コマンドラインの例は見つかりません。

ビルドを実行しようとしていますが、NuGetが接続できません。

コマンドラインでプロキシ設定を構成するにはどうすればよいですか？

これは、NTLM認証を使用する社内プロキシでこれを機能させるために行ったものです。NuGet.exeをダウンロードして、次のコマンドを実行しました（CodePlex に関するこのディスカッションへのコメントで見つかりました）。

nuget.exe config -set http_proxy=http://my.proxy.address:port
nuget.exe config -set http_proxy.user=mydomain\myUserName
nuget.exe config -set http_proxy.password=mySuperSecretPassword

これにより、次のNuGet.config場所に配置されます%appdata%\NuGet（Windows 7マシンではC：\ Users \ myUserName \ AppData \ Roamingにマップされます）：

<configuration>
    <!-- stuff -->
    <config>
        <add key="http_proxy" value="http://my.proxy.address:port" />
        <add key="http_proxy.user" value="mydomain\myUserName" />
        <add key="http_proxy.password" value="base64encodedHopefullyEncryptedPassword" />
    </config>
    <!-- stuff -->
</configuration>

ちなみに、これにより、Visual Studioでパッケージソースに初めてアクセスしたときにのみNuGetが動作する問題も修正されました。

このアプローチを試みた一部の人々http_proxy.passwordは、コマンドラインからのキーの設定を省略したり、構成ファイルから実際のキーを削除したりしても、NuGet関数を引き続き使用できるというコメントを通じて報告していることに注意してください。プロキシ全体。

しかし、あなたの見つけた場合、あなたがすることをしなければならない、NuGetの設定ファイルにパスワードを指定し、プロキシ資格情報はまた、ネットワークされている場合は、あなたがあなたのネットワークへのログインを変更すると、コマンドラインからNuGetの設定で保存されたパスワードを更新する必要があることを覚えておいてください資格情報。

多分あなたはあなたのdevenv.exe.configにこれを試すことができます

<system.net>
    <defaultProxy useDefaultCredentials="true" enabled="true">
        <proxy proxyaddress="http://proxyaddress" />
    </defaultProxy>
    <settings>
        <servicePointManager expect100Continue="false" />
        <ipv6 enabled="true"/>
    </settings>
</system.net>

NuGet Issueトラッカーから見つけました

NuGet +ネットワークの問題に関する他の貴重なコメントもあります。

nugetのhttpsバージョン（https://www.nuget.org）を使用している場合に備えて、httpsで値を設定する必要があることに注意してください。

• https_proxy
• https_proxy.user
• https_proxy.password

私は間違っている可能性がありますが、IEのプロキシ設定を使用していると思いました。

ログインする必要があると判断すると、ダイアログが開き、ログインするように求められます（つまり、ログインします）。

こちらの説明をご覧ください-> http://docs.nuget.org/docs/release-notes/nuget-1.5

VS2015を使用しているユーザーへ：「407プロキシ認証が必要です」というエラーが発生し、ビルドが壊れました。数時間調査した結果、「DownloadNuGet」ターゲットの一部としてNugetをダウンロードしようとしたときに、MSBuildが資格情報を送信していなかったことが判明しました。解決策は、次のXMLを<configuration>要素内のC：\ Program Files（x86）\ MSBuild \ 14.0 \ Bin \ MSBuild.exe.configに追加することでした。

<system.net>
            <defaultProxy useDefaultCredentials="true">
            </defaultProxy>
</system.net>

私のための解決策は含めることでした

<configuration>
  <config>
    <add key="http_proxy" value="http://<IP>:<Port>" />
    <add key="http_proxy.user" value="<user>" />
    <add key="http_proxy.password" value="<password>" />
  </config>
</configuration>

でnuget.configファイル。

同じ「nugetのプロキシ」の別のフレーバー：あるいは、fiddlerを介して接続するようにnugetプロキシ設定を設定できます。以下のcmdは、ユーザーのデフォルトのnuget構成ファイルにプロキシ設定を保存します%APPDATA%\NuGet\NuGet.Config

nuget config -Set HTTP_PROXY=http://127.0.0.1:8888

インターネットに接続するためにnugetが必要なときはいつでも、Fiddlerを開いて、デフォルトのポート8888でFiddlerがリッスンしていると仮定します。

フィドラーはアップストリームプロキシを使用してすべての認証を解決するため、この構成はパスワークの変更の影響を受けません。

多分これは誰かを助ける。私にとっての解決策は、Visual Studio（2015/2017）でNuGet設定を開き、新しいフィードURL http://www.nuget.org/api/v2/を追加することでした。

プロキシ関連の設定を変更する必要はありませんでした。

ほんの少し追加...

ユーザー名とパスワードではなく、http_proxy設定のみを指定しても問題ない場合は、プロジェクトのローカルnuget.configファイルにプロキシ設定を配置し、ソース管理にコミットすることをお勧めします。これにより、すべてのチームメンバーが同じ設定を取得します。

空の。\ nuget.configを作成します

   <?xml version="1.0" encoding="utf-8"?>
   <configuration>
   </configuration>

次に：

   nuget config -Set http_proxy="http://myproxy.example.com:8080" -ConfigFile .\Nuget.Config

そして最後に、新しいプロジェクトのローカルNuget.configファイルをコミットします。

これを試してください。基本的に、システムがnuget証明書を信頼していない場合、接続が失敗する可能性があります。

@arcainからの提案とは別に、次のWindows Azureコンテンツ配信ネットワークのURLをプロキシサーバーのホワイトリストに追加する必要がありました。

.msecnd.net

上記の@arcain Plusによる上記の解決策で問題が解決しました

1. Nugetパッケージマネージャー設定の下の「パッケージソース」を変更して、nuget.org設定を使用するチェックボックスをオンにすると、問題が解決しました。

2. また、パッケージソースの最初の選択肢としてthat（nuget.org）を使用するように変更しました。
   会社のパッケージソースのチェックを外して、nugetが常にグローバルソースから取得されるようにしました。

私が開発しているWindows Server 2016 Standardでは、Credential Managerコントロールパネルを開き、キャッシュされたVisual Studioのプロキシ設定を消去して、無効にしてからVisual Studioを再起動する必要がありました。次にNuget Package Managerを開いたときに、プロキシ資格情報の入力を求められたため、再び作業を開始しました。

参照：https : //support.microsoft.com/en-us/help/4026814/windows-accessing-credential-manager