Make nuget packages path use forward slashes.

[VSadov]

Need to use forward slashes to be compatible with Unix-like platforms.

[gafter]

👍

[agocke]

[jaredpar]

Why is NuGet special here? Nowhere else are we using forward slashes, the expectation is the tools on top need to be smart about slashes when crossing platforms.

[VSadov]

My view on this is that indeed, the tools on the top that perform path resolution and pass paths to other tools downlevel (like MSBuild) must be smart with slashes. However in this case there is no top level tool. The path is simply stored in a config file and NuGet does not do any resolution, just simply passes it to the file system. From this view it seems that we just need to fix the path in the config.

[jaredpar]

@VSadov how is this not broken for Windows?

[jaredpar]

You're saying there is no top level tool but we're also making a change to un-break something. So what's broken? And why is that item not dealing with the path like every other .Net tool.

[VSadov]

The path in the config file is is not correct on Unix-like platforms. If the path was created by an automated tool/process we would need to fix that, but the path is simply directly editable data. Essentially the top level tool that controls this path is us and we should just fix the path.
It is the same as if we had a path in a project file in wrong case. Assuming support for case-sensitive environments, that would be a human error and the proj file would need to be fixed.

[jaredpar]

I'm still not understanding what broke? What prompted this change?

[VSadov]

Without this change, "NuGet.exe restore src/Roslyn.sln " restores packages literally into ./....\packages
Note that "....\packages" is a valid directory name on Unix and on the part of NuGet this is technically a correct behavior.

[jaredpar]

Why don't we think this is a bug in NuGet? We are expecting all of our other tools like MSBuild to do path normalization on Linux. I don't see how NuGet is special here.

[VSadov]

I actually expect that most tools do not need to get involved with paths. MSBuild is special here since it is already heavily involved in the business of path resolution/canonization.
It is good question to the NuGet owners whether they see NuGet as a neutral consumer of paths (like csc.exe) or as a tool that wants to deal with paths in some platform-aware fashion (like MSBuild). At the moment it clearly just passes paths through to IO, therefore the fix is needed at least to get unblocked.