View lookups are case sensitive on non-case sensitive file systems

[ctolkien]

Not sure if a bug or by design, however with a view file named Alternate.cshtml on disk the following code works when not-precompiled:

return View("alternate");

But fails when precompiled. Needs to be

return View("Alternate");

To match the case of the file on disk. This is when deployed to Azure App Services (Windows).

[pranavkm]

The behavior wasn't by design, we just happen to have case sensitive structures where the precompiled view names land. That said, I looked at what embedded file provider does and it has the same behavior. In the case of the embedded provider, it's the call to Assembly.GetManifestResourceName that uses the casing files were embedded with. Perhaps this behavior is best left unchanged which would leave disk based providers a bit of an anomaly.

@DamianEdwards \ @rynowak , thoughts?

[ctolkien]

Further biting us... I'd created an area in Areas/Admin

And then registered controllers in there with [Area("admin")]

This asploded as well, as it was looking for views in Areas/admin/...

Core of my issue I guess.. is that things which work locally on my particular environment, don't work in production, and I'm caught unawares. Need to manually go and check if views are loading once something has been deployed.

[rynowak]

My understanding is that we are always case sensitive with view lookups now, to avoid a problem where you test and windows and deploy to linux.

[ctolkien]

@rynowak

My understanding is that we are always case sensitive with view lookups now, to avoid a problem where you test and windows and deploy to linux.

That doesn't appear to be the case. I've just tested this:

return View("TestingCase");

returns a view file named testingcase.cshtml (lowercase) when on Windows.

[pranavkm]

@ctolkien what @rynowak was trying to get to was that we don't do anything in particular to make the view lookup case invariant. If you had been working on a case sensitive file system or an IFileProvider such as EmbeddedFileProvider which does case sensitive lookups, the results you're seeing here would have been identical. Related discussion about this in the past: aspnet/Mvc#4426.

cc @danroth27 since you closed aspnet/Mvc#4426

[Eilon]

For the reasons @pranavkm mentions, this is by design. View names by default are case sensitive.

[Vasim-DigitalNexus]

Any chance making this optional? This is a real pain for large projects when refactoring folders or view names.

[Eilon]

@Vasimovic I think that is unlikely given that on many systems it's a hard requirement that there's no control over. I totally get that it can be annoying to deal with, but I think after all the issues in the app are fixed, they won't resurface.

[Vasim-DigitalNexus]

@Eilon I understand, would be nice to get errors or warnings during development though, since it works fine during development and then suddenly file not found error when published

[Eilon]

Ah, I agree it would be nice to possibly detect that. However, I'm not sure quite what it would look for... I don't know how reliable it would be for the disk-based view lookup to see that the case "changed."

For example, someone asked for "c:\apps\MyCoolApp\VIEWs\HOme\indEX.CShtml", which on Windows would succeed if it used controller=Home, action=Index, but then with pre-compiled views would fail. What I don't know is how to detect that there was a casing mismatch.

Any ideas on that?

[Vasim-DigitalNexus]

I am not sure, could the precompiler somehow check any functions that expect a view (e.g. View, PartialView, Html.PartialAsync, etc.) and give a warning?

I realize this is much more complicated since you can pass string variables with the view path, and assign them during runtime

Maybe, at runtime during debugging throw an error if the view name case-sensitivity does not match path/view on disk?

Or, on Windows platform, the precompiler could ignore case sensitivity, however, I understand this is not desirable

[ctolkien]

Any ideas on that?

No idea on the specifics, but I'd just prefer consistency. Is there a way to force when development is on Windows to also be case sensitive?

[pranavkm]

@ctolkien - We had a discussion about enforcing case sensitivity on Windows in another work item (#42). The SO answer for it don't look particularly pretty - http://stackoverflow.com/a/32995942

[Vasim-DigitalNexus]

It's is a hard thing to solve, my biggest issue is the precompiled views; the view files are not distributed, and you get a file not found when there is actually no physical file in the first place

Yes, I could search for every view path and file name and double check that I have typed everything correctly, however, this does not give me confidence that my development build will behave the same when published

I do want to mention the precompiled views are great and make a difference; this is a great feature

[Eilon]

Re-opening for consideration.

[Eilon]

Let's make pre-compiled views have a case-insensitive lookup by normalizing the precompiled view names (e.g. ToLowerInvariant). We need to show an error if there are ambiguities (e.g. edit and EDIT) and disallow that at build time.

---

Here was the original idea that we had, but that we can't do. Sad.

1. We'll change to always being case-sensitive (by default), even running locally, even on case-insensitive file systems (e.g. Windows)
2. When locating a view, we'll check if the filename we got back from the file provider matched the input we passed in. If it doesn't match, we show a nice error message saying the problem appears to be the case. The error message should mention the option in (3) to disable this feature.
3. We need to add a RazorViewEngineOption setting to disable this behavior. The error message in (2) should indicate that this option can be used.

[pranavkm]

@DamianEdwards \ @rynowak - do we want a flag that causes us to look up precompiled views in a case sensitive way? I'm not sure it adds a whole lot of value. Also @Eilon says we could always add it in the future if there's a demand for it.

[Eilon]

Per the meeting we had, I'm generally a fan of fewer options, but that we can add them later if needed.

[rynowak]

I agree with this guy.

[pranavkm]

Fixed in aspnet/Mvc@1124eb5

[pranavkm]

Use #136 for further discussion on this issue.

[MNF]

Am I right that #136 and aspnet/Announcements#251 are included in asp.net 2.0 and completed?
If yes, should they be closed?

[Eilon]

@MNF yes they are in 2.0.0, but they are "Discussion" and "Announcement" issues so they stay open for a while. We do periodically close discussion issues, but announcement issues remain open unless they become invalid.