In theory, NCrunch should support any source file that has debugging information present in the output PDB file.

In practice, we've never tested this with razor files. I honestly didn't know it was possible to build such a structure.

Could I convince you to provide us with a small sample project that demonstrates how you've done this? We should then be able to look into the behaviour of the engine and establish whether this can be fixed with a small patch or whether it will require a large amount of work. You can submit small code samples through the contact form.

Thanks for sending through the code sample.

I've managed to identify the source of the problem here. The build system is reporting the .razer file as being a Content file rather than a Compile one. This breaks conventions inside the build system as it means the file doesn't pass through a number of build steps. Probably they've done it this way to prevent it being picked up by the CSC/VBC compiler in the expectation that its IL will be injected into the assembly by another task further downstream.

I can think of no way to work around this problem with the currently released version of NCrunch. Any way we identify the file as a compile target would also result in your build being broken.

With .NET Core 3.0 still being in a preview state, it's difficult for us to reliably make changes in this area without destabilising things. I've noted this down to be looked at in detail after the release of .NET Core 3.0. There may be some way for us to identify these files as being compile targets internally without passing them into the compiler. This would allow us to highlight their code as we do with other source files. Sorry .. you'll need to deal with broken NCrunch code coverage and navigation in the files until we can find a reliable way to fix this.

Would you be interested in trying the build below to see if this solves the problem for you?

NCrunch_Console_3.31.0.5.msi
NCrunch_Console_3.31.0.5.zip
NCrunch_GridNodeServer_3.31.0.5.msi
NCrunch_GridNodeServer_3.31.0.5.zip
NCrunch_LicenseServer_3.31.0.5.zip
NCrunch_VS2008_3.31.0.5.msi
NCrunch_VS2010_3.31.0.5.msi
NCrunch_VS2010_3.31.0.5.zip
NCrunch_VS2012_3.31.0.5.msi
NCrunch_VS2012_3.31.0.5.zip
NCrunch_VS2013_3.31.0.5.msi
NCrunch_VS2013_3.31.0.5.zip
NCrunch_VS2015_3.31.0.5.msi
NCrunch_VS2015_3.31.0.5.msi.7z
NCrunch_VS2015_3.31.0.5.zip
NCrunch_VS2017_3.31.0.5.msi
NCrunch_VS2017_3.31.0.5.msi.7z
NCrunch_VS2017_3.31.0.5.zip
NCrunch_VS2019_3.31.0.5.msi
NCrunch_VS2019_3.31.0.5.msi.7z
NCrunch_VS2019_3.31.0.5.zip

The above build contains a fix that should allow the markers to render inside .razor files, which are reported by the build system as being content files (not code). So it contains a workaround to represent these files differently.

Note that this build doesn't introduce any build support for projects that are referencing the Blazor Nuget packages. It seems that some of the Blazor Nuget packages make critical changes to the build system that prevents the .NET Core .deps files from being generated. These files are needed to produce a runtime environment that can host test code, hence there are downstream problems. The code sample you submitted demonstrating your reported problem simply won't build in NCrunch when adapted to the later preview release of Blazor, and it's unlikely that we have a way to fix it. You may need to rethink the structure of your test project. The new Blazor project template under VS2019 seems to work OK.