dotnet restore fails when user folder contains non-standard characters in user name

[alexhost]

Description

A user has the character ø in their name. The user account folder (generated from AD) under C:\Users\ also contains this ø character. The user's solution source folder exists along this path. A call to dotnet restore ends up attempting to read from the wrong path as it appears to replace ø with o. It then proceeds to create a new directory in under C:\Users\ with ø converted to o (thereby pretty much verifying that it's confused about the path). The dotnet restore then fails (obviously), with error NU1301.

Configuration

• Which version of .NET is the code running on? 6.0.401
• What OS and version, and for Linux, what distro? Win11 (10.0.22621)
• What is the architecture (x64, x86, ARM, ARM64)? x64
• Do you know whether it is specific to that configuration? No
• If you're using Blazor, which web browser(s) do you see this issue in? n.a.

Regression?

Unknown, but have not seen this occur before. Potentially a regression.

Other information

error NU1301: Unable to load the service index. Unsurprising, given that it is looking in a directory that does not exist (o in the path instead of ø).

[buyaa-n]

Not sure if it is related to MSBuild or SDK, tagging both CC @rainersigwald @dsplaisted

[dsplaisted]

@alexhost Would it be possible to share a binlog of the failed restore operation?

FYI @dotnet/nuget-team, looks like there's a globalization issue somewhere here, possibly in NuGet.

[zivkan]

error NU1301: Unable to load the service index

this error points to an HTTP or networking issue. Unless the package source is private and needs authentication, and the username/password is in a nuget.config inside the directory with the ø, I think there might be two separate issues.

I agree a binlog would help us understand what's going on.

[zivkan]

After encountering many problems, I finally created a VM to test, and I can confirm that dotnet nuget locals all --list shows the wrong directory names. So it appears to be a bug in NuGet. I'll look for an "easy" way to copy this issue to NuGet/Home.

[zivkan]

Actually, when I do dotnet new console and then Console.WriteLine(Environment.CurrentDirectory);, the wrong character is output. Therefore, I think it's actually a bug in the runtime. Should this issue be moved to dotnet/runtime? I'm not familiar with how issues are tracked outside NuGet. seems to be a terminal & code page issue. I was looking at filing a new bug, but dotnet/runtime#43295 and dotnet/runtime#31466 seem to cover it already.

[zivkan]

Trying to repro the bug, I created a local package feed in $USERHOME\nupkgs, created a nuget.config that adds it as a package source, then both dotnet add package MyAmazingPackage worked, and when I check the project's obj\project.assets.json file, all the paths containing c:\users\<username> contained the correct character (not changed to o).

Therefore, I cannot reproduce the bug.

[github-actions]

This issue is stale because there has been no response to a request for more information for 7 days.

[github-actions]

This issue was closed because there was no response to a request for more information for 10 days.