-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.NET 5: Unable to install some .NET tools (dotnet tool install) #14547
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
I persisted the workspace to see if the file really isn't there.
|
@wli3 this seems to be an issue with dotnet tool install |
This might be a race condition. I've seen similar failures before but I still cannot repro |
Any idea how to troubleshoot? It is reproducible constantly (but only on our Jenkins slaves which are Linux containers btw). We are willing to invest some time here, as it blocks our whole company from updating to .NET 5. EDIT: The workspace w/o the file point into the wrong direction as this is the workspace after the failed install. When looking at the NuGet code I noticed that there is some cleanup code. Here is a screenshot of the Workspace during the install. |
@nkolev92 does the stack trace ring a bell? Any suggestion on how to investigate? |
@msallin is it possible for you to have a docker image with minimal repro (with only install dotnet tools steps) so that I can try it on my machine? |
ACL issue maybe? |
Hmm.. It's a Jenkins slave. Not sure if this is possible/reasonable. I'll contact our toolchain guys and discuss this.
Keep in mind that it works a) for .NET 2.2, 3.0 and 3.1 but not for 5.0 b) it works with some global tools (seems that only custom created tools hosted on our NuGet feed work). Hard to imagine that this is an ACL issue, isn't it? Further context:
Thoughts: |
The problem is "solved" by using env.NUGET_CERT_REVOCATION_MODE = 'offline'. Open questions:
|
I looked a bit at the source code. It seems like: |
@nkolev92 something to look into in nuget? |
In 5.0, signature verification was added. Probably what's causing this problem. cc @heng-liu and @kartheekp-ms who did the work there. I imagine you have certain ports blocked on those machines that makes the verification fail. |
@nkolev92 - It looks like customers are hitting the race condition mentioned here because the logs pasted in above comments showed
I think, it is just a coincidence that installation succeeded upon setting |
@kartheekp-ms @nkolev92 so this is considered a user error? |
What on this issue can be considered as user error? I don't understand what's wrong with what we are doing (especially, as this works fine for 3.1). I read through the linked issue. If it is the same, this issue should not occur anymore, when we specify the tool version, right? Should I try to reproduce it with specify the version? |
The race condition linked is an old tools implementation, not the same as global tools. Global tools regular restore. There's only 1 thread trying to write here. |
@msallin I am unable to reproduce this issue on WSL (Windows Subsystem for Linux) and Windows with Transferring this issue to |
I'm also unable to reproduce it when not using our Jenkins-Slaves. In the meantime, I tried to use NuGet directly (without Artifactory). It's the same result. |
close due to no repro |
Description
We install .NET tools on our Jenkins slaves (e.g. Sonar-scanner, powershell & report generator). After switching from .NET Core 3.1 to .NET 5.0 some tools cannot be installed anymore.
I discovered that I'm able to install .NET tools which are created by our own but not .NET tools from the public NuGet feed. We use Artifactory as NuGet feed proxy. Restore and build of a project works correctly.
Same situation for install it local and global.
One example is PowerShell. After ~17min it fails with the following error message.
The text was updated successfully, but these errors were encountered: