NuGet.targets incorrectly performs a url-decode on filesystem paths, resulting in projects not found

stewartadam commented 3 years ago

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 of folder%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

mkdir -p ~/git/Backend%20Endpoints
cd ~/git/Backend%20Endpoints
dotnet new console
dotnet build -v d

Exceptions (if any)

Microsoft (R) Build Engine version 16.11.0+0538acc04 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
/usr/local/share/dotnet/sdk/5.0.400/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1004: Assets file '/Users/stewartadam/git/Backend Endpoints/obj/project.assets.json' not found. Run a NuGet package restore to generate this file. [/Users/stewartadam/git/Backend%20Endpoints/Backend%20Endpoints.csproj]

Build FAILED.

Further technical details

Include the output of dotnet --info
The IDE (VS / VS Code/ VS4Mac) you're running on, and its version: N/A

.NET SDK (reflecting any global.json):
 Version:   5.0.400
 Commit:    d61950f9bf

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  11.0
 OS Platform: Darwin
 RID:         osx.11.0-x64
 Base Path:   /usr/local/share/dotnet/sdk/5.0.400/

Host (useful for support):
  Version: 5.0.9
  Commit:  208e377a53

.NET SDKs installed:
  3.1.412 [/usr/local/share/dotnet/sdk]
  5.0.400 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.18 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.9 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.18 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.9 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

dotnet-issue-labeler[bot] commented 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.

tessmichi commented 3 years ago

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

wli3 commented 3 years ago

This issue was moved to NuGet/Home#11247

nkolev92 commented 3 years ago

@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.

dotnet / sdk