Method 'WriteTo' does not have an implementation #450
Comments
|
I have just started experiencing the same exception running in Azure Functions, was just trying to figure out what changed. It looks like it wasn't a change of the functions runtime version. I also didn't update RazorLight, been running RC3 for a while. I can't reproduce it locally. Are you by any chance running it in Azure Functions? As my first instinct is it could be something they're doing - although I have set the Mine is occurring in Azure Functions on Windows, .Net Core 3.1, RazorLight 2.0.0-rc3 |
|
Mine is occurring in AZ Functions local SDK on Windows, not occurring on az servers (yet). This is my csproj header: |
|
What framework is your func.exe running against? |
|
I added the following code to my initialization method And this is the result: |
|
Can you give me these files: runtimeconfig.json |
|
runtimeconfig.json.txt |
|
Here's my latest startup event showing functions runtime <Event>
<System>
<Provider Name="IIS AspNetCore Module V2"/>
<EventID>1032</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>Keywords</Keywords>
<TimeCreated SystemTime="2021-06-28T23:11:12Z"/>
<EventRecordID>792258250</EventRecordID>
<Channel>Application</Channel>
<Computer>webwk000002</Computer>
<Security/>
</System>
<EventData>
<Data>Application 'C:\Program Files (x86)\SiteExtensions\Functions\3.0.15961\32bit\' started successfully.</Data>
<Data>Process Id: 8368.</Data>
<Data>File Version: 13.1.21133.16. Description: IIS ASP.NET Core Module V2 Request Handler. Commit: 7e8bbb70b266b2fdaf0b11ec47fb3077761fb6bf</Data>
</EventData>
</Event>I just have function.deps.json.txt and extensions.json.txt if they're any use. |
|
I think the right way to solve this problem is to get the function.deps.json.txt for the version that is breaking and the prior version of the func.exe SDK and diff the two, as that will likely show where the issue is. Unfortunately, package search engines like nuget.org dont let you easily query when a method went missing. |
|
The key difference in mine looks like Azure.Core bumped from |
|
I downgraded So how can Azure.Core have this effect? And should we be creating an issue there? |
|
Having exactly the same problem as @darnmason . |
|
I'm not sure but it probably has something to do with the order in which assembly binding occurs. To confirm you will need to turn on logging. |
|
What logging do I need to turn on @jzabroski could you please specify the steps you think will help? |
|
I had contributed documentation to this probing page because I was getting a lot of tickets about assembly binding issues, mostly from Azure Functions customers. If you have a long lunch break and need to be bored to death, you can read the PR conversation which is somewhat interesting: dotnet/docs@160ab22 |
|
I can see some references to Does it make any meaning to you @jzabroski |
|
Yes, it likely means that it is loading Microsoft.AspNetCore.Html.Abstractions 3.1.13 Assuming you are using the latest official rc https://www.fuget.org/packages/RazorLight/2.0.0-rc.3 , you can see we are linking to 3.1.5, so that will blow up. The problem is that "roll forward" technology does not work at runtime, I think (but am not 100% sure about that, but I would wager that is true). So, in the old days of .NET, binding Redirects would work across compile time and run-time, so you would say 0.0.0.0-12.0.0.0 -> 12.0.0.0. But with roll forward, it is all statically linked by the compiler once, and then rolled forward to the latest SDK target at the time dotnet run occurs, UNLESS you do a framework dependent deployment. HOWEVER, as you can infer, since a lot of people are running this in Azure, I dont think there is a way to run framework dependent deployment in Azure (but I use AWS and am definitely not an expert in selling Azure solutions to my clients, however rich it would make me). |
|
At this time at least for me it is working well in azure servers. This affects me only when using the local func.exe tool. Questions for you @jzabroski:
|
Some people were not happy with how I packaged 2.0.0 binaries in a .NET Core 3.0 context, but I explained that as a trade-off relating to Microsoft's decision to remove ASP.NET Core binaries from nuget and shipping them as an SDK that resides locally on disk, and the workaround would be to use their experimental tree shaking and do self-contained deployments. But that creates its own black hole of problems, since I don't personally feel the whole MSBuild SDK concept was particularly well designed. If you search GitHub, I argued that SDKs should be injectable dependencies, and the way target frameworks were designed was simply wrong. Warts like these are a symptom, but I doubt anyone at Microsoft deeply cares about 100% modular software and SDKs. The focus is more on optimization and efficient binaries, as that is directly mappable to economic benefits like higher operating margins for Azure. (Just my own 2 cents). |
|
The The issue persists. I compared both versions 3.1.5 and 3.1.13 (decompiling using JustDecompiler tool) and it seems |
|
Is it using the version from func.exe itself, or from your current SDK on your disk. I am not super familiar with func.exe. Is it a self-contained deployment, or is it rolling forward to the latest patch version? func.exe itself should have a deps.json file in its exe directory, as well as runtimeConfig.json i think |
|
See attached both deps and runtimeConfig |
|
func.exe is loading 3.1.13, for sure: I don't think there is a great solution here. I had spoken to Immo Landwerth about these types of modularity problems, and I think it never got addressed (although I do think he wanted to at least respond to my comments if not address the issue). In java, they have a "bind" tool that does co-constraints the guarantee a single binary version is loaded. It's not great but it's basically what is needed to solve run-time dependencies. |
|
I think the problem is not exactly to load 3.1.13 as I can successfully create a "hello world" simple project using that version. I think the problem lives on indirect dependencies when a project starts to get large. In my prod case RazorLight is referenced on a NETStd20 project, which seem to have a lower requirement than the netcore3.1 entry point project. |
When you create a direct dependency, you opt in to roll forward. When you have an indirect dependency, it does not. So I believe we are saying the same thing. The problem is that Roll Forward is based on the host executable. So you can create your own host and even specify Roll Forward LatestMajor, and it will Roll Forward that. But if you then dynamically load a different DLL version, Roll Forward doesnt know about that. The AssemblyLoadContext is literally just loading whatever DLL you give it. When that Assembly is unique, it will load correctly, but then calling functions in that assembly may fail if it transitively references another DLL with different version than one already in the AssemblyLoadContext. Hope that is clear. This is pretty complex stuff and nobody likes to admit how complex Microsoft made this. Unofficially, Microsoft's preference is people stop using anything that requires reflection/dynamic code loading and instead use C# Source Generators, as that opts in to the upstream gadgetry of MSBuild SDKs calculating the transitive closure of all static dependencies via ProjectReference and PackageReference, Roll Forward technology, etc. |
|
@jzabroski Thanks for your explanation. |
|
I'll see if I can find some time to play with func.exe. |
|
Can you do me a favor and report your |
|
Also, while you wait for me, can you try just setting I also noticed this documentation - with .NET 5, Azure Functions added a new feature called Isolated Azure Functions which seems like a nicer architecture to me (at a quick glance) because it doesn't commingle the host with the plug-in. https://docs.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide |
Yeah I saw that I will give a try on Thanks in advance for your kind help :D |
|
BTW, you can actually see Microsoft makes the same point I claim:
In other words, they're saying their original in-process architecture was a really bad idea. :D |
|
|
|
Unfortunately I'm using razor on a Durable Function, which is not yet supported by the isolated process method. :( |
|
Continuing on my investigation here @jzabroski, I created a small "hello world" function project, that works well, and then I started adding some of the dependencies I have on my real project, 1 by 1. It starts to give errors after I add the Video.mp4 |
|
I am not sure, either, just yet. Can you try loading just Azure.Core nupkg and see if that breaks it when its in a netstandard2.0 context. I have a feeling they packaged that incorrectly. The hard part with looking at this stuff, even with Nuget Package Explorer, is you have to know whats supposed to be "in box" vs. "out of box" (OOB) in the System namespace. OOB refers Microsoft-slang word for things that don't ship as part of the SDK but rather ship as nuget packages but live in the reserved System.* namespace on nuget.org - not to be confused with the C# namespace System even though they generally correspond 1:1. Think of it as batteries not included/sold separately. See: https://nuget.info/packages/Azure.Core/1.15.0 - I dont have a firm intuition as to why the OOB version numbers are so inconsistent and its not easy to mentally reason about which SDKs which version is meant to go against. - This has been a longstanding complaint of mine that Microsoft hasn't addressed. |
|
I can see the problem happening when I simply add |
|
@junalmeida Thanks for that info. Based on a quick google search for System.Text.Encodings.Web azure.core error, it looks like if you file an issue with Azure Functions, they will simply close it as "by design" and tell you to use "the worker model":
Did I ever mention how much I dislike Azure Functions and think they're a complete waste of everyone's time? It looks like out-of-process workers fix these problems, though. Unless you want to use durable functions. Then you should probably use the Durable Task Framework as a workaround. - I don't know if it would be a valid workaround but despite both having the word durable in it, there is nothing in common here between durable azure functions and the durable task framework. The guy who created the Durable Task Framework, @samarabbas, quit Microsoft and is basically selling a "low code" distributed computing framework inspired by the DTF. Durable Tasks are also only C# - whereas Durable Functions is supposed to be language agnostic. The "worker model" the Microsoft employee refers to is the out-of-process model we just discussed. See: https://github.com/Azure/azure-functions-dotnet-worker I do think, given Microsoft's rather funny comments that you can't upgrade System.Text.Json even one minor patch number without things breaking, that you should not spend any effort on the "in process" model and instead running everything "out of process." You can see my extended conversation with Microsoft about this, here: dotnet/standard#859 (comment) Basically, we're in this situation because Microsoft decided binding redirects made customer support extremely difficult, because it exploded the number of library-version interactions that might occur. But, they did not solve the user story binding redirects made so easy to solve, which was a hamfisted DSL for resolving run-time assembly conflicts. As far as I can guess, the reason they don't want to solve this is it can't be checked by the compiler, and so it can produce less reliable systems. |
|
Hi, Best regards! |
I think you misunderstood the conversation. It is not possible without dirty loading. Microsoft even said so. They built a plug-in architecture that does not allow safe loading of dynamically loaded plug-ins, including code written by Microsoft. Your only other option is to use out-of-process worker model, because it converts a dynamic plug-in into a static one. Please re-read. Thank you. |
|
I have encountered the same issue too. If i have well understand i must add this line in my csproj and the issue is gone. More info here: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/out-of-process-hosting?view=aspnetcore-5.0 I don t really understand all impacts of this line |
|
@rdhainaut The reason is that it's a general problem with dynamic plug-in architecture that Microsoft has not solved in .NET Core/.NET 5/.NET 6. Who knows if they will ever solve it. That said, the property you're settling there is for IIS , NOT AzureFunctions. I doubt it will work for AzureFunctions. It looks like you can start your journey here : https://docs.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide#net-isolated-project Note that section and the Package References section are requirements. It's pretty involved and clumsy, in my opinion, but it should nonetheless work and the major benefit is you don't have to worry about Azure Functions terrible use of a dynamic plug-in model. The same problem exists for Azure App Services. |
|
@jzabroski thanks for your explanation, your time and the link. Just in case, I have found a workaround to make it works locally. The workaround is to open a windows terminal, This time I have no error :) |
Describe the bug
RazorLight is throwing the following exception when running
engine.CompileRenderAsyncTo Reproduce
It seems like an incompatibility between dependencies, but I couldn't figure out exactly which one.
Expected behavior
It seems the said
WriteTomethod inViewBufferclass is a reference of the interfaceIHtmlContent, in the assemblyMicrosoft.AspNetCore.Html.Abstractions v2.1.0. The weird part is that this nuget package is apparently abandoned, the link to the project points to an archived repository, and I expect to see AspNetCore being on version3.1, not2.1.Information (please complete the following information):
The text was updated successfully, but these errors were encountered: