Statiq.Framework
Statiq.Framework copied to clipboard
Debugging a Razor CSHTML file
I'm having a bit of trouble debugging a CSHTML file - basically Visual Studio is saying the symbols aren't loading for it when I'm debugging my application. This happens when I add a breakpoint in the file itself.
I'm guessing this relates to how the CSHTML files are compiled by Statiq but I'm not entirely sure. The files in the Razor cache folder are loaded in the assembly but symbols are skipped because the module is optimized.
Also would be handy to be able to put breakpoints in csx files
I managed to get a breakpoint to be hit in Visual Studio in a cshtml file. Did you install the ASP.net support via Visual Studio installer? And did you debug from Visual Studio? I also set command line argument in the project settings "--attach --debug". Not sure if that also made a difference.
Could not get breakpoints to be hit in csx file though.
Well it looks like the build of the cshtml is optimized when looking at the Modules list in Visual Studio.. so the debugging experience is not great. Not sure if there is a way to get Statiq not to optimize them. Might also be nice if the names of the generated assemblies had a prefix with the original script name or something as the assembly names are rather cryptic.
I can't see the optimization level being set anywhere in Statiq source code. Would be great if could run with a flag to set this. Or perhaps the --debug flag. https://github.com/dotnet/roslyn/blob/main/src/Compilers/Core/Portable/Compilation/OptimizationLevel.cs
@petebannister Some great suggestions and research here. I'm going to take a look at both making the assembly names more obvious and not optimizing the assemblies.
I'm also wondering how Visual Studio knew how to map the dynamic assembly to the originating .cshtml
file in the first place. As far as I know that's not set anywhere (though maybe the internal Razor engine does some sort of association magic?). I'm actually not familiar with how this file-to-module association works for normal assemblies either, so might need to do some research.
Old thread but...
After some investigation, trial and error.. I found that, if you add System.Diagnostics.Debugger.Break();
instead of the breakpoint.. kinda works... you can inspect the objects....
You'll be prompted to select the file and confirm you want to debug a different source...
The breakpoing shows in a different place...
but works.. kinda...
Another alternative is the old console.log
Console.WriteLine()
or @Html.Raw()
and output stuff... to the page...