Question: Will there never be support for durable functions and other rich bindings, or just not yet?

[cmenzi]

Regarding this statement:

"One important difference with .NET 5 functions is that "rich bindings", such as Durable Functions or binding to SDK types like Cosmos DB client, are not supported. Use strings and C# objects (POCOs). For HTTP, use HttpRequestData and HttpResponseData objects."

Will there never be support for durable functions and other rich bindings in this out-of-process model, or just not yet? How to continue on this? Do we need to wait for the .NET 6.0 LTS version, when the runtime is supporting this?

[henriksen]

According to @anthonychu on Twitter, durable functions are not in scope for .NET 5. Maybe 6.

This will be the case for the .NET 5 out of process worker for the foreseeable future (GA and beyond). We’re looking at options for .NET 6. Durable Functions is definitely something we want to support.

https://twitter.com/nthonyChu/status/1337178724706394113?s=19

[RichMercer]

I think there's a lot of documentation that's desperately needs updating. I'm leaning heavily on Cosmos change feeds and docs such as this need a huge warning that it's not supported with .NET 5.0. https://docs.microsoft.com/en-us/azure/cosmos-db/change-feed-functions

[wahyuen]

That is a little disappointing to hear to be missing out completely on a whole set of functionality (we heavily utilize Durable Functions for parallel processing).

While admittedly this was our design choice, we (perhaps naively) have a lot of common functionality between our web application and function code (shared models/logic etc), assuming it was a safe bet that ASP .NET functionality would go lock step with Functions. The end result of this is that we either
a) refactor and decouple functions code so that it does not share dependencies with our web code
b) effectively bypass .Net 5 and its features until Functions can support Durable Functions next year??

I know the team does amazing work, and there are likely many factors at play dictating roadmap and timelines. All I can do here is voice a single opinion that I feel the team might have missed the mark slightly in this release :/

[Jandev]

Indeed. Not having support for Durable Functions is the main reason we can't/won't 'upgrade' to .NET 5 for our solutions.

We also have quite a bit of shared code between the two (Web API & Functions). There are probably ways to work around it, but so far it's not worth the time investment.

I do get why it's not implemented at this time. In the meantime playing around with the new runtime is fun, but not with customer projects (at this time). I haven't got a problem skipping a non-LTS release on production systems, but I do know some people who think they 'need' to upgrade to each and every little update available.

[dmytro-gokun]

I wonder if running functions from Docker images will work around all this issues and let us use .NET 5?

[anthonychu]

Durable Functions relies heavily on the extension, which runs in the host process. The out of process implementations that we have so far (JS, Python, PowerShell) required shims to be created in order for the functions code running separately to communicate with the extension in the host.

We currently don’t have plans to bring Durable Functions to this worker for the .NET 5 timeframe. We plan to have the host updated to .NET 6 LTS, and Durable Functions should run fine on that. We will evaluate whether we will bring Durable Functions to this worker long term.

/cc @cgillum @fabiocav

[wahyuen]

@anthonychu It would be quite useful to have your comments added to documentation, either on the Function side and probably on the Durable side. Even in the duration of this issue, I've had multiple work colleagues from other teams ask the exact same question of whether Durable functions is supported on .NET5 and if they should/can even perform upgrades.

Even if there were technical workarounds, that would be nice to document as well, at least to give teams a path forward. (Unsure if this is even possible?)

[ladeak]

We cannot really update .netcoreapp3.1 functions to .net5 functions, because of this missing support of Durable Functions. The rest of the app in my projects is .net5 already.
However, .netcoreapp3.1 functions cannot reference .net5 projects, which means I cannot update these dependency projects either.

This is a problem because we cannot use C# 9 features even in the rest of the app: such as record types and init only properties, which is a considerable constraint today. .net 6 seems just too far away.

Yes... there are "hacks" to get the latest lang features working (https://stackoverflow.com/questions/62648189/testing-c-sharp-9-0-in-vs2019-cs0518-isexternalinit-is-not-defined-or-imported)

Another question: what the community could do to improve the situation? If there was a plan to get Durable Functions working with .net5 functions, how much work would it be? How much could it be picked up by open-source community?

[hansmbakker]

@antonychu why can't the LTS/non-LTS issue be solved with a setting in Azure?

You can choose your functions host/runtime in configuration. If updating the functions host to .net 5 would cause compatibility issues, why can't it be put behind a configuration to enable using that updated host?

[kuromukira]

Durable Functions is a great tool to use with functions. Would be great if this would be supported in the long term.

[anthonychu]

@antonychu why can't the LTS/non-LTS issue be solved with a setting in Azure?

You can choose your functions host/runtime in configuration. If updating the functions host to .net 5 would cause compatibility issues, why can't it be put behind a configuration to enable using that updated host?

We might be able to find a solution to run the host on non-LTS versions but that will be in the .NET 7 timeframe. With .NET 5, our plan is to more forward with this out of process worker, and take the learnings forward in .NET 6 and beyond.

[hansmbakker]

Ok, I see. I cannot judge the trade-offs well, I assume this approach is for the better.

[tommck]

Wow, it didn't even occur to me that these bindings wouldn't be supported in the next version. That's going to make me look like an idiot to my clients when I tell them that we won't be able to update because we'd have to rewrite everything.

I'm truly astonished

[anthonychu]

@tommck This limitation is temporary and only affects the .NET out of process worker that is needed if you want to run .NET 5.

We will be updating the Azure Functions host to .NET 6. This means you'll be able to run .NET 6 functions in-process and have the same capabilities that you have today with .NET Core 3.1 (Durable Functions, rich bindings, etc).

At the same time, we plan to continue to improve the out of process worker to close the feature gap.

[yuramag]

@anthonychu Since .NET 6 Preview 1 is out, are you planning on upgrading the Azure Functions host and making it available as preview? If so, when should we expect it?

This is very painful for some of us to not being able to even try durable functions with .NET 5 or 6 at this point.

[anthonychu]

@yuramag Yes. We'll be shipping this out-of-process worker in the coming weeks. Then we'll start on updating the functions runtime to the .NET 6 preview. Expect a preview available in the first half of this year that you can run locally and deploy as containers. We're still working on timelines for when .NET 6 preview will be available in the platform so you can deploy it as a typical function app.

[jan-harders]

Durable functions was a killer feature. Please don't kill it.

[fabiocav]

We agree! Support for Durable Functions in the new model is very important to us. It's something we'll work on bringing in as we address some of the gaps that make it challenging today.

[fabiocav]

@henriksen

According to @anthonychu on Twitter, durable functions are not in scope for .NET 5. Maybe 6.

To be clear, it will absolutely be available with the .NET 6 support.