-
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
[Preview] Unable to restore packages from feeds with encrypted passwords on windows #23498
Comments
|
The same issue on multiple environments after today's update to 6.0.2 from stable channel. |
We have the same problem. All projects currently not building on our OnPremise Build-Servers |
We are also seeing this issue in our on-premises build servers using an authenticated TeamCity feed after installing VS 2022 17.1 build tools. |
I'm getting the same error after installing dotnet 6.0.2 via chocolatey ( |
Same. Will add that we're seeing this behavior on Win Server 2016 environments, though doesn't seem like the issue occurs on Server 2022 |
In my case it is not even a feed password, it's |
Same for us since updating to SDK |
I debugged this issue with
So the problem seems to be the The Windows platform specific DLL is found under the runtimes directory ( For some reason the dotnet executable is using the non platform specific version of the DLL and not the Windows platform specific version. I was able to workaround the issue by removing the non platform specific DLL at EDIT: Environment where I tested is Windows Server 2016. |
I tried to troubleshoot this issue further using dotnet-trace tool to see how assembly loading goes. I traced the dotnet restore command using command Trace of not working version (6.0.200)
Trace of working version (6.0.101)
|
This broke all our GitHub Actions jobs today after GitHub appeared to upgrade their .NET SDKs to use v6.0.200 instead of v6.0.101. We can no longer run our build scripts due to this exception. I sure hope Microsoft and GitHub can get a bug fix out ASAP! |
Hello everyone - this is a very concerning report, the team is currently investigating what some solutions might be. We're currently working on reproducing the error before we commit to a solution. Thank you especially to @saurla for the investigation and @shadow-cs for the initial report. |
Notes for team - the reference to System.Security.Cryptography.ProtectedData is being added here, but binlogs show both the OS-agnostic as well as the runtime-specific outputs being added to the redist project. We will likely need to look at post-build, pre-pack hooks to remove this dll, and then look into automated validation of other such dependencies (where an OS-agnostic DLL would error, but a correct OS-specific DLL is present). An alternative might be to change the SDK layout at the |
One further note from me. The OS agnostic version of |
The problem is also present on .net 7 preview 1 ( |
We just encountered this on our build pipelines in Azure DevOps, where the agent image |
@saurla the OS agnostic dll has been in that location since at least the 5.0.1xx SDKs, my running theory is that we just weren't using any data protection APIs in any SDK code paths until the PR linked above that would highlight this issue. |
@baronfel Ok. But I think it's expected behavior that OS agnostic dll of ProtectedData is found from the "root" folder and OS specific one from the runtimes when referencing that NuGet. I tried if I could reproduce this issue with very simple .NET 6 project that references the |
I'm having a hard time reproducing this - it would be very helpful if we could get the following data from anyone experiencing this:
|
I'm currently ill, so I can't do it right now. For whoever is doing it: @baronfel I assume that's the thing you are missing and why it's hard for you to reproduce right now. |
Even running
|
I started looking again through the assembly loading trace I pasted in comment #23498 (comment). I noticed that the used AssemblyLoadContext is I noticed that in the MSBuild side there was this one change between 17.0.0 and 17.1.0 to the |
The MSBuild-side revert is merged to daily builds of the 6.0.2xx SDK, and the next patch release of the .NET SDK should have the fix. |
We are currently having the same issue with 6.0.201 SDK. We had to go back to 6.0.101 via global.json for being able to restore nuget packages behind our proxy server. |
Having the same issue with the SDK. 6.0.201 on Windows 10 Enterprise. @saurla your workaround really helps. Thank you. Hope this bug gets fixed asap. |
We have the same problem on Windows, .net6. It fails with SDK. 6.0.201, and works with SDK. 6.0.101. But its many changes to our build scripts to stay on a fixed version, and not the latest .net. (we use cake as well). Any solution on this? Seems its been around for quite some time now this bug? |
@MrBjorn no need to change your build scripts. Just install 6.0.101 on all of your build servers and pin it by adding global.json to the root of your repo. |
@ABAG603 I'm not sure if it's sufficient in all cases. Our {
"sdk": {
"version": "6.0.101",
"rollForward": "disable",
"allowPrerelease": false
}
} |
Thanks for the fast and good reply! I added this and it worked. It seems like I had to add it to my unit test project as well. Well, I hope MS solves this asap., its not optimal to be stuck on a fixed .NET version. |
I had this problem also on a new computer with a new installation of Visual Studio - whatever version was available a week ago. (Now it is 17.1.3, but I'm not sure if there was an update or not) .NET SDK 6.0.201 was the only SDK installed. I installed .NET SDK 6.0.101. The problem is gone now. I did not need to add a global json file. |
Another computer spontaneously started having this problem. It has 17.1.3. Installing .NET SDK 6.0.101 did not alone fix the problem. |
Just tested .NET SDK 6.0.202 and everything appears to be in order in this version 😉. |
The changelog for MSBuild looks promising. Will try it tomorrow. |
Has anyone dared updating to 6.0.4 yet? Does it solve the issue we're discussing here? |
Yes it does. .NET SDKs 6.0.104 and 6.0.202 will also include the fix. Updating VS 2022 to 17.1.4 will also pull the needed version. I just removed the global.json pinning everywhere. |
Sweet! |
Nice it's released. Does someone know when the hosted agents get updated with this release? |
6.0.202/104 is not working for me, |
@hamarb123 Sounds like a different issue since it now has access to the DAPI (different message). So I'm not sure if it's not better to open a separate one. Is it working if you place a global.json and set the SDK to 6.0.101? |
Just tested this, it doesn't. |
Relentless searching - this seems to be exactly my problem..
None of the workarounds worked either. |
Bullseye is Debian 11 and as the message states, encrypted passwords only work on windows images. So it's not an issue with the current version but that the API is just not available. Either use a windows based image if you are on a windows host or use the unencrypted password flag. The tags with To use windows containers, right-click on your docker icon and switch the daemon. These are only hostable on windows machines. |
I'm using --store-password-in-clear-text. Is that what you mean by add the flag? |
Sorry, I missed it at the end of the line there. Yes, that's the flag that should work |
No problem. Yeah, it doesn't work for me with those commands from my dockerfile. I am using a GitHub action passing the GITHUB_TOKEN as a --build-arg and then using that in the actual docker file that's described above. Hhhmmm?? -- edit: 2022-04-18 |
Since this fix is out on patch releases of 6.0.1xx and 6.0.2xx SDKs, I'm going to close this issue since it dealt specifically with loading the correct version of the DPAPI DLLs. If folks have any more issues with NuGet key handling, please raise another issue to track that. |
Fixes #4081 and Fixes #1887; progress towards #5037 Context MSBuild doesn't currently respect .deps.json files for plugins (tasks). This can lead to incorrect versions of assemblies being found as finding the AnyCPU version of an assembly instead of the windows-specific version. Changes Made Use AssemblyDependencyResolver as a second pass (after looking for "well-known assemblies") to automatically use the deps.json file to find the right assembly. Testing Verified that for a task assembly with a rid-specific dependency, it finds the rid-specific dependency as specified by the deps.json file. Also verified that it can find native assemblies and that the issue that inspired this (dotnet/sdk#23498) no longer reproduces after giving nuget a .deps.json file specifying the correct version.
We had to pass the --build-arg flag to get the secret to work. We were passing as secrets on github actions. 'secrets: |' --build-arg failed on 6.0, but was succesful on 6.022.
|
Describe the bug
After the recent update of VS Preview (I got the telemetry prompt earlier today), I'm not able to restore packages from feeds that use an encrypted password.
To Reproduce
dotnet nuget locals all --clear
just in case to make sure the restore operation is neededdotnet restore
Exceptions (if any)
Detailed exception.
Further technical details
6.0.200-preview.21617.4
Workaround
Use
global.json
and downgrade to6.0.100
.The text was updated successfully, but these errors were encountered: