microsoft / durabletask-dotnet

Out-of-process .NET SDK for the Durable Task Framework
MIT License
111 stars 33 forks source link

New Class-Based Syntax for Azure Functions is not working (Error CS1061) #136

Open mdddev opened 1 year ago

mdddev commented 1 year ago

Hello,

I just gave this sample a go. I copied the content 1:1 in a new file in my Azure Functions project. I have also included a reference to the Microsoft.DurableTask.Generators package version 1.0.0-preview.1.

However, VS complains that no such extensions methods, like e.g. CallSayHelloTypedAsync(), can be found. Basically I am unclear if the generators, supposed to generate exactly that, have run or not. How would these be triggered to run?

Error CS1061

'TaskOrchestrationContext' does not contain a definition for 'CallSayHelloTypedAsync' and no accessible extension method 'CallSayHelloTypedAsync' accepting a first argument of type 'TaskOrchestrationContext' could be found (are you missing a using directive or an assembly reference?)
mdddev commented 1 year ago

PS

I just noticed the following output when building, it explicitly states, that it failed to generate source...

CSC : warning CS8785

Generator 'DurableTaskSourceGenerator' failed to generate source. It will not contribute to the output and compilation errors may occur as a result. Exception was of type 'InvalidCastException' with message 'Unable to cast object of type 'Microsoft.CodeAnalysis.CSharp.Symbols.PublicModel.ArrayTypeSymbol' to type 'Microsoft.CodeAnalysis.INamedTypeSymbol'.'
mdddev commented 1 year ago

@jviau , thanks for clarifying this. Is there some workaround or mitigation I can do on my part?

jviau commented 1 year ago

@mdddev unsure if there is any workaround right now, I would need to investigate this further.

mdddev commented 1 year ago

@mdddev unsure if there is any workaround right now, I would need to investigate this further.

Thanks @jviau , that would be much appreciated. Strongly-typed orchestrator and activity functions are an awesome feature, an I'm eager to give these a go. Again, thanks your efforts!

mdddev commented 1 year ago

@mdddev unsure if there is any workaround right now, I would need to investigate this further.

Thanks @jviau , that would be much appreciated. Strongly-typed orchestrator and activity functions are an awesome feature, an I'm eager to give these a go. Again, thanks your efforts!

Hi @jviau , may I ask if you have had the opportunity yet to do some digging on the topic? 😅 I am really eager to try this out and if there is any chance there is workaround I could implement on the user-side, this would be awesome.

jviau commented 1 year ago

@mdddev, sorry not yet. Ideally, I am waiting for some changes to the functions dotnet worker extensibility model. These changes would allow us to replace the code-gen approach with a more stable direct registration.

mdddev commented 1 year ago

@mdddev, sorry not yet. Ideally, I am waiting for some changes to the functions dotnet worker extensibility model. These changes would allow us to replace the code-gen approach with a more stable direct registration.

HI @jviau , I was wondering whether there is an update you might be able to share here? Has the blocker (partly) resolved itself?

mdddev commented 1 year ago

Hi, I just checked and the Microsoft.DurableTask.Generators package version has not yet changed and is still on 1.0.0-preview.1. Still, is there any progess to be shared? Is it working and only I am using it wrong somehow? I mean there is official documentation and official samples. Since these have been published I guess it must be working on someone's computer, right?

jviau commented 1 year ago

@mdddev - apologies, no progress has been made on this. Unfortunately, the source gen approach has a dead end to it: you cannot use class-based orchestrations/activities from assemblies that themselves did not have the generator ran for. And that is one of the primary goals of this feature, allowing re-use of orchestrations and activities through libraries (without the generator having to be ran for those libraries).

Instead, we are waiting on a new extensibility point from the functions dotnet worker to allow us to manually register these class-based orchestrations/activities functions at startup. This way we can have a seamless experience between standalone and functions. Until then we do not plan on investing in the source gen approach.

RobARichardson commented 1 year ago

Thanks for the update. My team is looking forward to using Class-based Orchestrations & Activities.

Arithmomaniac commented 1 year ago

Instead, we are waiting on a new extensibility point from the functions dotnet worker to allow us to manually register these class-based orchestrations/activities functions at startup. This way we can have a seamless experience between standalone and functions. Until then we do not plan on investing in the source gen approach.

I suggest this is made clearer in this README section:

IMPORTANT: class based syntax in Durable Functions relies on a package reference to Microsoft.DurableTask.Generators. This is still in "preview" and may be subject to significant change before 1.0 or even post-1.0. It is recommended to stick with function-syntax for now.

Ilia-Kosenkov commented 10 months ago

I will hijack this discussion to ask if there is any update on source-generated (or created otherwise) class-based orchestrations, @jviau . We actually got inspired by this source generator and wrote our own thing for in-process orchestrations, and now are planning to migrate our projects to isolated and cannot imagine going back to plain functions. Will there be anything similar to source-generated functionality available in the near future or should we just port our own generator to dotnet-isolated and not wait for sdk updates?

ssnseawolf commented 1 month ago

@jviau Do you know if .NET 9 unblocks development on replacing the class-based approach? The P2 label tentatively gives me hope.

Appreciated your insight on why this issue has been a problem for your team.

jviau commented 1 month ago

@ssnseawolf no it doesn't. This fix is very involved as we have to switch away from source generation entirely. Doing that depends on a new feature from the dotnet worker, which we have not committed to yet.