Razor debug information uses relative paths

[wesrupert]

The debug information generated for razor files uses relative paths for source line information. The debugger needs full path information in order to find the file to open.

Example

1. Get the Microsoft C# extension for VS Code
2. Get, restore and build cli-samples/HelloMvc
3. Open HelloMvc in VS Code and create a launch.json (example)
4. Set a breakpoint on Views/Index.cshtml line 4 and launch

Expected

VS Code breaks at the breakpoint and displays locals/watch expressions

Actual

VS Code breaks into no source page and cannot display locals/watch expressions

[Eilon]

@rynowak @NTaylorMullen any ideas?

[rynowak]

This seems like a behavior difference between VS debugger and VS code. I think that using the full path is generally the thing to do. Should be straightforward for us to fix.

[rynowak]

/cc @pranavkm

[pranavkm]

I think we used relative paths because that's what the IFileProvider generally exposes. Using PhysicalPath was discouraged since it's not necessarily always available. We could null coalesce it if it's fixes issues.

[Eilon]

Is there any point to using a relative path from an IFileProvider? The debugger won't be able to use that path anyway. I think it makes sense to use the Physical Path if it's there, and use nothing if it's not. No?

[pranavkm]

I guess. VS didn't have issues with relative paths which is why we stuck to it.

[Eilon]

@pranavkm assuming they happen to be rooted at the app root. But if they don't (e.g. my PhysicalFileProvider points at "~/AppContent/") and my Views are in there, does it find them?

[dougbu]

Suspect VS makes little use of the paths we provide. Doesn't VS cache file hashes for everything in the project and use them as its primary identifier when debugging?

[pranavkm]

@Eilon, self assigning this for 1.1.0.

[Eilon]

@pranavkm any plans for this? Is it still needed? What is still broken?

[pranavkm]

I had a set of PRs for this change - aspnet/Mvc#5112. Making this change required introducing a new host since the current interface doesn't allow for a way to pass in both the relative path and the absolute path both of which are currently required during view compilation. (The former is used to discover _ViewImports). When we discussed this last, @rynowak thought it would be better to address this as part of Razevolution, which would require yet another host contract, rather than fixing this piecemeal.

[Eilon]

@pranavkm ok, moved this to 1.2.0.

[pranavkm]

This was fixed with the move to Razor-Evolution. We use absolute path in the generated code (as long as it's available). See https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Razor/Internal/RazorCompilationService.cs#L105