NuGet возвращает 503 Сервер недоступен

Ответ 1

Это неясное условие, которое, скорее всего, произойдет только в "корпоративной" сетевой среде. Если эти условия применяются к вам:

• вам необходимо получить доступ к Интернету через прокси-сервер HTTP

• прокси-серверу HTTP требуется действительный идентификатор пользователя & пароль (или аутентификация AD) для разрешения запросов

• вы возились с классными инструментами разработчика, которые были перенесены на Windows из среды Linux/Unix

• новые классные инструменты работают после добавления HTTP_PROXY (или, возможно, HTTPS_PROXY или обоих) переменная (и) среды

• Вы можете получить доступ к серверам NuGet из браузера , не получая ошибку 503

Тогда, скорее всего, вы сломали NuGet, случайно вызвав эту конфигурационную функцию. Я не уверен, как именно переменная окружения нарушает NuGet, но я подозреваю, что NuGet обнаруживает & используя http_proxy URL, но отправляя пустой идентификатор пользователя & пароль, который заставляет HTTP-прокси отклонять запрос.

Исправление: удалите переменные среды, которые вы добавили, и посмотрите, можно ли настроить классный инструмент на использование прокси-сервера HTTP без них.

Обновление: Обнаружена версия этой проблемы с файлом конфигурации NuGet, на который есть ссылка в приведенной выше ссылке "эта функция конфигурации". Откройте этот файл:

% AppData%\NuGet\nuget.config

в вашем любимом редакторе. Если он содержит элементы с http_proxy или https_proxy, то удаление этих элементов также может решить проблему.

PS: Надеюсь, я получу голос от полковника Паника :-)

Ответ 2

Если вы использовали этот пакет в прошлом, он, вероятно, находится в вашем кеше. Вы можете добавить локальный кеш в качестве доступного источника пакета, перейдя в настройки диспетчера пакетов библиотеки в меню "Инструменты" в Visual Studio. В Visual Studio 2012 выберите "Инструменты", "Диспетчер пакетов библиотек", "Параметры диспетчера пакетов" и нажмите "Источники пакетов".

В разделе "Доступные источники пакетов" введите имя "Кэш", а затем источник для источника, найдите % LocalAppData%\NuGet\Cache. Возможно, вам потребуется использовать проводник Windows для перевода% LocalAppData%\NuGet\Cache в полный путь (обычно C:\Users\YourAccountName\AppData\Local\NuGet\Cache).

Как только у вас есть кэш как доступный источник, теперь вы можете использовать консоль диспетчера пакетов (найденную в меню "Вид" в разделе "Другие Windows" или также в меню "Сервис" в разделе "Диспетчер пакетов библиотек" ).

Из консоли (которая является окном PowerShell с командами для NuGet) вы можете ввести "get-help NuGet", чтобы увидеть доступные команды.

Затем, используя Get-Package, вы можете получить список идентификаторов пакетов. Убедитесь, что для параметра "Источник пакета" установлено значение "Кэш" (или как вы его назвали), а проект по умолчанию установлен в проект, который вам нужно манипулировать, оба из них - выпадающие списки, расположенные в верхней части консоли "Менеджер страниц". Вы также можете использовать Get-Project, чтобы убедиться, что вы работаете с правильным проектом в своем решении.

Наконец, вы можете ввести Install-Package, и при появлении запроса введите идентификатор пакета из вывода командлета Get-Package.

Ответ 3

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

попробуйте загрузить пакет в другой сети, возможно, он может вам помочь!

Ответ 4

Ответ Talbott не работал у меня, так как мой кеш был пуст. Однако, если вы использовали пакет в другом решении, вы можете скопировать нужные элементы из папки "пакеты" в другом решении в папку пакетов в целевом решении.

Если у вас нет пакетов, установленных в целевом решении, возможно, вам придется добавить следующее в файл repositories.xml в папке пакетов:

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

После этого пакеты, как оказалось, были установлены в моем решении, и я смог добавить их в проекты.

Дополнительная заметка: мне пришлось использовать параметр "Управление пакетами NuGet для решения" на уровне решения, чтобы добавить пакет к отдельным проектам. Использование Install-Package из консоли по-прежнему возвращает 503, хотя пакеты уже установлены в решении.

Ответ 5

Вы также можете получить эту ошибку, если используете VPN-клиент (например, Cisco AnyConnect), и недавно обновили свой сертификат VPN. Эта проблема может возникнуть после обновления сертификата, но перед перезагрузкой. Перезагрузка устраняет проблему.

Ответ 6

Это довольно старый вопрос, но я только что столкнулся с той же проблемой. В моем случае это произошло из-за того, что в диспетчере пакетов Visual Studio было настроено более одного источника пакетов nuget. В моей компании мы используем NuGet для получения основных пакетов, а MyGet - для своих собственных.

Когда я попытался вытащить довольно большой пакет, он потерпел неудачу с кодом 503, и ссылка на ошибку выглядела довольно странно, в ней вместо MyGet был MyGet. Оказывается, менеджер пакетов Visual Studio пытался извлечь его из другого источника, несмотря на то, что NuGet был выбран в качестве текущего источника. Отключение других источников и последующая загрузка исправили это.

Надеюсь, это поможет кому-то, кто наткнулся на эту тему, как я.