Home: Docker dotnet restore on VSTS fails to authenticate.

[livarcocc]

_From @SGStino on May 4, 2018 8:45_

Infrastructure:

• vsts-agent running in docker
• vsts agent running on windows machine
• tfs 2018 on-premise

Steps to reproduce

• Create a Nuget feed on the TFS server.
• Create ASP.NET Core project, reference one nuget package from Internal feed
• Build on Windows based agent
• Build on Docker image

Expected behavior

Both builds should succeed by using the OAuth token from VSTS?

Actual behavior

Docker based build fails: 401 Unauthorized.

NuGet.Protocol.Core.Types.FatalProtocolException: Unable to load the service index for source https://<tfsserver>/tfs/DefaultCollection/_packaging/<packagesource>/nuget/v3/index.json. ---> System.Net.Http.HttpRequestException: Response status code does not indicate success: 401 (Unauthorized).
at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
at NuGet.Protocol.HttpSource.<>c__DisplayClass12_0`1.<<GetAsync>b__0>d.MoveNext()

The difference between the windows and the linux machine is that the windows machine runs as a service user that is known in TFS, and as such is authenticated via NTLM?

And the linux container is outside of the domain, and as such, not authenticated
However, specifying a PAT as "Credentials for feeds outside this account/collection" doesn't seem to help:

I'm guessing this is becuase it is not "Outside of this account/collection" and as such doesn't use the credentials?

Environment data

dotnet --info output: (official docker image)
.NET Command Line Tools (2.1.101)

Product Information:
Version: 2.1.101
Commit SHA-1 hash: 6c22303bf0

Runtime Environment:
OS Name: ubuntu
OS Version: 16.04
OS Platform: Linux
RID: ubuntu.16.04-x64
Base Path: /usr/share/dotnet/sdk/2.1.101/

Microsoft .NET Core Shared Framework Host

Version : 2.0.6
Build : 74b1c703813c8910df5b96f304b0f2b78cdf194d

_Copied from original issue: dotnet/cli#9196_

[mishra14]

cc @nkolev92 who is doing crossplat auth work.

[nkolev92]

@mishra14
There is no cross-plat support out yet though :D

This has to do with the VSTS tasks.
Not aware what's being done here.

@alexmullans @keithrob for help

[infin8x]

Does the URL in the nuget.config exactly match the URL you configured in the "TFS-Nuget" service endpoint? The task should be looking for a match between that line in your nuget.config and the service endpoint to correctly inject credentials.

[keithrob]

Hey @livarcocc I would like to take a look at the build logs. Will you send them to kerobert AT microsoft.com.

[livarcocc]

@keithrob I am not the original reporter of this issue, I just moved it to this repo. It was originally filled by @SGStino

[SGStino]

@keithrob logs are on their way!

[mishra14]

@SGStino @nkolev92 🔔

[nkolev92]

@SGStino
Did you discuss this with @keithrob?

Anything required from NuGet specifically here?

Can this be closed?

[SGStino]

Haven't gotten information from him yet aside that they'd look into it for the next release

[matrap]

I have also this problem. I got "Unauthorized 401" using PAT and NET Core

Infrastructure

• TFS 2017 Update 2 (Version 15.117.26714.0)
• Docker version 18.03.1-ce, build 9ee9f40

Steps to reproduce:

1. Get Personal Access Token (PAT) from Security tab in TFS

2. Use feed from TFS using PAT to authentication.
   NuGet.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nugetRepo" value="https://{address to nuget in tfs}/nuget/v3/index.json. " protocolVersion="3"/>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />   
  </packageSources>
  <packageSourceCredentials>
      <nugetRepo>
        <add key="Username" value="{MyLogin}" />
        <add key="ClearTextPassword" value="{PAT}" />
    </nugetRepo>
  </packageSourceCredentials>
</configuration>

1. Use Dockerfile:

FROM microsoft/dotnet:2.0-sdk AS build-env
ADD some-root-ca.crt /usr/local/share/ca-certificates
RUN update-ca-certificates
WORKDIR /app
COPY . ./

WORKDIR /app
RUN dotnet restore ./Module/*.csproj --configfile NuGet.config
COPY . ./
WORKDIR /app/Module
RUN dotnet publish -c Release -o out

FROM microsoft/dotnet:2.0-runtime
WORKDIR /app
COPY --from=build-env /app/Module/out ./
RUN useradd -ms /bin/bash moduleuser
USER moduleuser
ENTRYPOINT ["dotnet", "Module.dll"]

1. Build docker image on .amd64

Expected behavior:

Dotnet use feed from TFS to restore dependencies and successfully build the image

Actual behavior:

Step 8/17 : RUN dotnet restore ./Module/*.csproj --configfile NuGet.config
 ---> Running in 0f37c6dbbaba
  Restoring packages for /app/Module/Module.csproj...

/usr/share/dotnet/sdk/2.1.202/NuGet.targets(114,5): error : Unable to load the service index for source https://{address to nuget in tfs}/nuget/v3/index.json. [/app/Module/Module.csproj]

/usr/share/dotnet/sdk/2.1.202/NuGet.targets(114,5): error :   Response status code does not indicate success: 401 (Unauthorized). [/app/Module/Module.csproj]

The command '/bin/sh -c dotnet restore ./Module/*.csproj --configfile NuGet.config' returned a non-zero code: 1

[nkolev92]

@matrap

What you're articulating might be duplicates of https://github.com/NuGet/Home/issues/2393. and https://github.com/NuGet/Home/issues/5286 /cc @jmyersmsft

@SGStino @matrap
Your problems with the tasks will probably be fixed by the introduction of https://github.com/NuGet/Home/issues/6486

[infin8x]

Sorry for the lag, catching up from vacation. @keithrob do you know if Aldo is taking this scenario into account as part of the #6486 work?

[SGStino]

I've just managed to test this again on a new environment and now I get a different authentication exception, not sure if it's related or not:

2018-08-22T08:00:25.7078924Z      1>/usr/share/dotnet/sdk/2.1.302/NuGet.targets(114,5): error : Unable to load the service index for source https://<tfs-server>/tfs/DefaultCollection/_packaging/RadiusNuget/nuget/v3/index.json. [/vsts/agent/_work/1/s/DockerAppTest.Service/DockerAppTest.Service.csproj]
2018-08-22T08:00:25.7097586Z /usr/share/dotnet/sdk/2.1.302/NuGet.targets(114,5): error :   GSSAPI operation failed with error - An invalid status code was supplied (Configuration file does not specify default realm). [/vsts/agent/_work/1/s/DockerAppTest.Service/DockerAppTest.Service.csproj]
2018-08-22T08:00:25.7124345Z          NuGet.Protocol.Core.Types.FatalProtocolException: Unable to load the service index for source https://<tfs-server>/tfs/DefaultCollection/_packaging/RadiusNuget/nuget/v3/index.json. ---> System.ComponentModel.Win32Exception: GSSAPI operation failed with error - An invalid status code was supplied (Configuration file does not specify default realm).
2018-08-22T08:00:25.7145752Z             at System.Net.Security.NegotiateStreamPal.AcquireCredentialsHandle(String package, Boolean isServer, NetworkCredential credential)
2018-08-22T08:00:25.7193817Z             at System.Net.NTAuthentication.Initialize(Boolean isServer, String package, NetworkCredential credential, String spn, ContextFlagsPal requestedContextFlags, ChannelBinding channelBinding)
2018-08-22T08:00:25.7209301Z             at System.Net.Http.AuthenticationHelper.SendWithNtAuthAsync(HttpRequestMessage request, Uri authUri, ICredentials credentials, Boolean isProxyAuth, HttpConnection connection, CancellationToken cancellationToken)
2018-08-22T08:00:25.7224491Z             at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
2018-08-22T08:00:25.7240991Z             at System.Net.Http.AuthenticationHelper.SendWithAuthAsync(HttpRequestMessage request, Uri authUri, ICredentials credentials, Boolean preAuthenticate, Boolean isProxyAuth, Boolean doRequestAuth, HttpConnectionPool pool, CancellationToken cancellationToken)
2018-08-22T08:00:25.7256109Z             at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
2018-08-22T08:00:25.7271188Z             at System.Net.Http.DecompressionHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
2018-08-22T08:00:25.7283650Z             at NuGet.Protocol.ServerWarningLogHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
2018-08-22T08:00:25.7298688Z             at NuGet.Protocol.HttpSourceAuthenticationHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
2018-08-22T08:00:25.7313473Z             at System.Net.Http.HttpClient.FinishSendAsyncUnbuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
2018-08-22T08:00:25.7327181Z             at NuGet.Protocol.TimeoutUtility.StartWithTimeout[T](Func`2 getTask, TimeSpan timeout, String timeoutMessage, CancellationToken token)
2018-08-22T08:00:25.7349627Z             at NuGet.Protocol.HttpRetryHandler.SendAsync(HttpRetryHandlerRequest request, ILogger log, CancellationToken cancellationToken)
2018-08-22T08:00:25.7366205Z             at NuGet.Protocol.HttpSource.GetThrottledResponse(Func`1 requestFactory, TimeSpan requestTimeout, TimeSpan downloadTimeout, Int32 maxTries, Guid sessionId, ILogger log, CancellationToken cancellationToken)
2018-08-22T08:00:25.7380151Z             at NuGet.Protocol.HttpSource.<>c__DisplayClass14_0`1.<<GetAsync>b__0>d.MoveNext()
2018-08-22T08:00:25.7428279Z          --- End of stack trace from previous location where exception was thrown ---
2018-08-22T08:00:25.7444882Z             at NuGet.Common.ConcurrencyUtilities.ExecuteWithFileLockedAsync[T](String filePath, Func`2 action, CancellationToken token)
2018-08-22T08:00:25.7458011Z             at NuGet.Protocol.HttpSource.GetAsync[T](HttpSourceCachedRequest request, Func`2 processAsync, ILogger log, CancellationToken token)
2018-08-22T08:00:25.7470457Z             at NuGet.Protocol.ServiceIndexResourceV3Provider.GetServiceIndexResourceV3(SourceRepository source, DateTime utcNow, ILogger log, CancellationToken token)
2018-08-22T08:00:25.7487012Z             --- End of inner exception stack trace ---
2018-08-22T08:00:25.7502805Z             at NuGet.Protocol.ServiceIndexResourceV3Provider.GetServiceIndexResourceV3(SourceRepository source, DateTime utcNow, ILogger log, CancellationToken token)
2018-08-22T08:00:25.7517538Z             at NuGet.Protocol.ServiceIndexResourceV3Provider.TryCreate(SourceRepository source, CancellationToken token)
2018-08-22T08:00:25.7530503Z             at NuGet.Protocol.Core.Types.SourceRepository.GetResourceAsync[T](CancellationToken token)
2018-08-22T08:00:25.7543610Z             at NuGet.Protocol.Core.Types.SourceRepository.GetResourceAsync[T]()
2018-08-22T08:00:25.7556968Z             at NuGet.Protocol.HttpFileSystemBasedFindPackageByIdResourceProvider.TryCreate(SourceRepository sourceRepository, CancellationToken token)
2018-08-22T08:00:25.7569322Z             at NuGet.Protocol.Core.Types.SourceRepository.GetResourceAsync[T](CancellationToken token)
2018-08-22T08:00:25.7582811Z             at NuGet.Protocol.Core.Types.SourceRepository.GetResourceAsync[T]()
2018-08-22T08:00:25.7595762Z             at NuGet.Commands.SourceRepositoryDependencyProvider.EnsureResource()
2018-08-22T08:00:25.7612796Z             at NuGet.Commands.SourceRepositoryDependencyProvider.FindLibraryCoreAsync(LibraryRange libraryRange, NuGetFramework targetFramework, SourceCacheContext cacheContext, ILogger logger, CancellationToken cancellationToken)
2018-08-22T08:00:25.7627607Z             at NuGet.Commands.SourceRepositoryDependencyProvider.<>c__DisplayClass18_0.<<FindLibraryAsync>b__0>d.MoveNext()
2018-08-22T08:00:25.7642760Z          --- End of stack trace from previous location where exception was thrown ---
2018-08-22T08:00:25.7659178Z             at NuGet.Commands.SourceRepositoryDependencyProvider.FindLibraryAsync(LibraryRange libraryRange, NuGetFramework targetFramework, SourceCacheContext cacheContext, ILogger logger, CancellationToken cancellationToken)
2018-08-22T08:00:25.7672721Z             at NuGet.DependencyResolver.ResolverUtility.<>c__DisplayClass7_1.<<FindLibraryFromSourcesAsync>b__0>d.MoveNext()
2018-08-22T08:00:25.7687808Z          --- End of stack trace from previous location where exception was thrown ---
2018-08-22T08:00:25.7703835Z             at NuGet.DependencyResolver.ResolverUtility.FindLibraryFromSourcesAsync(LibraryRange libraryRange, IEnumerable`1 providers, Func`2 action)
2018-08-22T08:00:25.7716675Z             at NuGet.DependencyResolver.ResolverUtility.FindLibraryByVersionAsync(LibraryRange libraryRange, NuGetFramework framework, IEnumerable`1 providers, SourceCacheContext cacheContext, ILogger logger, CancellationToken token)
2018-08-22T08:00:25.7731217Z             at NuGet.DependencyResolver.ResolverUtility.FindLibraryMatchAsync(LibraryRange libraryRange, NuGetFramework framework, GraphEdge`1 outerEdge, IEnumerable`1 remoteProviders, IEnumerable`1 localProviders, IEnumerable`1 projectProviders, SourceCacheContext cacheContext, ILogger logger, CancellationToken cancellationToken)
2018-08-22T08:00:25.7743837Z             at NuGet.DependencyResolver.ResolverUtility.FindLibraryEntryAsync(LibraryRange libraryRange, NuGetFramework framework, GraphEdge`1 outerEdge, RemoteWalkContext context, CancellationToken cancellationToken)
2018-08-22T08:00:25.7755882Z             at NuGet.DependencyResolver.RemoteDependencyWalker.CreateGraphNode(LibraryRange libraryRange, NuGetFramework framework, String runtimeName, RuntimeGraph runtimeGraph, Func`2 predicate, GraphEdge`1 outerEdge)
2018-08-22T08:00:25.7767986Z             at NuGet.DependencyResolver.RemoteDependencyWalker.CreateGraphNode(LibraryRange libraryRange, NuGetFramework framework, String runtimeName, RuntimeGraph runtimeGraph, Func`2 predicate, GraphEdge`1 outerEdge)
2018-08-22T08:00:25.7784328Z             at NuGet.Commands.ProjectRestoreCommand.WalkDependenciesAsync(LibraryRange projectRange, NuGetFramework framework, String runtimeIdentifier, RuntimeGraph runtimeGraph, RemoteDependencyWalker walker, RemoteWalkContext context, CancellationToken token)
2018-08-22T08:00:25.7798640Z             at NuGet.Commands.ProjectRestoreCommand.TryRestoreAsync(LibraryRange projectRange, IEnumerable`1 frameworkRuntimePairs, NuGetv3LocalRepository userPackageFolder, IReadOnlyList`1 fallbackPackageFolders, RemoteDependencyWalker remoteWalker, RemoteWalkContext context, Boolean forceRuntimeGraphCreation, CancellationToken token)
2018-08-22T08:00:25.7812258Z             at NuGet.Commands.RestoreCommand.ExecuteRestoreAsync(NuGetv3LocalRepository userPackageFolder, IReadOnlyList`1 fallbackPackageFolders, RemoteWalkContext context, CancellationToken token)
2018-08-22T08:00:25.7825747Z             at NuGet.Commands.RestoreCommand.ExecuteAsync(CancellationToken token)
2018-08-22T08:00:25.7839524Z             at NuGet.Commands.RestoreRunner.ExecuteAsync(RestoreSummaryRequest summaryRequest, CancellationToken token)
2018-08-22T08:00:25.7852217Z             at NuGet.Commands.RestoreRunner.ExecuteAndCommitAsync(RestoreSummaryRequest summaryRequest, CancellationToken token)
2018-08-22T08:00:25.7864356Z             at NuGet.Commands.RestoreRunner.CompleteTaskAsync(List`1 restoreTasks)
2018-08-22T08:00:25.7878055Z             at NuGet.Commands.RestoreRunner.RunAsync(IEnumerable`1 restoreRequests, RestoreArgs restoreContext, CancellationToken token)
2018-08-22T08:00:25.7891306Z             at NuGet.Commands.RestoreRunner.RunAsync(RestoreArgs restoreContext, CancellationToken token)
2018-08-22T08:00:25.7903828Z             at NuGet.Build.Tasks.RestoreTask.ExecuteAsync(ILogger log)

[nkolev92]

@SGStino
That could be this one:
https://github.com/dotnet/corefx/issues/27872

Can try you setting DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0 and retrying again.

[sabbadino]

in docker linux ubuntu ..
FROM microsoft/dotnet:2.1.401-sdk AS build ..

since I'm having the same error , I tried this

COPY .nuget/nuget.config ./nuget.config
ENV DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0
RUN dotnet restore -nowarn:msb3202,nu1503
COPY . .

nuget.config file

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <solution>
    <add key="disableSourceControlIntegration" value="true" />
  </solution>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
    <add key="ems" value="https://..../v3/index.json" />
  </packageSources>
  <activePackageSource>
    <add value="(Aggregate source)" key="All" />
  </activePackageSource>
  <packageSourceCredentials>
    <ems>
      <add key="Username" value="any-value" />
      <add key="ClearTextPassword" value="my PAT" />
    </ems>
  </packageSourceCredentials>
</configuration>

If you do so, the result is that you get the "original error" : (
Response status code does not indicate success: 401 (Unauthorized)

The feed is a TFS feed

[maartenba]

Smells similar to https://github.com/NuGet/Home/issues/5286, seeing the same using the NuGet SDK directly with a TFS server on Mac OS X or Linux

[sabbadino]

@maartenba .. maybe .. I must use dotnetcore restore , since I'm on a linux docker image without mono : nuget.exe does not work in linux unless you install mono & run nuget.exe under mono ..
Reading around google it seems that access to TFS private feeds can be done using MONO nuget.exe (providing a nuget.config with credentials (PAT token).
And a collegue of mine said that he had it working (with a little of work to pick up the "correct" linux image and installing mono on it with apt).

[nkolev92]

@sabbadino If the problem you are facing is #5286 as mentioned a few times, then nuget.exe on mono with a nuget.config and a PAT token won't fix it.
The only way to fix it currently is to use a credential provider.

The reason why a credential provider is the only solution can be found in the description of the fix https://github.com/NuGet/NuGet.Client/pull/2297

For dotnet.exe we have added support for cross platform plugin credential providers in https://github.com/NuGet/Home/issues/6486, and the credential providers should follow from the respective services (VSTS will have it available by EOY).

[sabbadino]

Hi,
first of all .. I'm working to get authentication work on a vsts feed, not other kind of feeds.

I had the error
__Operation failed with error - An invalid status code was supplied (Configuration file does not specify default realm)__ (which seems ntlm / kerberos related, but It's just a guess).
while doing a dotnet restore , not nuget.exe restore

It's not clear to me when you say :
_VSTS will have it available by EOY_

Do you mean I won't need to use a PAT token anymore ?

Do I need to wait for an update of dotnet restore or only of vsts , or both ? (not clear to me if cross platform plugin credential and vstst pat token are connected togheter somehow, and if they are .. how ? )

thank you

---

Using FROM microsoft/dotnet:2.1.401-sdk AS build ..
and MONO MONO_VERSION 5.4.1.6
and nuget.exe :
RUN curl -o /usr/local/bin/nuget.exe https://dist.nuget.org/win-x86-commandline/v4.8.1/nuget.exe

and providing a nuget.config like this (pat is replaced on the fly in order not to store it in plain text in the git repo)

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <solution>
    <add key="disableSourceControlIntegration" value="true" />
  </solution>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
    <add key="ems" value="https:/........." />
  </packageSources>
  <activePackageSource>
    <add value="(Aggregate source)" key="All" /> 
  </activePackageSource>
  <packageSourceCredentials>
    <ems>
      <add key="Username" value="any-value" />
      <add key="ClearTextPassword" value="__syspat__" />
    </ems>
  </packageSourceCredentials>
</configuration>

I had this command run with success (against a vsts private feed):
RUN mono /usr/local/bin/nuget.exe restore ./ -verbosity n -configfile .nuget/nuget.config

[phillip-haydon]

So the gist of this is that dotnet does not support private/authenticated feeds for VSTS or TeamCity? So I'm crippled now cos I cannot build a AWS Lambda since I cannot specify a specific version of the nuget.exe to use for restoring to resolve this bug?

[nkolev92]

@sabbadino

Operation failed with error - An invalid status code was supplied (Configuration file does not specify default realm) (which seems ntlm / kerberos related, but It's just a guess).

You are correct, that does look like negotiate goo.
This might be related: https://github.com/dotnet/corefx/issues/30203.

In your scenario, roughly the following happens:

1. You specify credentials in your nuget.config
2. The thing here is that the credentials you are providing are usually not NTLM/negotiate but rather basic auth credentials.
3. When connecting to the feed, the authentication stack discusses authentication strategies.
4. NTLM/negotiate is attempted before basic if the server supports it.
5. Whenever asked for credentials, the supplied credentials are provided.
6. Potentially this fails because the credentials are invalid or some runtime restrictions (like .NET Core not playing with NTLM/negotiate as well as .NET framework)

With the work done in https://github.com/NuGet/NuGet.Client/pull/2297, you would be able to pass credentials and force using them for basic auth only and that'd be more likely to succeed and avoid any potential NTLM/corefx issues. In other words, you are saying, I don't have ntlm creds, use my basic creds to authenticate.

This is coming no earlier 5.0 version of NuGet, and 3.x version of dotnet.exe.

With a credential provider plugin, you can achieve the same thing. With the added support of plugins in dotnet.exe this scenario should be improved. The plugins support in dotnet.exe is already available per #6486. VSTS should release their own credential provider very soon.

Hope this makes sense.

@phillip-haydon

No, dotnet.exe has always had limited support for private feeds. Various links to #6486 and this issue describe that in further detail.

SDK versions earlier than 2.1.400 only has supported for authentication with clearTextPasswords in NuGet.config.
https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file#packagesourcecredentials
The VSTS page also suggests the same thing. https://docs.microsoft.com/en-us/azure/devops/artifacts/nuget/dotnet-exe?view=vsts

Starting with 2.1.400, dotnet.exe supports Credential plugins https://github.com/NuGet/Home/issues/6486, similar to nuget.exe. This would allow you to do authentication on your CI without risking accidentally exposing your PAT to an unknown party.

Related https://github.com/NuGet/Home/issues/5881

[infin8x]

The VSTS Credential Provider can be acquired here: https://github.com/Microsoft/artifacts-credprovider#readme.

[nkolev92]

@sabbadino @phillip-haydon
At your convenience, please try out the credential provider linked by @alexmullans with the appropriate dotnet.exe.

[keithrob]

@sabbadino and @phillip-haydon ,
To make the artifacts-credential provider work with a container you will need to do the following:

1. Assuming you're using a *nix container
2. Compose a container with the netcore version of the plugin as described here
3. You will need to provide creds for each source in your nuget.config via an environment variable (i.e. docker run -e VSS_NUGET_EXTERNAL_FEED_ENDPOINTS=$JSON_GOES_HERE

You do not need mono and you don't need nuget for this. You do; however, need at least dotnet SDK 2.1.400 for this. dotnet will look for the credential provider in $HOME.nugetplugins, call it for each source in your nuget.config, and the credential provider will return credentials from your JSON environment variable.

[sabbadino]

Thanks, will it work with against an premise TFS 2017 as well ?

[nkolev92]

Please note the following problem when dealing with dotnet 2.1.400 and the plugin on docker.

https://github.com/NuGet/Home/issues/7223

The mentioned issue will be fixed in 2.1.500/2.2.100.

[keithrob]

@sabbadino ,
It should.

[lnaie]

tested it with azure devops and it works.
it would be nice, though, if dotnet restore (https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-restore?tabs=netcore2x) would have params to pass the PAT from the build definition variables.

[fabioimpe]

@sabbadino and @phillip-haydon ,
To make the artifacts-credential provider work with a container you will need to do the following:

1. Assuming you're using a *nix container
2. Compose a container with the netcore version of the plugin as described here
3. You will need to provide creds for each source in your nuget.config via an environment variable (i.e. docker run -e VSS_NUGET_EXTERNAL_FEED_ENDPOINTS=$JSON_GOES_HERE

You do not need mono and you don't need nuget for this. You do; however, need at least dotnet SDK 2.1.400 for this. dotnet will look for the credential provider in $HOME.nugetplugins, call it for each source in your nuget.config, and the credential provider will return credentials from your JSON environment variable.

I'm trying to restore packages from a private tfs feed (hosted on premise) using the version 2.1.403 without success... using the 2.2 I can successfully restore, but it is still a preview and I am not confident to use it in a production environment... any clue?

[nkolev92]

@fabioimpe
https://github.com/NuGet/Home/issues/7223 maybe?

[nkolev92]

I'm going to close this issue now as fixed, as I believe the credential provider and all the work we have done around has addressed the individual issues.

If you are still facing problems, please upgrade to the latest and greatest nuget.exe/dotnet.exe/VS (even previews) and artifacts provider.

If you still have problems then, please raise another issue clearly explaining your scenario.

Thanks!

[fabioimpe]

I'm going to close this issue now as fixed, as I believe the credential provider and all the work we have done around has addressed the individual issues.

If you are still facing problems, please upgrade to the latest and greatest nuget.exe/dotnet.exe/VS (even previews) and artifacts provider.

If you still have problems then, please raise another issue clearly explaining your scenario.

Thanks!

Excuse me, but why should I open another issue to report the same error as the above one?
The comunicate says that the issue is resolved starting from version 2.1.400, well, using the 2.1.403 the issue is still there, even with the same exact error message. Using the 2.2.100-preview3, with the same Dockerfile everything works as expected, so I should suppose that the issue is not an "individual issue". Since my containers run in a production environment I am not confident at all to use a preview version of the base image.
In my opinion this issue is not closed at all.

[phillip-haydon]

Really need to stop automatically adding sources to the global source list. It’s so frustrating and causes so many problems. Even in the preview I still have issues.

[infin8x]

@phillip-haydon can you elaborate? What process is adding sources to your global source list?

[nkolev92]

@fabioimpe
Frequently the comments in an issue stray away from the original problem statement and makes it difficult to keep things in check/track fixes etc.
It's complicated for both the maintainers and the customers.
The original issue talked about lack of support, which has since been addressed.

As far as your specific issue is concerned, does #7223 help at all?
Can you try setting the culture in our container with the stable releases or try using the previews.