Следующее относится к связанному вопросу, на который я недавно ответил .
Вот что я сделал, чтобы заставить это работать с моим корпоративным прокси-сервером, использующим проверку подлинности 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 из командной строки, когда вы меняете сетевой логин, если ваши учетные данные прокси-сервера также являются сетевыми учетными данными .