RazorLight requires ASP.NET Core runtime

[Tyrrrz]

Describe the bug

Because RazorLight has a FrameworkReference to Microsoft.AspNetCore.App, the user is expected to have the corresponding runtime. This is a show stopper for console or WPF apps as users of those will not have it installed (and shouldn't need to).

To Reproduce

1. Create a WPF app
2. Add RazorLight
3. Publish it
4. Try running on a machine where neither ASP.NET Core runtime nor SDK is installed

Expected behavior

It should work with just the base .NET Runtime.

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

[jzabroski]

@Tyrrrz How should it work instead?

[Tyrrrz]

Well ideally it shouldn't depend on ASP.NET Core runtime because in the majority of cases you would want to run it outside of an ASP.NET Core environment. Taking dependency on an entire framework kinda clashes with the idea of it being a light and independent Razor engine.

[jzabroski]

@Tyrrrz I think you're misunderstanding my comment. You're asking for support for your specific deployment scenario but not providing me with your csproj PackageReference(s), etc. I take it your problem is in the master branch here: https://github.com/Tyrrrz/DiscordChatExporter ? The notion that a WPF app needs to be "published" also indicates there is something else going on beyond just using WPF.

RazorLight can run on .NET Core without ASP.NET Core. Some people have had success (somehow) running it on legacy .NET Framework. But it should run on .NET Core without ASP.NET Core, since that is the main use case: e.g., from a console app, send emails using RazorLight email templates.

[Tyrrrz]

@Tyrrrz I think you're misunderstanding my comment. You're asking for support for your specific deployment scenario but not providing me with your csproj PackageReference(s), etc. I take it your problem is in the master branch here: https://github.com/Tyrrrz/DiscordChatExporter ? The notion that a WPF app needs to be "published" also indicates there is something else going on beyond just using WPF.

Yes, that is correct. I'm not asking for support with my deployment, I'm letting you know about this behavior, which I assume is not intended.

Not sure what you mean by "something else going on beyond just using WPF". It's not about WPF, the same can be observed with console applications. Just to clarify, by "publishing" I'm talking about dotnet publish.

It can run on .NET Core without ASP.NET Core, but only if ASP.NET Core Runtime or SDK is installed. If you're testing on your dev machine, you will have it installed.

By using FrameworkReference (as in here:

RazorLight/src/RazorLight/RazorLight.csproj

Line 38 in cc9ab96

<FrameworkReference Include="Microsoft.AspNetCore.App" />

), you're referencing a shared framework. It doesn't resolve to some NuGet package (it simply doesn't exist), but instead it expects the runtime with all the required libraries to be installed where the application is running.

This problem seems to have appeared starting from 2.0.0-beta2.

[jzabroski]

Got it. Thanks for that help. Very helpful.

I got involved after 2.0.0-beta2, so it makes sense I was unaware of this disconnect.

[jzabroski]

The other remark I have here is that FrameworkReference(s) are supposed to be installed locally. It's also a misnomer to say RazorLight depends on the runtime; it depends on the framework, not the runtime. We only load the assemblies we need (although I shoud write an integration test to verify this behavior, as, to your point, it defeats the purpose if it doesn't)

[Tyrrrz]

It's also a misnomer to say RazorLight depends on the runtime;

These are mostly the same when it comes to .NET. By depending on the runtime, I mean that the end users need to have this installed:

[jzabroski]

This may be a gap in my knowledge, but isn't the correct term for those runtimes in the screenshot a "Runtime Pack"? In other words, the runtime is the actual VM. The Runtime Pack is the core dependencies. Both Desktop Runtime (Pack) and ASP.NET Runtime (Pack) still have dotnet.exe as an entry point. The whole of what FrameworkReference does is to allow GAC-like behavior so we're not installing all these dependencies several times via "Framework-Dependent Deployment". Microsoft employee Nick Guerrera wrote the design for this feature for .NET Core 3.x, including how RollForward works.

[Tyrrrz]

Haven't heard the term "Runtime Pack", but maybe. The point is that, in order to use a project that references RazorLight, the end user needs to have ASP.NET Core Runtime installed, in addition to other runtime they would otherwise need. Normally, if it's just a console application, they only need the base runtime. Similarly, if it's a WPF or WF application, they would only need a desktop runtime. With RazorLight, they will need ASP.NET Core Runtime (which contains base) or ASP.NET Core Runtime + Desktop runtime (which is not contained within ASP.NET Core Runtime). The VM and dotnet.exe are distributed with all of them, but they differ in the libraries, like you mentioned.

[jzabroski]

I do understand your point, I am just describing my understanding of the issues and why they arise, so that I can backtrack to what the most elegant solution is (unless you already have a solution in mind that works). Because the idea of removing FrameworkReference somewhat flies in the face of my understanding of how things should work. The other idea is that this is why I created #299 , because there are so many deployment scenarios to truly regression test against that maintaining high quality is quite tricky. I even bought a Mac Mini three weeks ago for $100 to troubleshoot some issues with building on Mac, because Apple doesn't support docker containers.

[Tyrrrz]

It's not entirely clear how to best solve it, especially since RazorLight could also be used from ASP.NET Core context. Ideally, if you could reduce the dependencies just to Microsoft.AspNetCore.Razor.Language and Microsoft.CodeAnalysis.CSharp, that would solve it, but I assume RazorLight depends on other parts of ASP.NET Core as well.

[jzabroski]

I believe that there are parts of the infrastructure that are effectively tightly coupled to the runtime pack itself, like Antiforgery token. I never dug into why exactly but it is what it is. I know that some of the leaders on Microsoft's front have improved the modularity in some respects but also made it more tightly coupled in other areas (e.g., to reduce misconfiguration issues and cut down on combinatorial explosion in "configuration test" cases).

[toddams]

There is definitely a way to get rid of shared framework, as I remember, FrameworkReference got here from some contributor in order to solve some bug or smth.

[jzabroski]

@toddams I looked at the blame and you're right. Should be easy fix. I will do it this weekend.

[jzabroski]

@Tyrrrz @toddams Just an update on this.

I think I almost got this all fixed.

The remaining error I am a bit stumped by and need to push through to figure out why its not working is this:

Severity Code Description Project File Line Suppression State
Error CS1061 'IHostBuilder' does not contain a definition for 'ConfigureWebHostDefaults' and no accessible extension method 'ConfigureWebHostDefaults' accepting a first argument of type 'IHostBuilder' could be found (are you missing a using directive or an assembly reference?) RazorLight.Tests (netcoreapp3.0), RazorLight.Tests (netcoreapp3.1) D:\source\GitHub\RazorLightPRs\tests\RazorLight.Tests\Extensions\ServiceCollectionExtensionsTest.cs 93 Active

I found this StackOverflow post, but the advice (use Sdk="Microsoft.NET.Sdk.Web") doesn't seem to help us with a test project: https://stackoverflow.com/a/58097655/1040437 However, I do not understand WHY the Sdk project type must be <Project Sdk="Microsoft.NET.Sdk.Web"> - this especially doesnt make sense for RazorLight.Tests.csproj