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(яке відображається в C: \ Users \ myUserName \ AppData \ Roaming на моїй машині Windows 7):

<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>

Між іншим, це також вирішило мою проблему з NuGet, працюючи лише тоді, коли я потрапив у джерело пакунків у Visual Studio.

Зауважте, що деякі люди, які спробували такий підхід, повідомили через коментарі, що вони змогли опустити налаштування 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 +.

На всякий випадок, якщо ви використовуєте https версію nuget ( 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 потрібна автентифікація проксі", яка порушила мою збірку. Після кількох годин дослідження, виявляється, MSBuild не надсилав облікові дані при спробі завантажити Nuget як частину цілі "DownloadNuGet". Рішенням було додати наступний XML до C: \ Program Files (x86) \ MSBuild \ 14.0 \ Bin \ MSBuild.exe.config всередині <configuration>елемента:

<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файлі.

Ще один аромат того ж «proxy for nuget»: як альтернатива, ви можете встановити свої налаштування наближення, щоб підключитися через fiddler . Знизу cmd буде збережено налаштування проксі-сервера в стандартному файлі конфігурації назви для користувача в%APPDATA%\NuGet\NuGet.Config

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

Всякий раз, коли вам потрібен доступ до Інтернету, просто відкрийте Fiddler, вважаючи, що ви слухаєте скрипта на порту 8888 за замовчуванням.

Ця конфігурація не чутлива до змін у роботі, оскільки фіддер вирішить будь-яку автентифікацію за допомогою проксі-потоку для вас.

Можливо, це допомагає комусь іншому. Для мене рішенням було відкрити налаштування NuGet у Visual Studio (2015/2017) та додати нову 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.

Спробуйте це . В основному, підключення може не вдатися, якщо ваша система не довіряє сертифікату нута.

Окрім пропозицій від @arcain, я мав додати наступний URL-адресу Мережі доставки вмісту Windows Azure до білого списку нашого проксі-сервера:

.msecnd.net

Вище рішення від @arcain Plus нижче кроків вирішило мені проблему

1. Змінення "джерел пакунків" у налаштуваннях керування пакетами Nuget, щоб встановити прапорець, щоб використовувати налаштування nuget.org, вирішив мою проблему.

2. Я також змінив, щоб використовувати це (nuget.org) як перший вибір джерела пакунків,
   я знімав прапорці для джерел пакетних пакетів своєї компанії, щоб гарантувати, що цей нут завжди був обраний із глобальних джерел.

У Windows Server 2016 Standard, над яким я розвиваюсь, мені просто довелося відкрити панель керування Credential Manager і очистити кешовані налаштування проксі для Visual Studio, які більше не дійсні, а потім перезапустити Visual Studio. Наступного разу, коли я відкрив диспетчера пакунків Nuget, мені було запропоновано проксі-дані, завдяки чому я знову працював.

Дивіться: https://support.microsoft.com/en-us/help/4026814/windows-accessing-credential-manager