NuGet detrás de un proxy

Me doy cuenta de que NuGet permite la configuración de la configuración del proxy desde la versión 1.4. Pero no puedo encontrar ningún ejemplo de línea de comando.

Estoy intentando ejecutar una compilación y NuGet no se puede conectar.

¿Cómo configuro la configuración del proxy en la línea de comando?

Esto es lo que hice para que esto funcione con mi proxy corporativo que usa autenticación NTLM. Descargué NuGet.exe y luego ejecuté los siguientes comandos (que encontré en los comentarios de esta discusión sobre 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

Esto puso lo siguiente en mi NuGet.configubicación en %appdata%\NuGet(que se asigna a C: \ Users \ myUserName \ AppData \ Roaming en mi máquina con 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>

Por cierto, esto también solucionó mi problema con NuGet que solo funcionaba la primera vez que ingresé al código fuente del paquete en Visual Studio.

Tenga en cuenta que algunas personas que han probado este enfoque han informado a través de los comentarios que han podido omitir la configuración de la http_proxy.passwordclave desde la línea de comandos, o eliminarla después del hecho del archivo de configuración, y aún podían tener la función NuGet. a través del proxy.

Sin embargo, si descubre que debe especificar su contraseña en el archivo de configuración de NuGet, recuerde que debe actualizar la contraseña almacenada en la configuración de NuGet desde la línea de comando cuando cambie su inicio de sesión de red, si sus credenciales de proxy también son su red. credenciales .

Tal vez puedas probar esto en tu 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>

Lo encontré en el rastreador de problemas de NuGet

También hay otros comentarios valiosos sobre los problemas de la red NuGet +.

En caso de que esté utilizando la versión https de nuget ( https://www.nuget.org ), tenga en cuenta que debe establecer los valores con https.

• https_proxy
• https_proxy.user
• https_proxy.password

Podría estar equivocado, pero pensé que usaba la configuración de proxy de IE.

Si ve que necesita iniciar sesión, abre un cuadro de diálogo y le pide que lo haga (inicie sesión).

Consulte la descripción de esto aquí -> http://docs.nuget.org/docs/release-notes/nuget-1.5

Para cualquiera que use VS2015: Me encontré con un error "407 Proxy Authentication required", que rompió mi compilación. Después de algunas horas de investigación, resulta que MSBuild no estaba enviando credenciales al intentar descargar Nuget como parte del objetivo 'DownloadNuGet'. La solución fue agregar el siguiente XML a C: \ Archivos de programa (x86) \ MSBuild \ 14.0 \ Bin \ MSBuild.exe.config dentro del <configuration>elemento:

<system.net>
            <defaultProxy useDefaultCredentials="true">
            </defaultProxy>
</system.net>

La solución para mí fue incluir

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

En el nuget.configarchivo.

Otro sabor para el mismo "proxy para nuget": alternativamente, puede establecer su configuración de proxy nuget para conectarse a través de Fiddler . A continuación, cmd guardará la configuración del proxy en el archivo de configuración de nuget predeterminado para el usuario en%APPDATA%\NuGet\NuGet.Config

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

Siempre que necesite nuget para conectarse a Internet, simplemente abra Fiddler, asumiendo que tiene Fiddler escuchando en el puerto predeterminado 8888.

Esta configuración no es sensible a los cambios de contraseña porque Fiddler resolverá cualquier autenticación con el proxy de flujo ascendente por usted.

Quizás esto ayude a alguien más. Para mí, la solución fue abrir la configuración de NuGet en Visual Studio (2015/2017) y agregar una nueva URL de alimentación: http://www.nuget.org/api/v2/ .

No tuve que cambiar ninguna configuración relacionada con el proxy.

Solo una pequeña adición ...

Si funciona para que solo proporcione la configuración http_proxy y no el nombre de usuario y la contraseña, le recomiendo que coloque la configuración del proxy en un archivo nuget.config local del proyecto y lo confirme en el control de origen. De esa forma, todos los miembros del equipo obtienen la misma configuración.

Cree un. \ Nuget.config vacío

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

Luego:

   nuget config -Set http_proxy="http://myproxy.example.com:8080" -ConfigFile .\Nuget.Config

Y finalmente confirme el archivo Nuget.config local de su nuevo proyecto.

Prueba esto . Básicamente, la conexión podría fallar si su sistema no confía en el certificado nuget.

Además de las sugerencias de @arcain, tuve que agregar la siguiente URL de la Red de entrega de contenido de Windows Azure a la lista blanca de nuestro servidor proxy:

.msecnd.net

La solución anterior por @arcain Plus a continuación, me resolvió el problema.

1. La modificación de las "fuentes del paquete" en la configuración del administrador de paquetes de Nuget para marcar la casilla de verificación para usar la configuración de nuget.org resolvió mi problema.

2. También cambié para usar eso (nuget.org) como la primera opción de fuente de paquete.
   Desmarqué las fuentes de paquetes de mi empresa para asegurarme de que el nuget siempre se recogiera de fuentes globales.

En Windows Server 2016 Standard, que es en lo que desarrollo, solo tuve que abrir el Panel de control de Credential Manager y borrar la configuración del proxy en caché para Visual Studio que ya no era válida y luego reiniciar Visual Studio. La próxima vez que abrí el Nuget Package Manager, se me solicitaron las credenciales de proxy, lo que me permitió volver a trabajar.

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