NuGet za serwerem proxy

Doszedłem do wniosku, że NuGet umożliwia konfigurację ustawień proxy od wersji 1.4. Ale nie mogę znaleźć żadnego przykładu wiersza poleceń.

Próbuję uruchomić jakąś kompilację, a NuGet nie może się połączyć.

Jak skonfigurować ustawienia proxy w wierszu poleceń?

Oto, co zrobiłem, aby to działało z moim korporacyjnym serwerem proxy, który używa uwierzytelniania NTLM. Pobrałem NuGet.exe a następnie prowadził następujące polecenia (które znalazłem w komentarzach do tej dyskusji na 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

To umieściło następujące w mojej NuGet.configlokalizacji %appdata%\NuGet(która mapuje do C: \ Users \ myUserName \ AppData \ Roaming na moim komputerze z systemem 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>

Nawiasem mówiąc, rozwiązało to również mój problem z NuGet działającym tylko przy pierwszym trafieniu do źródła pakietu w programie Visual Studio.

Zwróć uwagę, że niektóre osoby, które wypróbowały to podejście, zgłosiły w komentarzach, że udało im się pominąć ustawienie http_proxy.passwordklucza z wiersza poleceń lub usunąć go po fakcie z pliku konfiguracyjnego i nadal mogły mieć funkcję NuGet przez proxy.

Jeśli jednak okaże się, że musisz określić swoje hasło w pliku konfiguracyjnym NuGet, pamiętaj, że musisz zaktualizować przechowywane hasło w konfiguracji NuGet z wiersza polecenia podczas zmiany logowania sieciowego, jeśli poświadczenia serwera proxy są również Twoją siecią poświadczenia .

Może mógłbyś spróbować tego na swoim 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>

Znalazłem go w narzędziu do śledzenia problemów NuGet

Istnieją również inne cenne komentarze dotyczące problemów z siecią NuGet +.

Na wszelki wypadek, gdy używasz wersji https nuget ( https://www.nuget.org ), pamiętaj, że musisz ustawić wartości przy użyciu https.

• https_proxy
• https_proxy.user
• https_proxy.password

Mogę się mylić, ale myślałem, że używa ustawień proxy IE.

Jeśli zauważy, że musisz się zalogować, otwiera okno dialogowe i prosi o zrobienie tego (czyli logowanie).

Zobacz opis tego tutaj -> http://docs.nuget.org/docs/release-notes/nuget-1.5

Dla każdego, kto używa VS2015: napotkałem błąd „Wymagane uwierzytelnienie serwera proxy 407”, który zepsuł moją kompilację. Po kilku godzinach badania okazuje się, że MSBuild nie wysyłał poświadczeń podczas próby pobrania Nuget w ramach celu „DownloadNuGet”. Rozwiązaniem było dodanie następującego XML do C: \ Program Files (x86) \ MSBuild \ 14.0 \ Bin \ MSBuild.exe.config wewnątrz <configuration>elementu:

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

Rozwiązaniem dla mnie było włączenie

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

W nuget.configpliku.

Inny wariant tego samego „serwera proxy dla nuget”: alternatywnie możesz ustawić ustawienia serwera proxy nuget, aby łączyć się przez skrzypce . Poniżej cmd zapisze ustawienia serwera proxy w domyślnym pliku konfiguracji NuGet dla użytkownika pod adresem%APPDATA%\NuGet\NuGet.Config

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

Zawsze, gdy potrzebujesz nuget, aby połączyć się z Internetem, po prostu otwórz Fiddlera, zakładając, że masz fiddler nasłuchujący na domyślnym porcie 8888.

Ta konfiguracja nie jest wrażliwa na zmiany hasła, ponieważ skrzypek rozwiąże za Ciebie wszelkie uwierzytelnianie za pomocą serwera proxy nadawczego.

Może to pomoże komuś innemu. Dla mnie rozwiązaniem było otwarcie ustawień NuGet w programie Visual Studio (2015/2017) i dodanie nowego adresu URL źródła: http://www.nuget.org/api/v2/ .

Nie musiałem zmieniać żadnych ustawień związanych z proxy.

Tylko mały dodatek ...

Jeśli działa, aby podać tylko ustawienie http_proxy, a nie nazwę użytkownika i hasło, zalecamy umieszczenie ustawień serwera proxy w lokalnym pliku nuget.config projektu i zatwierdzenie go do kontroli źródła. W ten sposób wszyscy członkowie zespołu otrzymają te same ustawienia.

Utwórz pusty plik. \ Nuget.config

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

Następnie:

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

Na koniec zatwierdź nowy lokalny plik Nuget.config nowego projektu.

W systemie Windows Server 2016 Standard, na którym rozwijam, po prostu musiałem otworzyć panel sterowania Credential Manager i wyczyścić buforowane ustawienia proxy dla programu Visual Studio, które nie były już ważne, a następnie ponownie uruchomić program Visual Studio. Następnym razem, gdy otworzyłem Menedżera pakietów Nuget, zostałem poproszony o podanie poświadczeń serwera proxy, co sprawiło, że znów działałem.

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

Spróbuj tego . Zasadniczo połączenie może się nie powieść, jeśli system nie ufa certyfikatowi NuGet.

Oprócz sugestii z @arcain musiałem dodać następujący adres URL Windows Azure Content Delivery Network do białej listy naszego serwera proxy:

.msecnd.net

Powyższe rozwiązanie autorstwa @arcain Plus Poniższe kroki rozwiązały problem

1. Modyfikacja „źródeł pakietów” w ustawieniach menedżera pakietów NuGet w celu zaznaczenia pola wyboru umożliwiającego korzystanie z ustawień NuGet.org rozwiązała mój problem.

2. Zmieniłem również, aby używać tego (nuget.org) jako pierwszego wyboru źródła pakietów. Odznacziłem źródła pakietów
   mojej firmy, aby upewnić się, że nuget był zawsze pobierany ze źródeł globalnych.