"Possible Performance degration, V3 was not working" error when using with TFS feed

[drwatson1]

Description

I get "Possible Performance degration, V3 was not working: One or more errors occurred." message when I use the on-premise TFS server.

Repro steps

The minimal paket.dependencies file to reproduce:

source http://tfs.geobuilder.ru:8080/tfs/DefaultCollection/_packaging/default-1/nuget/v3/index.json
source https://api.nuget.org/v3/index.json

framework: >= net45

nuget GeoCybernetica.Shared ~> 1.1.0.77

http://tfs.geobuilder.ru:8080 - is the latest version of on-premise TFS server and it is accessible from internet. I can provide you a login and password to reproduce.

[shauser]

I also get this warning since a few days, using an UNC path for our internal repository. It seems to me that it happens when two sources are listed and resolve at the same time.
This is the full error I get (which includes the exception message which caused this for me):

Possible Performance degradation, V3 was not working: The process cannot access the file 'C:\Users\username\AppData\Local\Nuget\Cache\Microsoft.AspNet.WebApi.Client.5.2.3.s1689900308_v5.114.json' because it is being used by another process.Possible Performance degradation, V3 was not working: The process cannot access the file 'C:\Users\username\AppData\Local\Nuget\Cache\Microsoft.AspNet.WebApi.Client.5.2.3.s1689900308_v5.114.json' because it is being used by another process.

[drwatson1]

I think this is an another case.
For my issue these messages appear only for packages hosted by on-premise TFS. For nuget.org and myget.org they are absent.

I found issue #2700 with the similar symptoms.

[blumu]

I also get this when pulling from a VSTS V3 feed. Also even though Paket falls back on V2, the message breaks our build because it now gets printed to stderror:

Paket/src/Paket.Core/Dependencies/NuGet.fs

Line 304 in 1cc416b

eprintfn "Possible Performance degradation, V3 was not working: %s" exn.Message

[matthid]

@blumu in vsts there usually is a checkbox in advanced to ignore stderr

[blumu]

I am aware of it but this is to ignore errors, not warnings. I still want the task to fail on actual errors, I would not want to ignore them. Would it make sense to print Paket warnings to stdout like it use to? From: Matthias Dittrich Sent: Wednesday, November 22, 2017 11:34 AM To: fsprojects/Paket Cc: William Blum; Mention Subject: Re: [fsprojects/Paket] "Possible Performance degration, V3 was notworking" error when using with TFS feed (#2877) @blumu in vsts there usually is a checkbox in advanced to ignore stderr — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[matthid]

@blumu Actual errors lead to a non-zero exit code.

[blumu]

@matthid Thanks for confirming that paket returns non-zero exit code. I would still love to have a paket option to silence this error though. As a workaround we disabled the VSTS option to fail on stderror:

The only drawback: we need to make sure to run paket in a dedicated VSTS task as we still want to fail on stderrors issued by our other build scripts.

[matthid]

Yes this is basically the "warnings as errors" feature. Note that in an ideal world we would have zero warnings. But the NuGet ecosystem is a mess and we are glad it is somehow not breaking apart every day. So yeah we have some edge cases.

[enricosada]

Paket/src/Paket.Core/Dependencies/NuGet.fs

Line 304 in 1cc416b

eprintfn "Possible Performance degradation, V3 was not working: %s" exn.Message

@matthid putting that to stdout instead of stderr can be ok?

[drwatson1]

As for me, I think it is a workaround only, not a solution. Because V3 is working

[matthid]

In my opinion warnings need to go to stderr not stdout, because stdout needs to be potentially parsable. That is generally agreed on in the unix and command line world.

[matthid]

Ideally the root cause is solved ;)

[matthid]

Ideally the root cause is solved ;)

I should add: if that is not possible for some technical reason we could add an option to silence that particular warning.

[forki]

Everything agrees except Microsoft. Am 24.01.2018 17:59 schrieb "Matthias Dittrich" <[email protected]>:

…

Ideally the root cause is solved ;) I should add: if that is not possible for some technical reason we *could* add an option to silence that particular warning. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2877 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNEJRT1T_dq5lnOeF9pr3wZetBioxks5tN2FTgaJpZM4QMrUu> .

[matthid]

Everything agrees except Microsoft.

It's really just a matter of defaults. Microsoft thinks defaulting to "Warning as error" is a good default and you cannot argue with that. It's more a problem with people not being able to change the defaults ;)

[drwatson1]

))))
I don't think so. It's look like a holy war therefore.
I can supply you with an account to our server if you want to see what's the matter or you can close the issue as none relevant.... It's up to you)))

[matthid]

No war. Ultimately, we have something here which is not critical but might need to be fixed (-> therefore a warning).
Until then disabling "warning as error" is a viable workaround.

[drwatson1]

Ok, I agree
It's more then nothing)) Thank you
But what do you think about this? Is it a real degradation or it is a possibility only? About a month or two ago 'paket install' takes about 30-40 minutes to add a one new package.... For now it works several minutes

[matthid]

Some additional info (verbose mode):

Starting request to 'https://tfs/tfs/TEAM/_packaging/GUID/nuget/v3/registrations2/PACKAGE/index.json'
Possible Performance degradation, V3 was not working: Value cannot be null.
Parameter name: source
Error while using V3 API: System.ArgumentNullException: Value cannot be null.
Parameter name: source
   at Microsoft.FSharp.Collections.SeqModule.Filter[T](FSharpFunc`2 predicate, IEnumerable`1 source)
   at [email protected](Unit unitVar)
   at [email protected](AsyncParams`1 args)

[matthid]

Actually I think this has been fixed since #3341