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?