View imports not carried into generated files

[naasking]

Not a huge deal, just a little unexpected. I have a _ViewImports.cshtml that has:

@using RazorBlade

This lets me write this template that without any IDE errors or warnings:

@inherits HtmlTemplate

But trying to compile fails:

error CS0246: The type or namespace name 'HtmlTemplate' could not be found (are you missing a using directive or an assembly reference?)

Basically, all RazorBlade types within a template need to be fully qualified despite the fact that _ViewImports.cshtml imports that namespace. Another case I ran into was a template that returned an HtmlString:

@inherits RazorBlade.HtmlTemplate
@(new HtmlString("<span>foo</span>"))

Same problem:

 error CS0246: The type or namespace name 'HtmlString' could not be found (are you missing a using directive or an assembly reference?)

Fully qualifying it as RazorBlade.HtmlString("foo"). Like I said, not a huge deal but unexpected given the standard idioms for razor.

[naasking]

I'm porting over some code for RazorSlices, so I might discover a few more issues as I go. This namespace issue becomes more problematic when the template invokes extension methods. Since the namespace isn't imported obviously the extension method won't work as expected, so it too has to be fully qualified and invoked as a static method. So instead of:

foo.SomeMethod()

It would have to be:

Fully.Qualified.Namespace.Class.SomeMethod(foo)

[ltrzesniewski]

I didn't plan to add _ViewImports.cshtml support, as I wanted templates to be independent. Imports make more sense in a full ASP.NET app than in a generic library, so any special behavior for files starting with an underscore was not implemented on purpose.

But if you expected view imports to work and the IDE additionally misleads you, that becomes a problem... Yet I'm not sure I want to introduce this kind of special behavior and implicit dependencies between cshtml files because of this, I'll need to think about it. A primary goal of this library is to remain as simple as possible.

I'm porting over some code for RazorSlices, so I might discover a few more issues as I go.

Sure, please report them. 🙂

Also, may I ask why you're porting from RazorSlices (which seems to be designed to be used in ASP.NET) to RazorBlade (which explicitly cannot be used with it) in an ASP.NET app? 😅
I'm genuinely curious.

Since the namespace isn't imported obviously the extension method won't work as expected, so it too has to be fully qualified and invoked as a static method.

Extension methods should work if you add the necessary @using (but I understand the trouble if you have to add many of these).

[naasking]

Also, may I ask why you're porting from RazorSlices (which seems to be designed to be used in ASP.NET) to RazorBlade (which explicitly cannot be used with it) in an ASP.NET app?

I do have some projects in mind in the future, but I'm just playing around with various options using ASP.NET minimal APIs. I have a tailwind dashboard theme that I'm turning into a sort of reusable component library using RazorBlade, RazorSlices, and Razor components. They all work fine so far, each with strengths and weaknesses. This is mostly straightforward with Razor components and the markup looks nice, but it's complex, heavy and actually has some surprising limitations.

Razor Slices and Razor Blade are both good, and look more like classical ASP.NET MVC compared to razor components (at least the way I'm doing it so far), but still very readable and very fast. The structure is simpler so far with RazorBlade because it has a more straightforward synchronous rendering pipeline.

I get not wanting to complicate your maintenance load with supporting broader use cases, I'm just putting it out there in case you are interested.

Extension methods should work if you add the necessary @using (but I understand the trouble if you have to add many of these).

Adding @using to every file does work, but obviously for the case I was described above it seems like unnecessary repetition given the idioms I'm used to, and as the IDE didn't show anything strange it took me a few minutes to puzzle out what was going on. Intellisense is also a bit spotty. I don't care about the other underscore files, I think global namespace imports are the only convenience I'd miss using this component approach. Thanks for considering!