2

I have a package feed on VSTS providing several packages that I reference in a solution that is also being built on VSTS. The builds have suddenly started failing at the package restore phase with the logs indicating that it cannot find the dlls nuget is supposed to restore.

Restoring NuGet package Basd.Diagnostics.0.7.0.

WARNING: Unable to find version '0.7.0' of package 'Basd.Diagnostics'.

The public / private feeds are listed in my nuget.config and they also show up in the build logs "Using Feeds..." so it's not a matter of the restore operation not being able to find the actual feeds for the package. It's more like it can't authenticate and therefore can't retrieve the package from the feed.

If I look at the history for the build definition there is a change from when it last worked to now and that is this:

  "build": [
    {
      "enabled": true,
      "continueOnError": false,
      "alwaysRun": false,
      "displayName": "NuGet restore MySol.sln",
      "timeoutInMinutes": 0,
      "task": {
        "id": "333b11bd-d341-40d9-afcf-b32d5ce6f23b",
        "versionSpec": "*",
        "definitionType": "task"
      },
      "inputs": {
        "solution": "Basd.Core.sln",
        "nugetConfigPath": "nuget.config",
        "restoreMode": "restore",
        "noCache": "false",
        "nuGetRestoreArgs": "",
        "verbosity": "",
        "nuGetPath": "",
        "preCredProviderNuGet": "false"
      }
    },

There is now a "preCredProviderNuGet": "false" field in the definition. I've googled but I can't find out how and where this is set but I'm assuming this is preventing authentication to my feed which in turn is why the restore operation fails.

So where is this setting and/or how do I turn it back on or remove it as an entry? In the working build def, it was not set to true, it just didn't exist.

Is it a VSTS UI related field or something I set in nuget.config files? I'm assuming the former because again doing a diff suggests nothing has changed in my nuget.config between working and non working builds.

Community
  • 1
  • 1
rism
  • 11,932
  • 16
  • 76
  • 116
  • https://www.bountysource.com/issues/36464119-nuget-installer-restore-fails-to-pull-down-unlisted-packages-from-vsts-package-management – rism Jul 31 '16 at 00:43

2 Answers2

1

This seems to be caused by the VSTS issue which should be fixed by now, please try the build agent.

Issue: Packaging issues with Visual Studio Team Services – 7/30 – Resolved

Eddie Chen - MSFT
  • 29,708
  • 2
  • 46
  • 60
  • No unfortunately this does not solve my problem but given nothing has changed at my end and that the timing is too coincidental Id suggest its Microsofts problem. This is the problem with cloud - lack of control and when it breaks it breaks for everyone. A bug becomes an infection. Thanks for the link though - something of a sanity check. – rism Aug 01 '16 at 08:38
  • @rism MS is investigating a new issue on this: https://blogs.msdn.microsoft.com/vsoservice/?p=12025 – Eddie Chen - MSFT Aug 02 '16 at 00:59
  • The second patch / fix has worked. Thanks for the links. – rism Aug 02 '16 at 07:25
0

The "preCredProviderNuGet" setting is not related to your problem. The NuGet Restore task has additional advanced settings, "Path to NuGet.exe" and the corresponding checkbox "Path to NuGet.exe is below version 3.2". These settings correspond to the nuGetPath and preCredProviderNuGet settings in the build json. In usage, preCredProviderNuGet only has an impact if the nuGetPath is also set, and is a signal to the task that the version of NuGet in use will not be able to employ the credential provider, since plugin credential providers are not supported prior to v3.2

One suggestion would be to set this task's verbosity to "Detailed", and rerun the build. You will find that in NuGet Restore task \ Advanced \ Verbosity.

Peter S - MSFT
  • 1
  • Thanks for reply but it's the detailed logs that lead me to believe this setting is key. In the builds that worked when this setting was not present it would log `Setting Credentials for xyzFeed`. In the builds that fail where `preCredProviderNuGet` is present there is no entry for that. If it does't set the credentials then it would make sense that it won't connect / find packages. So this setting is turning off the step that sets the credentials. Since both builds had neither a nuget path or the below version 3.2 checked, i think this setting is acting on something all the same. – rism Jul 31 '16 at 03:36