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

Есть также другие ценные комментарии о проблемах сети 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 Proxy Authentication required», которая нарушила мою сборку. После нескольких часов исследования выяснилось, что 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файле.

Другой вариант для того же «прокси для nuget»: в качестве альтернативы вы можете настроить параметры проксирования nuget для подключения через скрипач . Ниже cmd сохранит настройки прокси в файле конфигурации nuget по умолчанию для пользователя по адресу%APPDATA%\NuGet\NuGet.Config

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

Всякий раз, когда вам понадобится nuget для выхода в Интернет, просто откройте 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 вашего нового проекта.

В Windows Server 2016 Standard, над которой я работаю, мне просто нужно было открыть панель управления диспетчера учетных данных и очистить кешированные настройки прокси-сервера для Visual Studio, которые больше не действительны, а затем перезапустить Visual Studio. В следующий раз, когда я открыл диспетчер пакетов Nuget, мне было предложено ввести учетные данные прокси, что заставило меня снова работать.

См .: https://support.microsoft.com/en-us/help/4026814/windows-accessing-credential-manager

Попробуйте это . По сути, соединение может завершиться ошибкой, если ваша система не доверяет сертификату nuget.

Помимо предложений от @arcain, мне пришлось добавить следующий URL-адрес сети доставки контента Windows Azure в белый список нашего прокси-сервера:

.msecnd.net

Вышеупомянутое решение от @arcain Plus, приведенное ниже, решило проблему.

1. Изменение «источников пакетов» в настройках диспетчера пакетов Nuget, чтобы установить флажок для использования настроек nuget.org, разрешило мою проблему.

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