Partial Views referenced with relative paths are not recompiled after changing the .cshtml

[rihei]

It seems that when a partial view is referenced in ASP.NET Core MVC 1.0.1 by a relative path (../), changes to the partial view's .cshtml file require a build to take effect. Normally saving the changed .cshtml file and reloading the page in browser are enough to make the changes visible.

Minimal project to reproduce this: https://github.com/rihei/aspnetcoremvc-partialview-relativepath-bug/

In the test project, there are two partial views (one in Other folder and one in Shared). First prints "1" and second "A". When I edit them to print "2" and "B" instead, save the files and reload the page in browser, the relatively referenced partial views don't change. The same file referenced differently on the same page shows the new content instead.

[dougbu]

Terminology: It's a bit strange but MVC performs view location expansion on view names such as "../Shared/_TestSharedPartial" i.e. they are names and not paths. The .cshtml suffix controls whether the given string is treated as a view name or a path. Paths are either absolute or relative, depending on whether they start with "/" or "@" (after canonicalization) or not.

Using the above terminology, view caching is working correctly for simple view names and absolute paths. But, both relative paths and more complicated view names confuse the system. Makes me wonder if the problem is the ".." portion of the names / paths you're testing.

@pranavkm ??

[pranavkm]

Perhaps there's an issue with the watcher triggering on the resolved path versus Mvc listening on the unresolved path. I'll have a look.

[pranavkm]

My hunch was right - IFileProvider.Watch registers a token for the file with the path given as is i.e. Views/Home/../Shared/_TestSharedPartial.cshtml which then fails to match when an event is raised for Views/Shared/_TestSharedPartial.cshtml (since those are just exact matches). It's essentially the same issue as aspnet/FileSystem#248.

That said, perhaps we use this as a reason to address the other .. issues in the view engine: aspnet/MvcPrecompilation#33. We should certainly fix aspnet/FileSystem#248, but if we invoke Watch using normalized paths, we wouldn't have seen this issue here. Thoughts @Eilon

[rihei]

This bug still seems to be present in asp.net core 2.0.1? Has the fix been published?

[pranavkm]

@rihei the issue should have been fixed in 2.0.0. Is https://github.com/rihei/aspnetcoremvc-partialview-relativepath-bug/ still a good sample that reproduces the problem?

[rihei]

I updated the sample project to the newest versions, and investigated a bit more. The problem seems to be partly fixed: relative path to a partial view now works if the ".cshtml" extension is present in the path. The view still doesn't show the changed content if the partial view is referenced by relative path and no ".cshtml".

Here I have first set the two partial views to print "1" and "A", then started the project and loaded the view in the browser, then edited them to print "2" and "B" and reloaded the browser view. The same partial produces different content based on how it's referenced. Wrong kind of reference shows the old content, even though the very same file produces new content on the same page when referenced the right way.

[pranavkm]

@rihei we made further changes to the look up behavior as part of the (yet to be released) 2.1.0 release. See #6672. For the 2.0.0 release, you must have an cshtml extension for the view engine to treat the string as a path (and not a name to look up).

[rihei]

Ok, I expect this to be fixed in 2.1.0 then. Thank you! At the moment you cannot notice that a reference is somehow wrong until the site is already running and edits to the partial view don't take effect.