 <p>This appears to be a defect in the dotnet dnx tools but in my case I was able to work around the defect. I expect a fix will will be in place by RTM as this was an RC build of dot net core.</p> <p>The Nuget.HttpSource constructor assigns the credentials as follows when the environment variable "http_proxy" is in the simple (non-username) format:</p> <pre><code>UriBuilder builder = new UriBuilder(environmentVariable); WebProxy proxy = new WebProxy(environmentVariable); if (string.IsNullOrEmpty(builder.UserName)) { proxy.Credentials = CredentialCache.DefaultCredentials; } </code></pre> <p>DefaultCredentials is set to an immutable set of empty Credentials:</p> <pre><code>SystemNetworkCredential.s_defaultCredential = new SystemNetworkCredential(); private SystemNetworkCredential() : base(string.Empty, string.Empty, string.Empty) {} </code></pre> <p>Since SetProxyOptions() checks the credential using:</p> <pre><code>if (credential != null) { if (string.IsNullOrEmpty(credential.UserName)) throw ... </code></pre> <p>And the UserName is Empty it will always throw an exception. </p> <p>If instead it were to check using:</p> <pre><code>if (credential != null &amp;&amp; !string.IsNullOrEmpty(credential.UserName)) // do cred work </code></pre> <p>Then all would be well. Null or default credentials (e.g. SystemDefaultCredentials which are immutably empty) would be treated as "no credentials".</p> <p>Otherwise Microsoft could change the DNX tool to leave the credentials null instead of using the SystemDefaultCredentials. This is a simple case of the caller and callee disagreeing on the protocol for specifying a lack of credentials (null ref vs. ref with empty strings).</p> <p>In my case the workaround I used was to fill in a bogus credential so that the dnx tool wouldn't throw. Luckily my proxy server didn't complain about the unwanted and invalid credential.</p>