IncludeAsync should not default to ".cshtml"

Describe the bug

When you use IncludeAsync along with embed resource provider, it will always append .cshtml to the end of the key. I’m trying to include a CSS file to embed it inside the page, but I can’t, unless it ends in .cshtml.

To Reproduce Steps to reproduce the behavior:

@{ await IncludeAsync("Core.css"); } // tries to include "Core.css.cshtml"

Expected behavior

Should properly include Core.css instead of trying to resolve Core.css.html.

Information (please complete the following information):

• OS: Win10 x64
• Platform .NET Core 3.1
• RazorLight version 2.0-beta9
• Are you using the OFFICIAL RazorLight package? yes
• Rider 2020.1.3

Additional context Add any other context about the problem here.

[jzabroski]

FileSystemRazorProject.Extension was marked as virtual, and had a DefaultExtension value, which could be configured via constructor.

EmbeddedResourceRazorProject.Extension was not marked as virtual, and had an explicit default value of “.cshtml”. I suppose you could override this by sub-classing EmbeddedResourceRazorProject and defining a different default in that constructor, but that is very ugly.

End-game is to true these up. Both project types should support constructors where you pass in the default extension, and tests should cover that it is ok to pass in an string.Empty value for default extension. In that case, View.css should work (I hope)

[jzabroski]

I’m not sure exactly how StyleTagHelper works, so maybe it would also solve the problem.

On-Topic: You’d just define a StyleTagHelper with a custom razorlight-src helper attribute that would let you write:

<style razorlight-src="View.css" />

and it would internally call the equivalent of IncludeFileContentsAsync effectively.

Off-topic: I have various ways I’ve loaded CSS into web pages over the years. By far my favorite conceptually was when I was using RequireJS AMD with the requirejs/text plugin, as it enabled me to build TypeScript components that fully packaged a ViewModel, html template and css in a modular way that avoided including the same CSS multiple times. It also was nice in that it made it clear that a component had some assumptions on how it was styled, so the html piece and css piece had clear contracts with the overall component. This had the added benefit I could create an arbitrary MVC endpoint that would just… load a TypeScript component given some jsonConfig. I personally think moving away from such paradigms is a mistake, but as I get older, I’m less rebellious and more compliant with what everyone else is doing.

@jzabroski thanks for getting back about this!

No problem. I just wish I had more free time to just code for fun and work on these projects. While I use these projects professionally, I never knew people had so many diverse use cases.