forceConsistentCasingInFileNames TypeScrypt equivalent for dotnet

[webartoli]

Is your feature request related to a problem? Please describe.

Dotnet core is a cross-platform language, and increasingly we have teams with different operating systems.

On windows the filesystem is not case sensitive while on *nix it is, and this for dotnet build is a problem.

If on the filesystem for example we have the project Foo.Bar.Lib/Foo.Bar.Lib.csproj by another project as follows.

 <ItemGroup>
    <ProjectReference Includes="FOO.BAR.Lib/Foo.Bar.Lib.csproj" />
    <!--                        ^^^^^^^ wrong casing           -->
  </ItemGroup>

This on windows compiles while on Linux it does not.

Describe the solution you'd like

An option like forceConsistentCasingInFileNames in TypeScript would be useful.

Additional context

In my case many developers are on windows, the CI has windows agents, and running the developers' local environment has docker components.

Result: local build and ci build succeeds while there are build errors by launching docker build.

[marcpopMSFT]

buildcheck request I believe.

[webartoli]

I've done several tests with this repo:

src
` Foo.Bar.Lib/
  ` Foo.Bar.Lib.csproj
    Class.cs
` Foo.Bar.Console/
  ` Foo.Bar.Console.csproj
    Class.cs

Where Foo.Bar.Console.csproj file contains a reference with a different casing for the lib path:

 <ItemGroup>
    <ProjectReference Includes="FOO.BAR.Lib/Foo.Bar.Lib.csproj" />
    <!--                        ^^^^^^^ differs for casing     -->
  </ItemGroup>

Here below the results:

Dotnet SDK	OS	File System	Result
8.0 LTS	Windows 11 24H2	NTFS (Case insensitive)	✅ Build Success
8.0 LTS	macOS Sequoia	APFS (Case insensitive)	✅ Build Success
8.0 LTS	Microsoft Hosted AzureDevOps Agent Ubuntu 20.04	ext4 (Case sensitive)	✅ Build Success
8.0 LTS	Official mcr.microsoft.com/dotnet/sdk:8.0 docker image	ext4 + overlay (Case sensitive)	🟥 Build Failed

I would expect a consistent result that was either in both cases red or in both cases green. But not different outputs on such similar architectures.

But if different behavior are expected for different os I think it is critical to include a flag/settings that can check for this issue regardless of the OS under which it is run.

Particularly in this scenario the CI marks as build succeeded but a local docker build fails and this is a serious issue.