dotnet restore fails only on Linux when Sdk="Microsoft.Net.Sdk"

[livarcocc]

From @danpere on August 28, 2017 18:9

Steps to reproduce

1. Create a .csproj file in the new format that starts

<Project Sdk="Microsoft.Net.Sdk">

and has NuGet packages referenced. (Note the casing: the docs say the Sdk should be "Microsoft.NET.Sdk" with NET in all caps.)

2. Run dotnet restore on Windows.
3. Run dotnet restore on Linux.

Expected behavior

dotnet restore fails or succeeds on both platforms.

Actual behavior

dotnet restore successfully restores packages on Windows. On Linux it displays

Foo.csproj : error MSB4236: The SDK 'Microsoft.Net.Sdk' specified could not be found.

Environment data

dotnet --info output:

.NET Command Line Tools (2.0.0)

Product Information:
 Version:            2.0.0
 Commit SHA-1 hash:  cdcd1928c9

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  14.04
 OS Platform: Linux
 RID:         ubuntu.14.04-x64
 Base Path:   /usr/share/dotnet/sdk/2.0.0/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

Copied from original issue: dotnet/cli#7541

[livarcocc]

From @dasMulli on August 28, 2017 18:21

I'd always expect filesystem-based logic to behave differently on file system with different case sensitivity.

The problem now is that it isn't "really well" fixable. NuGet worked around similar problems by making all package folder names lowercase for the global packages cache (to support case insensitive PackageReferences). Now that there are multiple versions of msbuild with SDK resolvers out (dotnet cli, VS msbuild, mono msbuild) this will be hard to change.

[livarcocc]

From @danpere on August 28, 2017 18:26

The documentation says "Microsoft.NET.Sdk", so I'd expect tools to reject "Microsoft.Net.Sdk", even on case-insensitive file systems. I could see how changing the behavior to make something previously valid be an error could be a problem... perhaps a compromise would be to make it a warning?

[livarcocc]

If we decide to do that, it will have to happen in MSBuild, as doing that just in the resolver level does not cover all scenarios, as such, I am moving this bug over there.

[hcoona]

I think I also hit this issue.

/__w/1/s/dirs.proj : error MSB4019: The imported project "/__w/.nuget/microsoft.build.traversal/4.1.0/Sdk/Sdk.props" was not found. Confirm that the expression in the Import declaration "/__w/.nuget/microsoft.build.traversal/4.1.0/Sdk/Sdk.props" is correct, and that the file exists on disk.