NuGet derrière un proxy

Je comprends que NuGet permet la configuration des paramètres de proxy depuis la version 1.4. Mais, je ne trouve aucun exemple de ligne de commande.

J'essaie d'exécuter une compilation et NuGet ne peut pas se connecter.

Comment configurer les paramètres proxy sur la ligne de commande?

Voici ce que j'ai fait pour que cela fonctionne avec mon proxy d'entreprise qui utilise l'authentification NTLM. J'ai téléchargé NuGet.exe , puis j'ai exécuté les commandes suivantes (que j'ai trouvées dans les commentaires de cette discussion sur 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

Cela place ce qui suit dans mon NuGet.configsitué à %appdata%\NuGet(qui correspond à C: \ Users \ myUserName \ AppData \ Roaming sur ma machine 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>

Incidemment, cela a également résolu mon problème avec NuGet ne fonctionnant que la première fois que j'ai atteint la source du package dans Visual Studio.

Notez que certaines personnes qui ont essayé cette approche ont signalé dans les commentaires qu'elles avaient pu omettre de définir la http_proxy.passwordclé de la ligne de commande, ou la supprimer après coup du fichier de configuration, et pouvaient toujours avoir la fonction NuGet à travers le proxy.

Si vous trouvez, cependant, que vous devez spécifier votre mot de passe dans le fichier de configuration NuGet, n'oubliez pas que vous devez mettre à jour le mot de passe stocké dans la configuration NuGet à partir de la ligne de commande lorsque vous modifiez votre connexion réseau, si vos informations d'identification de proxy sont également votre réseau informations d'identification .

Peut-être que vous pourriez essayer ceci sur votre 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>

Je l'ai trouvé à partir du suivi des problèmes NuGet

Il existe également d'autres commentaires utiles sur les problèmes de réseau NuGet +.

Juste au cas où vous utilisez la version https de nuget ( https://www.nuget.org ), sachez que vous devez définir les valeurs avec https.

• https_proxy
• https_proxy.user
• https_proxy.password

Je peux me tromper mais je pensais qu'il utilisait les paramètres proxy d'IE.

S'il voit que vous devez vous connecter, il ouvre une boîte de dialogue et vous demande de le faire (connexion c'est-à-dire).

Veuillez consulter la description de ceci ici -> http://docs.nuget.org/docs/release-notes/nuget-1.5

À toute personne utilisant VS2015: je rencontrais une erreur «407 Proxy Authentication required», qui a cassé ma version. Après quelques heures d'enquête, il s'avère que MSBuild n'envoyait pas d'informations d'identification lors de la tentative de téléchargement de Nuget dans le cadre de la cible 'DownloadNuGet'. La solution consistait à ajouter le code XML suivant à C: \ Program Files (x86) \ MSBuild \ 14.0 \ Bin \ MSBuild.exe.config à l'intérieur de l' <configuration>élément:

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

La solution pour moi était d'inclure

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

Dans le nuget.configfichier.

Une autre saveur pour le même "proxy pour nuget": vous pouvez également définir vos paramètres de proxy nuget pour vous connecter via Fiddler . Ci-dessous cmd enregistrera les paramètres de proxy dans le fichier de configuration par défaut du nuget pour l'utilisateur à%APPDATA%\NuGet\NuGet.Config

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

Chaque fois que vous avez besoin de nuget pour accéder à Internet, ouvrez simplement Fiddler, car vous avez un violon écoutant sur le port par défaut 8888.

Cette configuration n'est pas sensible aux changements de passwork car Fiddler résoudra pour vous toute authentification avec un proxy en amont.

Peut-être que cela aide quelqu'un d'autre. Pour moi, la solution était d'ouvrir les paramètres NuGet sur Visual Studio (2015/2017) et d'ajouter une nouvelle URL de flux: http://www.nuget.org/api/v2/ .

Je n'ai pas eu à modifier les paramètres liés au proxy.

Juste un petit ajout ...

Si cela fonctionne pour vous de ne fournir que le paramètre http_proxy et non le nom d'utilisateur et le mot de passe, je vous recommande de placer les paramètres de proxy dans un fichier nuget.config local du projet et de le valider au contrôle de code source. De cette façon, tous les membres de l'équipe obtiennent les mêmes paramètres.

Créez un. \ Nuget.config vide

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

Ensuite:

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

Et enfin, validez votre nouveau fichier Nuget.config local de projet.

Essayez ceci . Fondamentalement, la connexion peut échouer si votre système ne fait pas confiance au certificat nuget.

Outre les suggestions de @arcain, j'ai dû ajouter l'URL suivante du réseau de distribution de contenu Windows Azure à la liste blanche de notre serveur proxy:

.msecnd.net

Ci-dessus Solution by @arcain Plus, les étapes ci-dessous m'ont résolu le problème

1. La modification des "sources du package" sous les paramètres du gestionnaire de packages Nuget pour cocher la case pour utiliser les paramètres nuget.org a résolu mon problème.

2. J'ai également changé pour utiliser cela (nuget.org) comme premier choix de source de paquet.
   J'ai décoché les sources de paquet de ma société pour m'assurer que le nuget était toujours récupéré à partir de sources mondiales.

Sur Windows Server 2016 Standard, sur lequel je développe, je devais simplement ouvrir le panneau de configuration Credential Manager et effacer les paramètres de proxy mis en cache pour Visual Studio qui n'étaient plus valides, puis redémarrer Visual Studio. La prochaine fois que j'ai ouvert le gestionnaire de packages Nuget, on m'a demandé des informations d'identification de proxy, ce qui m'a permis de travailler à nouveau.

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