Home: dotnet restore with basic authentication failing

[TheRealPiotrP]

_From @simon-hardy on April 14, 2016 22:2_

Steps to reproduce

Ubuntu 14.04 container running on docker in Digital Ocean

Followed https://dotnet.github.io/getting-started/

Nexus Nuget feed with Basic Authentication enabled

Added feeds to Nuget.config with nuget add source & nuget setapikey.

Expected behavior

Manually running nuget 3.3.0 authenticates correctly, but:

Actual behavior

dotnet restore ./project.json

gives

log : Response status code does not indicate success: 401 (Unauthorized).

Detailed trace:

error: Response status code does not indicate success: 401 (Unauthorized).
trace: System.AggregateException: One or more errors occurred. (Failed to retrieve information from remote source 'http://subdomain.domain.com/repository/nuget.org-proxy/FindPackagesById()?id='MRAM.ServiceFramework''.) ---> NuGet.Protocol.Core.Types.FatalProtocolException: Failed to retrieve information from remote source 'http://subdomain.domain.com/repository/nuget.org-proxy/FindPackagesById()?id='MRAM.ServiceFramework''. ---> System.Net.Http.HttpRequestException: Response status code does not indicate success: 401 (Unauthorized).
trace: at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
trace: at NuGet.Protocol.HttpSource.d__16.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Protocol.Core.v3.RemoteRepositories.RemoteV2FindPackageByIdResource.d__23.MoveNext()
trace: --- End of inner exception stack trace ---
trace: at NuGet.Protocol.Core.v3.RemoteRepositories.RemoteV2FindPackageByIdResource.d__23.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Protocol.Core.v3.RemoteRepositories.RemoteV2FindPackageByIdResource.d__19.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.SourceRepositoryDependencyProvider.d__8.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.<>c__DisplayClass15_1.<b__0>d.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.d__15.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.d__14.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.d__11.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.d__8.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.d__3.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.d__3.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreCommand.d__19.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreCommand.d__14.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreCommand.d__11.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreCommand.d__8.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreRunner.d__1.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreRunner.<>c__DisplayClass0_0.<b__0>d.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreRunner.d__2.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreRunner.d__0.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.CommandLine.XPlat.RestoreCommand.<>c__DisplayClass0_1.<b__1>d.MoveNext()
trace: --- End of inner exception stack trace ---
trace: at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
trace: at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
trace: at Microsoft.Dnx.Runtime.Common.CommandLine.CommandLineApplication.Execute(String[] args)
trace: at NuGet.CommandLine.XPlat.Program.Main(String[] args)
trace: ---> (Inner Exception #0) NuGet.Protocol.Core.Types.FatalProtocolException: Failed to retrieve information from remote source 'http://subdomain.domain.com/repository/nuget.org-proxy/FindPackagesById()?id='MRAM.ServiceFramework''. ---> System.Net.Http.HttpRequestException: Response status code does not indicate success: 401 (Unauthorized).
trace: at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
trace: at NuGet.Protocol.HttpSource.d__16.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Protocol.Core.v3.RemoteRepositories.RemoteV2FindPackageByIdResource.d__23.MoveNext()
trace: --- End of inner exception stack trace ---
trace: at NuGet.Protocol.Core.v3.RemoteRepositories.RemoteV2FindPackageByIdResource.d__23.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Protocol.Core.v3.RemoteRepositories.RemoteV2FindPackageByIdResource.d__19.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.SourceRepositoryDependencyProvider.d__8.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.<>c__DisplayClass15_1.<b__0>d.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.d__15.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.d__14.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.d__11.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.d__8.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.d__3.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.DependencyResolver.RemoteDependencyWalker.d__3.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreCommand.d__19.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreCommand.d__14.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreCommand.d__11.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreCommand.d__8.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreRunner.d__1.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreRunner.<>c__DisplayClass0_0.<b__0>d.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreRunner.d__2.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.Commands.RestoreRunner.d__0.MoveNext()
trace: --- End of stack trace from previous location where exception was thrown ---
trace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
trace: at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
trace: at NuGet.CommandLine.XPlat.RestoreCommand.<>c__DisplayClass0_1.<b__1>d.MoveNext()<---

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-beta-001793)
Usage: dotnet [common-options] [command] [arguments]

Arguments:
[command] The command to execute
[arguments] Arguments to pass to the command

Common Options (passed before the command):
-v|--verbose Enable verbose output
--version Display .NET CLI Version Info

Common Commands:
new Initialize a basic .NET project
restore Restore dependencies specified in the .NET project
build Builds a .NET project
publish Publishes a .NET project for deployment (including the runtime)
run Compiles and immediately executes a .NET project
repl Launch an interactive session (read, eval, print, loop)
pack Creates a NuGet package

_Copied from original issue: dotnet/cli#2510_

[TheRealPiotrP]

_From @Petermarcu on April 14, 2016 23:12_

@yishaigalatzer , Can you take a look at confirm what needs to happen here?

[TheRealPiotrP]

_From @yishaigalatzer on April 14, 2016 23:14_

Yes, this was fixed already in 3.4.2, but wasn't merged yet into the CLI.

[TheRealPiotrP]

_From @blackdwarf on April 15, 2016 4:44_

Should we close this?

[TheRealPiotrP]

_From @yishaigalatzer on April 15, 2016 4:51_

After we merge

Sent from Outlook Mobilehttps://aka.ms/xp9y6l

On Thu, Apr 14, 2016 at 9:44 PM -0700, "Zlatko Knezevic" <[email protected][e-mail]> wrote:

Should we close this?

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/dotnet/cli/issues/2510#issuecomment-210285995

[TheRealPiotrP]

_From @simon-hardy on April 15, 2016 6:53_

@yishaigalatzer, any guidance on a likely time-frame for the merge to happen? or any workaround you know of in the meantime?

[TheRealPiotrP]

_From @eerhardt on April 15, 2016 15:17_

We've taken NuGet v3.5.0-beta-1160 in the latest CLI (CLI version 1.0.0-rc2-002392).

The issue report was using .NET Command Line Tools (1.0.0-beta-001793), which was a while ago.

[TheRealPiotrP]

_From @blackdwarf on April 15, 2016 15:27_

@simon-hardy can you try with latest and see if this still repros?

[TheRealPiotrP]

_From @simon-hardy on April 15, 2016 15:53_

@blackdwarf @eerhardt still get a similar error:

error: Failed to retrieve information from remote source 'http://configmanagement.xxx.com:8081/repository/nuget.org-proxy/FindPackagesById()?id='System.Linq''.
error: Response status code does not indicate success: 401 (Unauthorized).

[TheRealPiotrP]

_From @yishaigalatzer on April 15, 2016 15:57_

@simon-hardy yes because it wasn't integrated yet into the CLI and hence this bug should stay open until it does. You can use nuget.exe 3.4.2 in the meantime. The root cause is a bug in the nexus server that the new code doesn't have a hack to work around with.

[TheRealPiotrP]

_From @simon-hardy on April 15, 2016 16:0_

@yishaigalatzer ok you guys need to get on the same page as @eerhardt is indicating the RC2 CLI has nuget.exe 3.5.0 integrated...

[TheRealPiotrP]

_From @eerhardt on April 15, 2016 16:10_

@yishaigalatzer - can you elaborate on which "merge" needs to happen? The way I read your response is that the CLI needs to merge a new NuGet build. But we have the latest NuGet build.

[TheRealPiotrP]

_From @yishaigalatzer on April 15, 2016 16:23_

@simon-hardy @eerhardt you are both correct

@eerhardt is correct that he has the latest 3.5-Beta build in the CLI
The fixes are in 3.5-RC (or the nuget dev branch) and 3.4.3 branch that is ahead of 3.5-Beta as 3.5-Beta was frozen in escrow and 3.4.3 had patches applied.

We are working on approving a merge from 3.5-RC (basically renaming the branch to 3.5-Beta) where at that point there will be a newer build that the CLI can take.

Hopefully this clarifies the state of affairs.

[TheRealPiotrP]

_From @deathrowe on April 19, 2016 19:49_

I'm still hitting this issue with version 1.0.0-rc2-002427. I have nuget version 3.3.0.212 as well. I also noticed that 'dotnet restore' will even try to hit my diabledPackageSources.

[TheRealPiotrP]

_From @rrelyea on April 19, 2016 20:26_

Included with the .NET CLI binaries are some NuGet binaries...
The last build we integrated into .NET CLI was 3.5.0-beta-1178.
That build of NuGet should contain all fixes from our public 3.4.2 release.
Please check your version of NuGet components in the CLI build you have.

[TheRealPiotrP]

_From @deathrowe on April 19, 2016 21:9_

I'm assuming you're talking about any of the NuGet.*.dll files from the /sdk/1.0.0-rc2-002427/ directory? I tried looking at the info for a couple of the files and I don't see any versioning. Is there a command I can run? I'm running on the latest OS X if that makes a difference

[TheRealPiotrP]

_From @rrelyea on April 19, 2016 21:12_

This may be able to tell you the version:
corerun nuget.commandline.xplat.dll --version

[TheRealPiotrP]

_From @deathrowe on April 20, 2016 3:17_

Unfortunately, that command does not work for me. I get: 'Could not get full path: No such file or directory'

[TheRealPiotrP]

_From @patrickjamesbarry on May 4, 2016 14:24_

I am on a Mac, running .NET Command Line Tools (1.0.0-rc2-002659) and NuGet Version: 3.4.3.855. I am running into same Unauthorized issue with dotnet restore. nuget restore works just fine. Hopefully whatever merge needs to be approved, happens soon!

[TheRealPiotrP]

_From @patrickjamesbarry on May 10, 2016 16:35_

On NET Command Line Tools (1.0.0-preview1-002700), and this is still an issue. Can we get an update on this issue?

[TheRealPiotrP]

_From @yishaigalatzer on May 10, 2016 16:45_

Everything is already merged. So we will need more info from you, like a fiddler trace, exact version of Nexus and any particular instruction you can provide us to try and repro this in details.

CC @rrelyea

[TheRealPiotrP]

_From @patrickjamesbarry on May 10, 2016 18:23_

Artifactory (Cloud subscription)
Mac 10.10.5
NET Command Line Tools (1.0.0-preview1-002700)
Mono JIT compiler version 4.2.3

I think I found the problem. The auth header is not getting set correctly.
Authorization: Basic Og==

I have confirmed that my credentials are set correctly and even tried 2 different ways. Encrypted vs Clear text. Everything works when I run nuget restore, which uses the same config file.

<packageSourceCredentials>
    <Artifactory>
        <add key="Username" value="username" />
        <add key="Password" value="encrypted-pwd" />
    </Artifactory>
</packageSourceCredentials>
<packageSourceCredentials>
    <Artifactory>
        <add key="Username" value="username" />
        <add key="ClearTextPassword" value="pwd" />
    </Artifactory>
</packageSourceCredentials>

[TheRealPiotrP]

_From @alpaix on May 10, 2016 19:21_

@patrickjamesbarry Encrypted passwords are not supported on CoreCLR due to missing System.Security.Cryptography assembly. Can you try with clear text password section only?

[TheRealPiotrP]

_From @patrickjamesbarry on May 10, 2016 19:27_

I tried both (separately) with neither working.

[TheRealPiotrP]

_From @yishaigalatzer on May 10, 2016 23:45_

We have a proper repro, thanks!

@spadapet and @alpaix are working on a fix.

CC @rrelyea

[TheRealPiotrP]

_From @mburumaxwell on June 25, 2016 12:31_

I made a script as a workaround for automated builds in case anyone needs a quick workaround.
See https://maxwellweru.com/using-authenticated-nuget-feeds-with-dot-net-rc2-on-vsts/

[TheRealPiotrP]

_From @nwoolls on February 13, 2017 16:9_

I hope this is the correct thread - there seem to be several threads / issues tracking this.

We are trying to automate builds for projects using the .NET Core tooling that is compatible with project.json and allows for private NuGet packages to be restored via dotnet restore using nuget.config. I am running into the same issue as this thread using 1.0.0-preview2-003156. The command nuget list can read the packages just fine and I see:

Using credentials from config. UserName: XYZ

However, attempting to use dotnet restore results in the same 401 in this thread:

log  : Response status code does not indicate success: 401 (Unauthorized).

I see references to this being fixed and merged, but the fixed CLI tooling I have tried seems to only use the new csproj project format.

Thanks in advance for any direction on this. Note this is not using VSTS - just a private NuGet server.

[TheRealPiotrP]

_From @ericstj on February 14, 2017 1:0_

I don't think this should have been closed. GitHub closed it on my behalf when I merely forked NuGet.Client and merged its dev branch into my private fork...

[TheRealPiotrP]

_From @rrelyea on February 14, 2017 19:46_

The nuget fix is not available for a dotnet.exe that supports xproj/project.json.
There is a workaround mentioned above if you need to stay with Project.json.

NuGet.exe v3.5.0 has this fix, but only runs on windows (and sometimes on mono).

NuGet v4.0.0-rc4 and VS 2017-rc is available today with this fix, but it requires you to migrate to msbuild/csproj from xproj/project.json.

[TheRealPiotrP]

_From @nwoolls on February 14, 2017 20:1_

@rrelyea what workaround are you referring to? I only see workarounds specific to VSTS (using a token) but nothing for a private NuGet server.

Are folks using project.json dead in the water with private NuGet servers + auth?

[TheRealPiotrP]

_From @rrelyea on February 14, 2017 21:15_

I was referring to workaround from @mburumaxwell where he started with: "I made a script as a workaround for automated builds in case anyone needs a quick workaround."
Perhaps it was not the right workaround.

Are you able to use NuGet.exe v3.5.0-rtm in your scenario?

[TheRealPiotrP]

_From @ferrancg on February 21, 2017 20:37_

I am also experiencing a similar issue when using dotnet (1.0.0-preview2-003121) against VSTS Feeds, but only intermittently. After exploring a bit on this issue, here is what I found:

1. The error sometime is shown as 403, sometimes as " Password decryption is not supported on .NET Core for this platform."
2. The dotnet restore can actually access the VSTS Feed with the credential, because it works most of the time on both VSTS and local (I did clean the cache before the restore)
3. Not only dotnet restore, even Nuget.exe restore also experience the same error intermittently.
4. The issue does not occur when you use Nuget + Cred Provider (This is our workaround right now)

[TheRealPiotrP]

_From @blackdwarf on February 21, 2017 21:43_

@rrelyea I guess that this issue should be moved to Nuget/home, right?

[TheRealPiotrP]

_From @gtokenThinhnguyen on February 22, 2017 3:50_

I am also having same issues when I am using dotnet (1.0.0-rc4-004771) on ubuntu Ubuntu 16.04.
I already set the api key in Nuget.Config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="private_nuget_source" value="http://nexus.<domain>/repository/nuget-hosted/" />
  </packageSources>
  <disabledPackageSources>
    <add key="Microsoft and .NET" value="true" />
  </disabledPackageSources>
  <apikeys>
    <add key="http://nexus.<domain>/repository/nuget-hosted/" value="<private_key>" />
  </apikeys>
  <packageRestore>
    <add key="enabled" value="True" />
    <add key="automatic" value="True" />
  </packageRestore>
  <bindingRedirects>
    <add key="skip" value="False" />
  </bindingRedirects>
</configuration>

dotnet restore --configfile=NuGet.config
Retrying 'FindPackagesByIdAsyncCore' for source 'http://nexus.<domain>/repository/nuget-hosted/FindPackagesById()?id='AspNetCore.DataProtection.Aws.S3''.
Response status code does not indicate success: 401 (Unauthorized).

[TheRealPiotrP]

_From @nwoolls on February 22, 2017 3:58_

@gtokenThinhnguyen only options we found:

• Build on Windows using NuGet.exe 3.5 and nuget restore
• Or, build on *nix using Mono and NuGet 3.5 (nuget update -self) and nuget restore
• Or, put your private NuGet server inside a VPN (if under your control)
• Or, upgrade your project(s) to the recently released csproj based tooling - @gtokenThinhnguyen indicates this may not resolve the issue

[TheRealPiotrP]

_From @gtokenThinhnguyen on February 22, 2017 4:10_

Thank you @nwoolls for a quick response. I already upgraded my project using csproj and I can restore the packages if my nuget repository is set public (without authentication). I guess that "dotnet restore" cannot get the credentials from NuGet.Config.

[TheRealPiotrP]

_From @nwoolls on February 22, 2017 4:12_

@gtokenThinhnguyen interesting (and unfortunate if true) - that last option was an assumption on my part based on the feedback of others. We have yet to do the upgrade from project.json for these particular projects.

[TheRealPiotrP]

_From @gtokenThinhnguyen on February 22, 2017 4:21_

@nwoolls yah I am looking for why "dotnet restore" cannot retrieve my credentials from NuGet.config :(

[TheRealPiotrP]

_From @nwoolls on February 22, 2017 4:27_

@gtokenThinhnguyen did you try the other options? Not sure if Mono is an option for you and your build tooling. But using Mono along with nuget restore - not dotnet restore - worked here as long as NuGet was updated using e.g. nuget update -self.

[gtokenThinhnguyen]

Hi, @nwoolls if we use nuget restore we have to config csproj back to project.json right? May be I will put my nuget repo to the VPN currently.

[emgarten]

@gtokenThinhnguyen use nuget.exe 4.0.0 from http://dist.nuget.org/index.html for PackageReference support.

[gtokenThinhnguyen]

hi @emgarten. I am using nuget (4.0.0.2275) to restore to packages. However it said that "The folder does not contain an msbuild solution or packages.config file to restore." I guess that nuget 4.0 haven't supported csproj yet?

[emgarten]

I guess that nuget 4.0 haven't supported csproj yet?

It does, but with slightly different inputs. nuget.exe covers more inputs and requires the path to the csproj to restore a single project.

Example: nuget.exe restore project.csproj

[gtokenThinhnguyen]

I tried that by mono nuget.exe restore myProject.csproj it just says that "MSBuild auto-detection: using msbuild version '14.0' from '/usr/lib/mono/xbuild/14.0/bin'." and stop there.

[emgarten]

@zhili1208 what does @gtokenThinhnguyen need to add to get this to work on mono?

[zhili1208]

@gtokenThinhnguyen looks like you tried this on linux, since mono doesn't have msbuild on linux now, it doesn't work for now.

[gtokenThinhnguyen]

@zhili1208 yes, I tried this on Ubuntu. It's ok I will wait for `dotnet restore to read credentials or apis from NuGet.config feature then. Thanks you guys for answers.

[zhili1208]

@gtokenThinhnguyen Actually dotnet restore can read credentials, the issue is you can't add credentials by using mono, if you use "mono nuget.exe source add", it will add credetnails to .config/NuGet/NuGet.config, dotnet restore read credentials from .nuget/NuGet/NuGet.config, you can just add your credential to .nuget/NuGet/NuGet.config or use mono like this "mono nuget.exe source add [your source and credetnial] -configFile ./nuget/NuGet/NuGet.config. it should work on linux

[zhili1208]

I think this is a dupe of https://github.com/NuGet/Home/issues/4095

[nwoolls]

@zhili1208 I do not believe so. I reproduced all of this without Mono. Mono is not involved in the issue I am seeing at all.

The only way Mono is involved is that you can use the newer nuget CLI from Mono to work around the issue, rather than using the dotnet tooling. But that requires you to use Mono for builds instead of .NET Core.

_Edit: see https://github.com/NuGet/Home/issues/4668#issuecomment-281570017_

[zhili1208]

@nwoolls you mentioned nuget CLI from mono can work around your issue, Did you use -configFile flag with mono? what's the path of your nuget.config which contains credential?

[nwoolls]

@zhili1208 I was using the nuget CLI installed by Mono on OS X - I was not using mono NuGet.exe. Installing Mono installs a nuget CLI and I updated that using nuget update -self. Afterward I was able to use nuget restore with a project.json project. This was with config in ~/.nuget not ~/.config.

> which nuget
/Library/Frameworks/Mono.framework/Versions/Current/Commands/nuget

[derwasp]

Guys, should I expect this to be fixed anytime soon? Is there a known workaround for this on Linux?

[emgarten]

Thanks for reporting this issue. We have not been able to reproduce this issue. If you are still able to reproduce this with the latest NuGet version, please provide additional steps.

[nwoolls]

In our case this ended up being related to config in IIS. The site hosting NuGet.Server was configured with both Basic Auth _and_ Windows Auth enabled. This worked fine when accessing the NuGet.Server homepage and feeds via a web browser, but causes the dotnet CLI to fail restoring packages:

  Restoring packages for /Users/nwoolls/src/tmp/nuget-basic-auth/nuget-basic-auth.csproj...
  Retrying 'FindPackagesByIdAsyncCore' for source 'http://192.168.0.44/nugetserver/nuget/FindPackagesById()?id='nuget-etwrbw''.
  Response status code does not indicate success: 401 (Unauthorized).
  Retrying 'FindPackagesByIdAsyncCore' for source 'http://192.168.0.44/nugetserver/nuget/FindPackagesById()?id='nuget-etwrbw''.
  Response status code does not indicate success: 401 (Unauthorized).
/usr/local/share/dotnet/sdk/2.0.2/NuGet.targets(102,5): error : Failed to retrieve information about 'nuget-etwrbw' from remote source 'http://192.168.0.44/nugetserver/nuget/FindPackagesById()?id='nuget-etwrbw''. [/Users/nwoolls/src/tmp/nuget-basic-auth/nuget-basic-auth.csproj]
/usr/local/share/dotnet/sdk/2.0.2/NuGet.targets(102,5): error :   Response status code does not indicate success: 401 (Unauthorized). [/Users/nwoolls/src/tmp/nuget-basic-auth/nuget-basic-auth.csproj]

Disabling Windows Auth for the NuGet.Server website allows the dotnet CLI tooling to interact with NuGet as expected.

[derwasp]

@emgarten do you have a case for the issue with windows auth? Because it looks like we have the same problem as @nwoolls . We are using ProGet and windows auth to allow for permission distribution among developers.

[derwasp]

Workaround for windows boxes for windows auth when the machine is not in the domain:
In your buildscripts add this:
cmdkey /add:address-of-the-nuget-server.under.win.auth /user:{domain}\username /pass:{password}