DNU file globbing is case sensitive on Windows

[pranavkm]

It looks like DNX was changed recently that made paths to be case sensitive (See https://github.com/aspnet/xunit/commit/91d7568fb13201f3f3f427edbc0e07cf36982102). This is not very intuitive on Windows (or other platforms where paths are case insensitve) since ls-ing these paths return results, but DNU fails to match these paths. E.g.

{ "compile": ["../Foo.cs"] }

with the file on disk being named foo.cs does not include the file.

[troydai]

The file globbing is indeed case sensitive. But the second part of the issue is not a bug. It is because the compileBuiltIn is not override.

[troydai]

/cc @davidfowl @lodejard need you import. It is universal case sensitive today. If we make if case insensitive on Windows, it may cause trouble when a project is copied to *nix environment.

[troydai]

@pranavkm I've talked to multiple people including @victorhurdugaci @davidfowl @NTaylorMullen all thing case sensitive universally is better.

Given that, I think a better output warnings will be the best second options. Thoughts?

[pranavkm]

Seems like a terrible choice, but we should probably make sure we're consistent in behavior with the one in the tag helpers in Mvc \ other places that specify globbing paths. cc @DamianEdwards

[troydai]

Talked with @NTaylorMullen regarding this topic. Seems to be the case.

[NTaylorMullen]

Talked with @pranavkm and I feel that if we can only choose 1 (case sensitive or case insensitive) case pattern I feel like case sensitive is the right/broader approach.

However, in my opinion the 100% best approach is to auto-detect the current platforms case-sensitivity and use that. This would also involve allowing a flag to be passed in to specify one way or the other to override the default behavior. Auto-detecting would be consistent with how other things reflect cross platform ex being Environment.NewLine (it just happens to be another value when on Linux); also it would keep developers familiar with the platform they're developing on.

[troydai]

Auto-detect will suffer from the incompatible search path across platform. A project compiled on Windows but fail on other OS because of missing file. I'm generally against the idea auto-detect approach because it hides the assumption from user.

My suggest is to offer a loosen mode, in which file searching detects current OS to decide if case-sensitive or not. The loosen mode is not the default option, but we provide warning message to notify users. The switch of the loosen mode can be placed in the project.json.

[Tragetaschen]

I'm reminded of aspnet/Home#225 and my list of suggestions. I'm sure glad to see things improving considerably ☺️

I'd like to 👍 a default of loosen mode, so possible future problems when developing with VS on Windows can surface early. As mentioned in the Home bug, things like Razor precompilation won't run when the folders don't follow the lower-case naming convention and this is really hard to notice otherwise.

Personally, I'd always go with strict mode, but that's definitely too much for many programmers. And those that know they will always run on a case-insesitive file system on Windows have the option to disable these kinds of warnings.

[NTaylorMullen]

@troydai Loosen should definitely be the default. I understand your concern with copying a project on windows and moving it over to another platform causing issues but this inherently is already the case (going back to my other example of Environment.NewLine). In essence if it's already going to be a problem I'd much rather make the 90% case where users are developing on a single platform family (whether it be linux or windows etc.) be consistent with the platform they're on/what they're used to; otherwise you're setting users up for failure due to unexpected errors.

[troydai]

All right. So looks like the consensus is:

1. Add a loosen mode, in which the file searching is case-insensitive on Windows (but always case-sensitive on other OS);
2. loosen mode is the default mode.

[NTaylorMullen]

👍

[Tragetaschen]

I really hope the solution here spans most (if not all) cases of conventional files like ViewStart.chstml or the special project folders. Currently, it's way too easy to get things wrong - event in the VS templates.

[troydai]

/cc @muratg @glennc is this issue accepted? Can I begin working on it?

[muratg]

@davidfowl What is the verdict here?

[lodejard]

It's not just the OS to detect, but the rules in effect on the hard drive in question. Mac default drive format is also case insensitive. Even worse I think if you're using a file share case sensitivity might be determined by the file server? (The last is a speculation.)

Instead of adding a loosen mode or messing around with configuration or detection, to start with let's just change the matching to use case insensitive comparisons. Once that's done lets ask the folks doing cross-platform clrs what's the right API to tell if a folder path is on a case-sensitive drive, and if there is one add a second bug to get file globbing to use it.

[troydai]

Ping @davidfowl @lodejard @glennc
/cc @muratg
Can we all agree on @lodejard 's solution?

1. Change to case insensitive unconditionally for now.
2. Find the right API to detect if the file system is case sensitive then take different approach.

[troydai]

Keep the remaining task being tracked in #2260.

This one is fixed.