'dotnet build <SLN>' fails if path in the solution file is not case sensitive

Steps to reproduce

mkdir ProjectA
mkdir ProjectB
cd ProjectA
dotnet new classlib
cd ../ProjectB/
dotnet new classlib
cd ..
dotnet new sln
dotnet sln add projecta\projecta.csproj <- this will break the build
dotnet sln add projectb\projectb.csproj

Add the following to ProjectB

<ItemGroup>
    <ProjectReference Include="..\ProjectA\ProjectA.csproj" />
</ItemGroup>

And build the solution with

dotnet build

Expected behavior

λ  dotnet build
Microsoft (R)-Buildmodul, Version 15.4.8.50001 für .NET Core
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

  ProjectA -> C:\temp\test\ProjectA\bin\Debug\netstandard2.0\ProjectA.dll
  ProjectB -> C:\temp\test\ProjectB\bin\Debug\netstandard2.0\ProjectB.dll

Der Buildvorgang wurde erfolgreich ausgeführt.
    0 Warnung(en)
    0 Fehler

Verstrichene Zeit 00:00:03.00

Actual behavior

λ  dotnet build
Microsoft (R)-Buildmodul, Version 15.4.8.50001 für .NET Core
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

  projecta -> C:\test\projecta\bin\Debug\netstandard2.0\projecta.dll
C:\Program Files\dotnet\sdk\2.0.2\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets(114,5): error : Die Projektinformationen für "C:\test\projecta\projecta.csproj" wurden nicht gefunden. Dies ist möglicherweise auf einen fehlenden Projektverweis zurückzuführen. [C:\test\projectb\projectb.csproj]

Fehler beim Buildvorgang.

C:\Program Files\dotnet\sdk\2.0.2\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets(114,5): error : Die Projektinformationen für "C:\test\projecta\projecta.csproj" wurden nicht gefunden. Dies ist möglicherweise auf einen fehlenden Projektverweis zurückzuführen. [C:\test\projectb\projectb.csproj]
    0 Warnung(en)
    1 Fehler

Verstrichene Zeit 00:00:02.99

Running the build with /v:d or /v:diag did not help as it produced no additional information except

Die Ausführung der GenerateDepsFile-Aufgabe ist abgeschlossen -- FEHLER.

I had to build my own Microsoft.NET.Build.Tasks.dll[*] to be able to debug the GenerateDepsFile-Task.

The problem here is that in https://github.com/dotnet/sdk/blob/8992a1b11f55b93bea97aa8483de8c85a986c070/src/Tasks/Microsoft.NET.Build.Tasks/DependencyContextBuilder.cs#L623-L627 _referenceProjectInfos contains a list of the case sensitive absolute paths to the referenced projects and for some reason the path from the SLN which is not case sensitive is used to find the referenced project.

Environment data

λ  dotnet --info
.NET-Befehlszeilentools (2.0.2)

Product Information:
 Version:            2.0.2
 Commit SHA-1 hash:  a04b4bf512

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.2\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

Workaround

Change the projet references inside the SLN to the correct case sensitive version

[*] On a side note Debugging the Microsoft.NET.Build.Tasks.dll did not work out of the box too. After adding Debugger.Launch(); in GenerateDepsFile.Execute(), building the project and copying the output to C:\Program Files\dotnet\sdk\2.0.2\Sdks\Microsoft.NET.Sdk\tools I could attach Visual Studio to the process but was unable to debug because Visual Stiudio wouldn’t load my debug PDB (see dotnet/core-setup#3138).

After some googling and trying the same with VSCode I found the following warning while attaching to the build process

WARNING: Could not load symbols for 'Microsoft.NET.Build.Tasks.dll'. 'C:\Program Files\dotnet\sdk\2.0.2\Sdks\Microsoft.NET.Sdk\build\..\tools\netcoreapp1.0/\Microsoft.NET.Build.Tasks.pdb' is a Windows PDB. These are not supported by the cross-platform .NET Core debugger.

After adding

<DebugType>portable</DebugType>

to the Microsoft.NET.Build.Tasks project and rebuilding it I was finally able to debug the Task.

[peterhuene]

It would impact users that really do have two project paths that differ on case (Linux and case-sensitive APFS users on OSX). Given our tooling currently prevents users from adding references / projects based on case differences, users would have to have manually modified the solution / project files to add the entries. I would not be surprised if no one ever runs into this (having SRC/foo.csproj and src/foo.csproj in your repo would not be a good practice, regardless of our tooling).

[KathleenDollard]

We should be consistent in how we handle this. I agree that we change the dictionary to ignore case.

Are there any scenarios this could result in problems for users? I am just considering whether this is a minor bug fix or something we need to talk about.