Closed ascott18 closed 1 year ago
I am not going to consider this. I am sorry that this happened to you, and happy for you that you found a workaround.
Directory names can and do contribute to uniqueness. If you need a way to debug embedded templates, I suggest using file system projects instead. There is no such thing as debugging embedded resources anywhere in .NET. If you are using .NET Core, you can use the File Provider API and your code will be less odd than the one you proposed: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/file-providers?view=aspnetcore-7.0#manifest-embedded-file-provider
If you simplify this approach using the manifest embedded file provider, perhaps I will consider a PR, but this initial post has me quite skeptical.
Thanks for the follow-up. I'm checking with my team to see if there's a specific reason why embedded templates were used in this case rather than pulling from the filesystem, as I didn't write the original implementation.
Thanks again for taking the time to look into this. There was indeed no reason for the project to being using manifest embedded templates rather than filesystem-sourced templates.
Describe the bug In RazorSourceGenerator,
RazorSourceDocument.ReadFrom
is called withprojectItem.Key
as the fileName. When an embedded resource exists in a nested directory in the project (which, it almost always does), this key looks something like "Views.File.cshtml". Unfortunately, this then prevents the debugger from correlating the generated C# to the original source file on disk.If the file name were to be passed as the actual file name on disk (directory is not needed, e.g. just "File.cshtml"), the debugger works as expected and you can set breakpoints in your templates.
To Reproduce Steps to reproduce the behavior:
string result = await engine.CompileRenderAsync<object>("Views.File", model);
Expected behavior Breakpoint is hit.
Information (please complete the following information):
Additional context
I realize that its impossible to 100% correctly deduce the filename from an embedded resource because directory slashes become dots. What would be nice is an additional, overridable property
FileName
onRazorLightProjectItem
whose default implementation isKey
, and on EmbeddedRazorProjectItem its implemention is something likestring.Join('.', Key.Split(".").Reverse().Take(2).Reverse())
(i.e. assume that the file name on disk contains no dots other than the extension, which will be correct most of the time and at least be more correct than it is now). Custom implementations can then create their ownEmbeddedRazorProject
implementation and set theFileName
according to their own logic, if needed.This is our workaround for this, which is the closest I can get without a dedicated
FileName
property that is used by RazorSourceGenerator. This does make debugging function correctly: