Open stewartadam opened 3 years ago
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.
Additionally, when opening the .sln file into visual studio, the nuget packages can't be restored and no files get added to the solution. have not been able to find another workaround other than re-cloning into a folder with no spaces in the path
This issue was moved to NuGet/Home#11247
@kartheekp-ms investigated https://github.com/nuget/home/issues/11247#issuecomment-923322523 and he found that https://github.com/dotnet/sdk/blob/b6bbe16dc12c3bc394ac58b72eefd7d5a7c068c9/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.PackageDependencyResolution.targets#L24 is where the assets file path expected by the SDK changes.
We think the fix should happen on the SDK side.
Describe the bug
NuGet.targets (or perhaps something that includes it in the msbuild stack) is incorrectly performing a URL-decode on filesystem paths, causing builds to fail due to projects not being found (because it's trying to access them with
folder name
offolder%20name
as they exist on the filesystem).This can happen easily by cloning a Azure DevOps repo whose project has spaces in its name, as DevOps provide the clone URL with %20 characters in it.
To Reproduce
Exceptions (if any)
Further technical details
dotnet --info