.NET Core 3 support aka Razorlight update

[bjcull]

Updated razorlight to beta-4, the web sample to .net core 3.1 and added a full framework console app to demonstrate full-framework implementation.

[bjcull]

Leaving in myget until I can properly test against my prod apps.
https://www.myget.org/F/fluentemail/api/v3/index.json
v2.8.0

[jzabroski]

Let me know if you need any help. Im on keybase.

[Karql]

Hi!

Any updates with this PR?

Regards,
Mateusz

[jzabroski]

@Karql It's on his myget feed but not on nuget.org

[georg-jung]

Are there any plans to go forward with this package on NuGet? Like, is someone already working on it or would it make sense to fork this and have the repo under an organization or something similar? I really like the project but the outdated-ness of the nuget package is a pitty so I'm trying to understand what could be contributed to move forward...

[georg-jung]

While the solution is kind of hackish I created a step-by-step guide to get FluentEmail.Razor running with modern ASP.NET Core 3.x applications as part of my FluentEmail.Postmark project (see the readme there), example included: https://github.com/georg-jung/FluentEmail.Postmark

[lukewarlow]

I have FluentEmail.Razor version 2.7.0 running in ASP.Net Core 3.1. I had errors about references to AntiForgery code iirc, I managed to fix this by adding some lines to my .csproj file.
Hope this is useful. Apologies if this is a different issue.

<PropertyGroup>
        <TargetFramework>netcoreapp3.1</TargetFramework>
        <MvcRazorExcludeRefAssembliesFromPublish>false</MvcRazorExcludeRefAssembliesFromPublish>
        <PreserveCompilationReferences>true</PreserveCompilationReferences>
</PropertyGroup>

[computamike]

The latest version of Razor Light seems to be 2.0.0-beta9 - so should this branch be updated accordingly?

[lukencode]

I am not sure @bjcull is available to finish this one off. Is anyone else able to take it over? @computamike we should use the latest version for sure.

[computamike]

I am not sure @bjcull is available to finish this one off. Is anyone else able to take it over? @computamike we should use the latest version for sure.

I can have a go at taking this pull request and taking it to the latest version

[jzabroski]

Hi, I think the next release of RazorLight I am working on should be the target for this change. See the issues in RazorLight, as there are problems with the beta when targeting .NET Core 3.0 and later that users have reported.

[mpoiron]

Hi,

I used the workaround provided by @georg-jung (thanks !) and installed Razorlight 2.0.0-rc.1, only to stumble on the same error as issue #189. So now I have to use the workaround described on #184 (comment)

Is there any news regarding this PR ? This would solve the problem.

[georg-jung]

Part of the problem could be that an official FluentEmail.Razor 2.8 package was published since I posted the workaround. Thus, you're probably installing that one instead of the one provided by me, when you follow my workaround and that one might lead to the problems you're experiencing. You might want to ensure that you're installing the 2.8 package from my feed and might want to try the exact version of RazorLight that I'm using in my example. If this works for you please leave a short note here.

I'll think about creating a higher-versioned package in the same way so that my workaround works as expected again. Nevertheless it would be great if this would be fixed upstream (-> this PR) of course.

[jzabroski]

I updated RazorLight 2.0.0-rc.1 to 2.0.0-rc.2. However, I am not sure why some pull requests for this project are lingering.

[mpoiron]

Thanks again @georg-jung, my problem was fixed when I downgraded the RazorLight version to 2.0.0-beta7.

[rburnham52]

For reference i had a look at upgrading to the latest version of RazorLight and tried adding support for Default Namespaces. Even the standard System namespaces were not working by default.

I ran into some problems though with RazorLight ignoring the Default Namespaces settings. After a bunch of digging i found out that.

1. This branch changes _engine.CompileRenderAsync to _engine.CompileRenderStringAsync because the signature changed during the upgrade to support .net core 3.
2. FluentEmail seems to handle embedded resources itself using EmbeddedResourceHelper and treats the template as a string. This looks like it is so there is a single common Parse method for any template type.
3. The RazorLight Project used for string templates for some reason ignores default namespaces, see this issue for details
   Default Namespaces does not appear to work toddams/RazorLight#387. This is what is being used by CompileRenderStringAsync

We've decided to go down another path as this would require some core changes to either FluentEmail to use RazorLight Projects based on the template type or a change to RazorLight so it does not ignore Default Namespaces for strings, The answer i got was that they are not sure why it ignores namespaces for strings.

I hope this info comes in handy for anyone trying to upgrade to .net core 3 and fix the default namespace issue