toddams / RazorLight

Template engine based on Microsoft's Razor parsing engine for .NET Core
Apache License 2.0
1.51k stars 260 forks source link

Razorlight dependency resolution fails in asp.net 4.7.2 #347

Open itniels opened 4 years ago

itniels commented 4 years ago

Describe the bug When calling the RazorLight render methods from a .NET 4.7.2 Web project, it fails to resolve assemblies.

Every time one is fixed a new one arises.. Our system cannot use the packages specific to RazorLight as they are way outdated, so due to the references in RazorLight it cannot be used by Framework 4.7.2.

To Reproduce Create a NETSTANDARD2.0 project with razorlight and call it from a .net 7.7.2 asp.net web application.

I have a full repro on my github here: RazorLightTest

Expected behavior It renders a template.

Information (please complete the following information):

Additional context Hi @jzabroski :) As requested a full repro of this issue as simplified as i can. https://github.com/itniels/RazorLightTest

jzabroski commented 4 years ago

I started to clean up some scenarios related to legacy .NET Framework. In particular, in my local, I have added the fix suggested by someone in #202 . There are a couple of additional fixes needed to guard against spurious behavior on legacy .NET Framework, mostly dealing with making the .NET link-load process happy. End game is to evolve the API so users can more easily configure stuff that is currently hard-coded/inflexible, and then document the knobs. Defaults for knobs will target latest and greatest .NET 5.0.

jzabroski commented 4 years ago

@itniels Why do you have two lines for the same dependency?

https://github.com/itniels/RazorLightTest/blob/8f816632fbe3cac47e862c31211e1d0d155a081c/RazorLightTest/RazorEngine/RazorEngine.csproj#L30-L34

        <PackageReference Include="Microsoft.AspNetCore.Mvc.Razor" Version="2.2.0" /> // DUPLICATE
        <PackageReference Include="Microsoft.AspNetCore.Razor" Version="2.2.0" />
        <PackageReference Include="RazorLight" Version="2.0.0-beta8" />
        <!-- Here to satisfy intellisense -->
        <PackageReference Include="Microsoft.AspNetCore.Mvc.Razor" Version="2.1.0" /> // DUPLICATE
itniels commented 4 years ago

@jzabroski Ahh so sorry, that was from testing! I updated it now to reflect what i used.

    <ItemGroup>
        <!-- RazorLight -->
        <PackageReference Include="RazorLight" Version="2.0.0-beta8" />
        <!-- Here to satisfy intellisense -->
        <PackageReference Include="Microsoft.AspNetCore.Mvc.Razor" Version="2.1.0" />
    </ItemGroup>
TheWrightDev commented 3 years ago

@itniels Were you able to work around this at all? We have a 4.7.2 project we'd like to use with RL, but ran into the same issue.

jzabroski commented 3 years ago

I think the fix is to have netstandard2.0 use the pre-FrameworkReference code. I'm still on vacation but will look into this next week. (FrameworkReference didn't exist until netstandard2.1 IIRC, as .NET Core pretty much only supported framework dependent deployment prior to intro of TFMs netstandard2.1/.netcoreapp3.0)

itniels commented 3 years ago

@itniels Were you able to work around this at all? We have a 4.7.2 project we'd like to use with RL, but ran into the same issue.

Hi @TheWrightDev, I did not no, we put the project on ice for a bit.

0Neji commented 3 years ago

Hi, was there ever any progress on this? We're looking to use this on an Umbraco 8 project which requires 4.7.2 and I'm seeing the same error.

jorn1 commented 3 years ago

RIP Umbraco Developers

jzabroski commented 3 years ago

Didn't understand that last comment. Is Umbraco using RazorLight?

Edit: Nevermind, i see the person wanted to see about using it with Umbraco 8.

I think the fix is to have netstandard2.0 use the pre-FrameworkReference code. I'm still on vacation but will look into this next week. (FrameworkReference didn't exist until netstandard2.1 IIRC, as .NET Core pretty much only supported framework dependent deployment prior to intro of TFMs netstandard2.1/.netcoreapp3.0)

@toddams We had discussed this on our LinkedIn chat awhile ago - do you feel comfortable if we make this change?