2

I need to use the .NET Core build pipeline task with the restore command. Target is to restore the package references (*.nupkg) of a solution. I have two package sources:

  • nuget.org
  • private artifacts feed (MyFeed) on ADS

Some projects in my solution refer the packages from MyFeed and needs to restored on agent before build.

enter image description here


The Error

The task fail when it try to download the packages from my private feed MyFeed: (unfortunately the output is on german so i put the error message into google translator and hope the best)

C:\Program Files\dotnet\sdk\3.1.402\NuGet.targets(128,5): error: Error getting information about "ext.lib.MyPackage" from the remote source "https://MyUrl.de/Collection/_packaging/38df75fe-122d-57f9-af47-de3a09231f5e/nuget/v3/flat2/ext.lib .MyPackage / index.json ".
C:\Program Files\dotnet\sdk\3.1.402\NuGet.targets (128,5): error: No login information is available in the security package. [D:\AzureDevOpsData\Agents\MyAgent\_work\2\s\MySolution.sln]

What I have done?

Use NuGet Task

I try to reproduce that behavior with the NuGet task, but with this task everything works fine. This task has access to my private feed MyFeed. Important: the NuGet task is no alternative for use, we need to use the .NET Core task

Windows Credential Manager

I add my feed to the Package Manager in Visual Studio 2019 on my agent and enter the credentials of my agent user. In result of the an 2 entries added to my Windows Credential Manager.

enter image description here

This change do not solve the issue, the error message is the same.


Edit 1: add Auth to NuGet.Config

I try to add the Auth to my NuGet.Config. This approach has many variables, I try to list all varieties I try.

NuGet.Config Path

The dotnet restore task provides to options for a NuGet config:

enter image description here

  1. Option: I associate with the %APPDATA%\NuGet\NuGet.Config (but I am not sure)
  2. Option: is a NuGet.Config path to your repository

So for all runs I try always BOTH options!

  1. Run: Username with Domain Password (Encrypted) ❌
  2. Run: Username with PAT (ClearTextPassword) ❌
  3. Run: Domain\Username with PAT (ClearTextPassword) ❌
  4. Run: Username with Domain Passwort (ClearTextPassword) ❌
  5. Run: Domain\Username with Domain Passwort (ClearTextPassword) ❌

NuGet.Config structure for all runs

<?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="MyFeed" value="https://MyFeedUrl/nuget/v3/index.json" />
  </packageSources>
  <config>
    <add key="http_proxy" value="http://www-MyProxy.de:3000" />
    <add key="https_proxy" value="http://www-MyProxy.de:3000" />
  </config>
  <packageSourceCredentials>
    <MyFeed>
        <add key="Username" value="$MyRunUser" />
        <add key="ClearTextPassword" value="$MyRunKey" /> <- ClearTextPassword OR Password
        <add key="ValidAuthenticationTypes" value="basic" />
      </MyFeed>
  </packageSourceCredentials>
</configuration>

Temporary NuGet.Config

Doesn't matter what I do, the dotnet task always create and use a temporary NuGet.Config. From the system.deubg = true log I could get:

##[debug]Getting credentials for local feeds
SYSTEMVSSCONNECTION exists true
##[debug]SYSTEMVSSCONNECTION exists true
##[debug]Got auth token
##[debug]externalEndpoints=null
##[debug]Setting up sources
##[debug]selectOrConfig=config
##[debug]nugetConfigPath=D:\AzureDevOpsData\Agents\MyAgent\_work\18\s\MyNuGet.Config
##[debug]check path : D:\AzureDevOpsData\Agents\MyAgent\_work\18\s\MyNuGet.Config
##[debug]nugetConfigPath=D:\AzureDevOpsData\Agents\MyAgent\_work\18\s\MyNuGet.Config
##[debug]Absolute path for pathSegments: D:\AzureDevOpsData\Agents\MyAgent\_work\18\s\MyNuGet.Config = D:\AzureDevOpsData\Agents\MyAgent\_work\18\s\MyNuGet.Config
##[debug]build.sourcesDirectory=D:\AzureDevOpsData\Agents\MyAgent\_work\18\s
##[debug]Absolute path for pathSegments: D:\AzureDevOpsData\Agents\MyAgent\_work\18\s = D:\AzureDevOpsData\Agents\MyAgent\_work\18\s
##[debug]nugetConfigPathpath supplied :true
##[debug]Agent.BuildDirectory=D:\AzureDevOpsData\Agents\MyAgent\_work\18
##[debug]build.buildId=15914
##[debug]Setting auth in the temp nuget.config
"NuGet.config" wird in einer temporären Konfigurationsdatei gespeichert.
##[debug]Getting sources from NuGet.config in this location: D:\AzureDevOpsData\Agents\MyAgent\_work\18\Nuget\tempNuGet_12914.config

Temporary NuGet.Config:

<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3"/>
    
  <add key="feed-MyFeed" value="https://MyAdsUrl.de/MyCollection/_packaging/MyFeed/nuget/v3/index.json"/></packageSources>
  <config>
    <add key="http_proxy" value="http://www-cache.MyProxy.de:3000"/>
    <add key="https_proxy" value="http://www-cache.MyProxy.de:3000"/>
  </config>
  <packageSourceCredentials>
    
  <feed-MyFeed><add key="Username" value="VssSessionToken"/><add key="ClearTextPassword" value="QhbGcsadsasadd... VERY LONG KEY-PA"/></feed-MyFeed></packageSourceCredentials>
</configuration>

From my perspective I can see the temprary Nuget.Config contains my custom proxy and my custom feed, but not my custom authentication.

Does that mean that the dotnet task do not use my custom NuGet.Config?


Meta Information

  • ADS and Agent is self-hosted
  • Version: 17.153.29207.5 (AzureDevOps2019.Update1)
  • Proxy: Yes
Mar Tin
  • 2,132
  • 1
  • 26
  • 46

3 Answers3

2

You can try putting the credentials of your azure artifacts feed in your nuget.config file.

First you need to generate a Personal access token from Azure devops with the Read&Write Packaging scope.

Then you can provide the credentials to the azure feed for your nuget source. See below example:

<configuration>
  <packageSources>
    <add key="AzureArtifactFeedName" value="http://dctfs2019:8080/tfs/Collection/_packaging/AzureArtifactFeedName/nuget/v3/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <AzureArtifactFeedName>
        <add key="Username" value="any" />
        <add key="ClearTextPassword" value="{Personal Access Token}" />
      </AzureArtifactFeedName>
  </packageSourceCredentials>
</configuration>

You can also run below commands to add the feed credential:

sources Add -Name "AzureArtifactFeedName" -Source "http://dctfs2019:8080/tfs/Collection/_packaging/AzureArtifactFeedName/nuget/v3/index.json" -username any -password PersonalAccessToken -ConfigFile path/to/Nuget.config -StorePasswordInClearText

Then the package can be automatically pushed.

Also, you can try to add <add key="ValidAuthenticationTypes" value="basic"/> to the package source credentials to prevent nuget/dotnet from trying to authenticate via NTLM/Windows authentication.

Alina Wang-MSFT
  • 522
  • 3
  • 4
  • Hey Alina, thanks a lot for your answer. I add a new section to my question *Edit 1: add Auth to NuGet.Config*. I would be so happy if you could read it. Unfortunately this approach do not work for me. But I have the adoption that the `dotnet` restore task ignores my custom auth configuration from my `NuGet.Config`. Can you confirm? – Mar Tin Nov 27 '20 at 06:00
  • The `dotnet` task will also use the `VssSessionToken` in the temporary `nuget.config`, when I use a **nuget service connection**. There is no way to prevent the `dotnet` task creating temporary `nuget.config` files and there is no way to but custom authentication in that temporary config. – Mar Tin Nov 27 '20 at 06:09
0

In your pipelines try to add a Nuget Authenticate step first. And make sure you have the persistcredentials set to true (checkout arguments)

michiel Thai
  • 547
  • 5
  • 16
  • Thanks for your reply! The `NuGet Authenticate` task is not part of **Azure DevOps Server 2019**. See [NuGet Authenticate Not Found](https://developercommunity.visualstudio.com/content/problem/950388/nuget-authenticate-not-found.html) for more information. – Mar Tin Nov 25 '20 at 17:04
0

Azure DevOps Server dotnet restore has no access to feed

To resolve this issue, you could use the nuget restore task to restore the packages, and use the dotnet build task with argument --no-restore:

enter image description here

If you still want use dotnet restore instead of nuget restore, you could execute following dotnet command line in the Azure devops server machine:

dotnet nuget add source http://xxxxx/DefaultCollection/_packaging/LeoTestFeed/nuget/v3/index.json -n YourFeedName -u YourUserName -p YourPAT --store-password-in-clear-text

You could check the document dotnet nuget add source for some more details.

Then we could use the dotnet restore successful:

enter image description here

My test result(TFS 2018, Since my TFS2019 server is down for unknown reasons):

enter image description here

Leo Liu
  • 71,098
  • 10
  • 114
  • 135
  • Ola Leo, thanks for your response. The `nuget restore` works for us in general too. But we overserve a strange behavior why we **can't** use it. In project file we use the package reference like `` to always get the newest version of our packages from the feed. I have a package with version `4.0.0` in the feed. I had to make a very small change, so add a version counter to `4.0.0.1`. `nuget restore` task resolve this package randomly as `4.0.0` and some times as `4.0.0.1` (**local cache disabled**), so we lost the trust in that task. – Mar Tin Dec 02 '20 at 04:43
  • Another requirement is to use the *full* `dotnet` tool chain for our builds. In principal we like the all in one `dotnet` approach. Unfortunately small issues (authentication) prevent the usage of `dotnet` in our pipelines. – Mar Tin Dec 02 '20 at 04:49
  • 1
    Shouldn't I use the `dotnet nuget add source http://xxxxx/DefaultCollection/_packaging/LeoTestFeed/nuget/v3/index.json -n YourFeedName -u YourUserName -p YourPAT --store-password-in-clear-text` on my agents instead of me Azure DevOps Server Machine? – Mar Tin Dec 02 '20 at 04:51
  • @MarTin, If your agent and Azure DevOps Server Machine are not in the same machine, use it in the agent machine. – Leo Liu Dec 02 '20 at 05:42
  • 1
    I try the command on my agent, and the result is the same: `error: No login information is available in the security package`. I use a full access PAT, generated for my personal account. By the way, the workaround we use currently is a simple powershell inline script the executes: `dotnet restore $(Solution) --configfile $(Build.SourcesDirectory)\DotNet.Config`. The `DotNet.Config` is a custom config only with feed source information without auth. – Mar Tin Dec 02 '20 at 05:55
  • @MarTin, The error message seems not related to the certification, you could check this document for some more details: https://github.com/microsoft/azure-pipelines-tasks/issues/10399 and https://stackoverflow.com/questions/53430896/nuget-restore-fails-on-azure-devops-with-message-unable-to-load-the-service-ind. BTW, Thank you for sharing your workaround, you could convert it as an answer before you get the better answer. – Leo Liu Dec 02 '20 at 06:04