Я выясню, что 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.
Я мог ошибаться, но я думал, что он использовал настройки прокси-сервера 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>
Может быть, это помогает кому-то другому. Для меня решение заключалось в том, чтобы открыть настройки NuGet в Visual Studio (2015/2017) и добавить новый URL-адрес канала: http://www.nuget.org/api/v2/.
Мне не нужно было изменять какие-либо настройки, связанные с прокси.
Еще один аромат для такого же "прокси-сервера для nuget": альтернативно вы можете настроить параметры прокси-сервера nuget для подключения через fiddler. Ниже cmd сохранит настройки прокси-сервера в файле конфигурации nuget по умолчанию для пользователя в% APPDATA%\NuGet\NuGet.Config
nuget config -Set HTTP_PROXY = http://127.0.0.1:8888
Всякий раз, когда вам нужно nuget для доступа к Интернету, просто откройте Fiddler, и вы попробуете прослушивать скрипдер на порту 8888 по умолчанию.
Эта конфигурация не чувствительна к пассивным изменениям, так как скрипач разрешает любую аутентификацию с помощью прокси-сервера upstream для вас.
Просто небольшое дополнение...
Если вы используете только параметры 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 проекта.
Попробуйте this. В принципе, подключение может завершиться неудачно, если ваша система не доверяет сертификату nuget.
Помимо предложений от @arcain, я должен был добавить следующий URL-адрес сети доставки контента Windows Azure на наш прокси-сервер: белый список:
.msecnd.net
Выше решение от @arcain Plus ниже шагов разрешило мне проблему
Изменение "источников пакетов" в настройках ящика пакета Nuget для проверки флажок, чтобы использовать настройки nuget.org, разрешил мою проблему.
Я также изменил использование этого (nuget.org) в качестве первого выбора источника пакета
Я снял флажки с источников своего пакета, чтобы гарантировать, что nuget всегда был выбран
из глобальных источников.
Решение для меня было включить
<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.