Feasible to support .net 6 and azure functions V4?

[Taci42]

With RazorLight 2.0.0 after converting a project to .net 6 the following code:

...
var engine = new RazorLightEngineBuilder().UseEmbeddedResourcesProject(typeof(TViewModel))
                                          .SetOperatingAssembly(typeof(TViewModel).Assembly)
                                          .UseMemoryCachingProvider().Build();

return await engine.CompileRenderStringAsync("key", html, model);
...

now results in the following exception:

System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.InteropServices.WindowsRuntime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

Is it feasible to fix this issue? The application was working fine with netcoreapp3.1 and azure functions V3.

[jzabroski]

Short answer: This is not a RazorLight issue. This is a Azure Functions customer support issue. Open a case with them and ask them why this doesn't just work out of the box.

Workaround: Don't use in process Azure Functions. They're a terrible architecture. Use out of process hosting via a container.

Long answer:
I don't know. Does Azure Functions V4 support .net 6, really?

To elaborate, I hate the way Azure Functions manages dependencies, and the whole thing is absolutely crazy to me. I absolutely hate getting requests from people to make their RazorLight integration app work with Azure Functions, when I think the problem is strictly on the side of Microsoft building a terrible plug-in architecture for customers.

Here is the worst part: https://docs.microsoft.com/en-us/azure/azure-functions/functions-versions?tabs=in-process%2Cazure-cli%2Cv4&pivots=programming-language-csharp#migrating-from-3x-to-4x

Azure Functions version 4.x is highly backwards compatible to version 3.x. Many apps should safely upgrade to 4.x without significant code changes.

What does "highly backwards compatible" even mean, when code that worked on 3.x doesn't work on 4.x because of a core system library being different? I loath this marketing gimmick, because it pushes the support costs on everyone else, since they don't precisely define what their compatibility scheme is, so it forces customers to run around blaming various vendors for the problem.

I'm not even referencing the library you're asking me to support, so why is it my responsibility to fix Microsoft's terrible architecture? I went to them 2 years ago and voiced my concerns about how bad this was, and how many false positive reports I get across my two open source projects, and I actually got thumbs down'ed by their engineers. Yup. (It looks like the engineers since removed the thumbs down, but they WERE there.)

Here are our dependencies:
https://www.nuget.org/packages/RazorLight#dependencies-tab

Tell me how we're referencing the assembly you're talking about.

[jzabroski]

@Taci42 I updated my answer

[Taci42]

Hi,

Thank you very much for your detailed answer. You are right, there's no direct reference to the assembly that fails to load.
Looks like the reference is hidden deep in the dependency graph.

Anyway, I have added

<_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>

to the project file of the Azure function. Now it works, but I am not sure if this is a good solution.

[jzabroski]

You should push Microsoft to fix their terrible system. That's the only good solution. I know ex-Microsoft employees who similarly dislike Azure Functions "modularity" and believe nothing will be done about it because the expectation is it's good enough.

[jzabroski]

I thought about your remark that it is hidden in the dependency graph. I suppose I can create a pre-restore step to generate a lock file, and check that in to source control, so it makes it locally searchable vs. needing to click through all deps. That won't solve the problem but it will make it easier to grok a complaint like this.

[jacekkulis]

If someone looking for working sample I have made some effort to setup it and share it with you, here is my repo.

[jzabroski]

@jacekkulis Does it actually deploy to Azure successfully? Your instructions imply you got it to work through to Azurite (local test environment). Can you provide any insight into what you had to do to make it work? It's not clear you actually uploaded all the code since your unit tests do nothing right now: https://github.com/jacekkulis/razorlight-functionapp-sample/blob/main/tests/Application.UnitTests/UnitTest1.cs

Correct me if I am wrong, but I think what you have done here: https://github.com/jacekkulis/razorlight-functionapp-sample/blob/main/src/FunctionApp/FunctionApp.csproj#L7-L9

Implies that the key is still my answer above, _FunctionsSkipCleanOutput default setting causes lots of problems for people trying to use Azure Functions for the first time with the .NET Core 3.1 (and later) trimming features.