프록시 뒤의 NuGet

프록시 뒤의 NuGet

---

NuGet은 1.4 버전부터 프록시 설정 구성을 허용한다는 것을 알았습니다. 그러나 명령 줄 예제를 찾을 수 없습니다.

일부 빌드를 실행하려고하는데 NuGet이 연결할 수 없습니다.

명령 줄에서 프록시 설정을 구성하려면 어떻게합니까?

---

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( Windows 7 컴퓨터의 C : \ Users \ myUserName \ AppData \ Roaming 에 매핑 됨 ).

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

덧붙여서, 이것은 또한 Visual Studio에서 처음으로 패키지 소스에 도달했을 때만 작동하는 NuGet 문제를 해결했습니다.

이 접근 방식을 시도한 일부 사람들 http_proxy.password은 명령 줄에서 키 설정을 생략 하거나 구성 파일에서 사후에 삭제할 수 있었으며 여전히 NuGet 기능을 사용할 수 있었다는 의견을 통해보고 했습니다. 프록시를 통해.

그러나 NuGet 구성 파일에서 암호를 지정 해야하는 경우 프록시 자격 증명이 네트워크 인 경우 네트워크 로그인을 변경할 때 명령 줄에서 NuGet 구성에 저장된 암호를 업데이트해야합니다. 자격 증명 .

---

아마도 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>

NuGet 문제 추적기 에서 찾았습니다.

NuGet + 네트워크 문제에 대한 다른 귀중한 의견도 있습니다.

---

https 버전의 nuget ( https://www.nuget.org )을 사용하는 경우 https로 값을 설정해야합니다.

• https_proxy
• https_proxy.user
• https_proxy.password

---

나는 틀릴 수 있지만 IE의 프록시 설정을 사용한다고 생각했습니다.

로그인이 필요하다고 판단되면 대화 상자가 열리고 로그인하라는 메시지가 표시됩니다.

여기에서 이에 대한 설명을 참조하십시오-> http://docs.nuget.org/docs/release-notes/nuget-1.5

---

To anyone using VS2015: I was encountering a "407 Proxy Authentication required" error, which broke my build. After a few hours investigating, it turns out MSBuild wasn't sending credentials when trying to download Nuget as part of the 'DownloadNuGet' target. The solution was to add the following XML to C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe.config inside the <configuration> element:

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

---

The solution for me was to include

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

In the nuget.config file.

---

Maybe this helps someone else. For me the solution was to open NuGet settings on Visual Studio (2015/2017) and add a new feed URL: http://www.nuget.org/api/v2/.

I didn't have to change any proxy related settings.

---

Another flavor for same "proxy for nuget": alternatively you can set your nuget proxing settings to connect through fiddler. Below cmd will save proxy settings in in default nuget config file for user at %APPDATA%\NuGet\NuGet.Config

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

Whenever you need nuget to reach out the internet, just open Fiddler, asumming you have fiddler listening on default port 8888.

This configuration is not sensitive to passwork changes because fiddler will resolve any authentication with up stream proxy for you.

---

Just a small addition...

If it works for you to only supply the http_proxy setting and not username and password I'd recommend putting the proxy settings in a project local nuget.config file and commit it to source control. That way all team members get the same settings.

Create an empty .\nuget.config

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

Then:

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

And finally commit your new project local Nuget.config file.

---

Try this. Basically, connection could fail if your system doesn't trust nuget certificate.

---

Apart from the suggestions from @arcain I had to add the following Windows Azure Content Delivery Network url to our proxy server's the white-list:

.msecnd.net

---

Above Solution by @arcain Plus below steps solved me the issue

1. Modifying the "package sources" under Nuget package manger settings to check the checkbox to use the nuget.org settings resolved my issue.

2. I did also changed to use that(nuget.org) as the first choice of package source
   I did uncheck my company package sources to ensure the nuget was always picked up from global sources.

참고URL : https://stackoverflow.com/questions/9232160/nuget-behind-a-proxy