Azure-functions-host: Roadmap for .NET 5 and Azure Functions V3

[prabh-62]

What problem would the feature you're requesting solve? Please describe.

Azure Functions V3 project does not build with .NET 5 SDK

Describe the solution you'd like

Azure Functions V3 project should not error out with .NET 5 SDK

Describe alternatives you've considered

N/A

Additional context

Tried running Azure Functions V3 in .NET 5 docker container
*.csproj file

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.9" />
  </ItemGroup>
</Project>

• > dotnet --info

.NET SDK (reflecting any global.json):
 Version:   5.0.100-rc.1.20452.10
 Commit:    473d1b592e

Runtime Environment:
 OS Name:     debian
 OS Version:  10
 OS Platform: Linux
 RID:         debian.10-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.100-rc.1.20452.10/

Host (useful for support):
  Version: 5.0.0-rc.1.20451.14
  Commit:  38017c3935

.NET SDKs installed:
  5.0.100-rc.1.20452.10 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.0-rc.1.20451.17 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.0-rc.1.20451.14 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

• dotnet build

Microsoft (R) Build Engine version 16.8.0-preview-20451-02+51a1071f8 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
  ImageService -> /workspaces/net5fn/bin/Debug/net5.0/ImageService.dll
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : It was not possible to find any compatible framework version [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : The framework 'Microsoft.NETCore.App', version '3.1.0' was not found. [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :   - The following frameworks were found: [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :       5.0.0-rc.1.20451.14 at [/usr/share/dotnet/shared/Microsoft.NETCore.App] [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :  [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : You can resolve the problem by installing the specified framework and/or SDK. [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :  [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : The specified framework can be found at: [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :   - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=3.1.0&arch=x64&rid=debian.10-x64 [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :  [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : Metadata generation failed. [/workspaces/net5fn/ImageService.csproj]

Build FAILED.

/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : It was not possible to find any compatible framework version [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : The framework 'Microsoft.NETCore.App', version '3.1.0' was not found. [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :   - The following frameworks were found: [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :       5.0.0-rc.1.20451.14 at [/usr/share/dotnet/shared/Microsoft.NETCore.App] [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :  [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : You can resolve the problem by installing the specified framework and/or SDK. [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :  [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : The specified framework can be found at: [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :   - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=3.1.0&arch=x64&rid=debian.10-x64 [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :  [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : Metadata generation failed. [/workspaces/net5fn/ImageService.csproj]
    0 Warning(s)
    2 Error(s)

Time Elapsed 00:00:02.40

[prabh-62]

Not sure, if this issue should be moved to https://github.com/Azure/azure-functions-vs-build-sdk repo

[Peter-B-]

This is a very interesting question. Is there a roadmap for supporting .Net 5 in Azure Functions?

Is there a plan to support EF Core 5 on .Net Core 3.1?

[c0dybrown]

@prabh-62 @Peter-B- Have you tried using azure functions prerelease as so:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
    <AzureFunctionsVersion>v3-prerelease</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Functions.Extensions" Version="1.1.0" />
    <PackageReference Include="Microsoft.Azure.WebJobs.Extensions.EventGrid" Version="2.1.0" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="5.0.0-rc.1.20451.13" />
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.9" />
  </ItemGroup>

[Pinox]

@c0dybrown Does it work as a workaround ?

[Peter-B-]

@c0dybrown No, I didn't know about it. Thanks for bringing that to my attention. I will give it a try.

I know that it says prerelease, but is there any "getting started" or documentation for that? I could not find much on Google or even Bing :-)

[prabh-62]

I tried with v3-prerelease. Still the same errors with dotnet build command.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
    <AzureFunctionsVersion>v3-prerelease</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.9" />
  </ItemGroup>
</Project>

• dotnet build

Microsoft (R) Build Engine version 16.8.0-preview-20451-02+51a1071f8 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored /workspaces/net5fn/ImageService.csproj (in 534 ms).
  You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
  ImageService -> /workspaces/net5fn/bin/Debug/net5.0/ImageService.dll
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : It was not possible to find any compatible framework version [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : The framework 'Microsoft.NETCore.App', version '3.1.0' was not found. [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :   - The following frameworks were found: [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :       5.0.0-rc.1.20451.14 at [/usr/share/dotnet/shared/Microsoft.NETCore.App] [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :  [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : You can resolve the problem by installing the specified framework and/or SDK. [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :  [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : The specified framework can be found at: [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :   - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=3.1.0&arch=x64&rid=debian.10-x64 [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :  [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : Metadata generation failed. [/workspaces/net5fn/ImageService.csproj]

Build FAILED.

/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : It was not possible to find any compatible framework version [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : The framework 'Microsoft.NETCore.App', version '3.1.0' was not found. [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :   - The following frameworks were found: [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :       5.0.0-rc.1.20451.14 at [/usr/share/dotnet/shared/Microsoft.NETCore.App] [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :  [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : You can resolve the problem by installing the specified framework and/or SDK. [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :  [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : The specified framework can be found at: [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :   - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=3.1.0&arch=x64&rid=debian.10-x64 [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error :  [/workspaces/net5fn/ImageService.csproj]
/root/.nuget/packages/microsoft.net.sdk.functions/3.0.9/build/Microsoft.NET.Sdk.Functions.Build.targets(32,5): error : Metadata generation failed. [/workspaces/net5fn/ImageService.csproj]
    0 Warning(s)
    2 Error(s)

Time Elapsed 00:00:02.54

[prabh-62]

https://github.com/Azure/azure-functions-vs-build-sdk/issues/451#issuecomment-693030505

As per this comment, .NET 5 is not supported

[Peter-B-]

Does anyone know a plan for enabling EF Core 5 und .Net Core 3.1 in an Azure Function?

This would be great, but when I run it locally, it does not find Microsoft.Extensions.Logging 5.

See Azure/azure-functions-vs-build-sdk#472

[atvanvlack]

Azure/azure-functions-vs-build-sdk#451 (comment)

As per this comment, .NET 5 is not supported

My question is, will Azure Functions have a new release in November when GA happens for .NET 5?

[anthonychu]

We’re working .NET 5 support but don’t know whether it will be ready when .NET 5 is GA.

As for running EF Core 5 on v3, we need to investigate why it’s not working.

[jjxtra]

.NET 5 publish to azure functions is working but there are a few "could not evaluate...' errors. It does deploy the zip file though, but every function call gets a 404 error.

Since azure functions lags months behind the general .net annual cycle, can we get self contained publishing support on azure functions? This has to make your life simpler on the back-end as you can stop caring about what runtimes are installed on your Windows and Linux cloud servers...

[anthonychu]

Currently, .NET functions compile to a class library that is loaded in a .NET Core 3.1 host process, so you can't run on .NET 5 by publishing a self-contained exe.

With the new .NET 5 worker, we're breaking from the class library model and the worker will be its own process.

cc @jeffhollan

[tforkmann]

Hi there, is there any news on that? Thanks, Tim

[c0dybrown]

@anthonychu One thing that would bridge the gap in a big way: get EF Core 5 working on Azure functions somehow. For me and many others that I work with, the most critical feature coming out of the .NET/EF 5 release is the new "Split Query" feature. Using split queries for long include chains in EF cuts transaction time exponentially and drastically reduces code complexity.

It's the difference between having a function run for 45+ seconds (or fail) due to a poorly optimized DB query that requires developer intervention and a bunch of code to fix, and having the same code execute in <1 second.

Please my friend, I will personally put a bounty on EF 5 in Azure Functions

[onionhammer]

@c0dybrown have you tried using efcore5 with netcoreapp3.1? In the interim, I dont think EF core 5 requires .net5

[thiagottss]

@c0dybrown have you tried using efcore5 with netcoreapp3.1? In the interim, I dont think EF core 5 requires .net5

It works with netcore3.1 but it doesn't work with Azure Function v3, on Azure. If you want to "run/debug" locally you can update (4) Azure Functions Core Tools dlls to version 5 and it will work. But it will fail when you deploy it to Azure.

https://stackoverflow.com/a/64460664/7037154

[c0dybrown]

@c0dybrown have you tried using efcore5 with netcoreapp3.1? In the interim, I dont think EF core 5 requires .net5

It works with netcore3.1 but it doesn't work with Azure Function v3, on Azure. If you want to "run/debug" locally you can update (4) Azure Functions Core Tools dlls to version 5 and it will work. But it will fail when you deploy it to Azure.

https://stackoverflow.com/a/64460664/7037154

@onionhammer - @thiagottss answer is accurate in my experience, even after trying a million "tricks" such as installing the .NET 5 runtime on the Azure function host

[onionhammer]

@thiagottss ahh that bites. Hopefully Microsoft fixes this swiftly :/

[schmid37]

We are about to deploy our application with .Net 5 ... Just the Azure function does not support it... What's going wrong here?

[jjxtra]

Azure functions is getting overhauled - self contained deploys will be the future as far as I understand, then we don't have this annual mess of not being able to upgrade .net version.

[onionhammer]

It would be nice to get some sort of ETA; like "Coming December" or "Coming Q3 of 2024", just a ballpark to know if its worth waiting

[jjxtra]

If you need to deploy today, make a .net core 3.1 functions app and refactor any shared code that your functions project needs into a .net standard 2.1 library. Once they get their stuff in order, you can move the 3.1 functions app to .net 5.

This is a little painful but can be accomplished by adding linked .cs files to the .net standard 2.1 library project (or to the functions project and skip the library project). It's a little hacky, but only temporary until they get things sorted out.

[MattJeanes]

This issue is blocking our upgrade to .NET 5 and we'd like to know if it's worth waiting a couple weeks for Azure Functions to support .NET 5 or if we should go ahead changing our libraries to netstandard2.1 and functions back to netcoreapp3.1

[anthonychu]

Current ETA is a preview by end of year. Thanks for your patience.

[kuromukira]

If you need to deploy today, make a .net core 3.1 functions app and refactor any shared code that your functions project needs into a .net standard 2.1 library. Once they get their stuff in order, you can move the 3.1 functions app to .net 5.

This is a little painful but can be accomplished by adding linked .cs files to the .net standard 2.1 library project (or to the functions project and skip the library project). It's a little hacky, but only temporary until they get things sorted out.

3rd party packages that teams rely on should also move to .net standard 2.1 right?

[jjxtra]

Definitely. If you are relying on Azure functions in the next few months, I'd rely on .net standard 2.1 to bridge the gap. Most nuget packages support it just fine.

[SergiySeletsky]

It is blocking us to use .NET 5 too...
will the next version support gRPC triggers and streams for functions?
maybe you need some help to make it faster?

[chassq]

As a side note I recall that this same thing happened in the transition from dotnet core 2.2 to 3.0. We had to wait until the following January, after the 3.0 release, to upgrade to 3.0 as azure functions took a few months to catch up. I hope they stop this practice in the future as it is incredibly annoying to have to hold every thing just for them. Even if it is for the best to change how functions work they should realize a new major version is in the works and account for it. Oh well....

[mwwhited]

As a side note I recall that this same thing happened in the transition from dotnet core 2.2 to 3.0. We had to wait until the following January, after the 3.0 release, to upgrade to 3.0 as azure functions took a few months to catch up. I hope they stop this practice in the future as it is incredibly annoying to have to hold every thing just for them. Even if it is for the best to change how functions work they should realize a new major version is in the works and account for it. Oh well....

I've been assuming the changes that they have been making this year that broke their own code (such as not being able to use SqlClient with Azure Functions for a while) was because they were focused on .Net 5... that seems to not the case and that makes me a little worried.

[anthonychu]

Currently, .NET functions run inside the Azure Functions host. The host is something that runs in production for all of our customers (regardless of language) and we take upgrading it very seriously. This means when new versions of .NET is released, it’s more than just recompiling against the new framework and shipping it. We need to go through a preview process before we can declare GA.

This is also the reason why we are not updating the host to .NET 5. We’d need to support the host longer than .NET 5’s planned its end of life.

For .NET 5, we are building a completely new language worker that runs in a separate process from the host, like the workers for other languages. Because it’s built from the ground up, it’s taking longer to get ready.

The good news is that we believe the out-of-process model will allow us to do a better job of keeping up with future .NET releases, as it’s just a NuGet package now.

Thanks for your patience on this. We want to ship this as much as you all want to get your hands on it. 🙂

[deyanp]

@anthonychu , understood, however what is the ETA? Nov, Dec, or Jan?

Any chance to get it earlier out for those like us hosting in AKS?

Need that for my own planning, if it is Jan I will see if I can dump the functions framework then and replace with standard .net core asp.net mvc stuff ... The only thing I am using are anyway only the event hub and queue triggers ...

[tforkmann]

I totally agree with @deyanp. I already moved some functions to our local server (.NET 5). Bc I don’t want to maintain two different frameworks.

[AartBluestoke]

@anthonychu , does this mean that the dependencies for our functions will decouple form the underlying host, but only if you are not running netcoreapp3.1?

[anthonychu]

Currently targeting public preview before end of December but can’t provide a definite date right now.

@deyanp If you are running in AKS and those are the only triggers you need, a good alternative is to use the WebJobs SDK directly in a .NET 5 console app.

You can also run .NET 5 in Functions as a custom handler. But our recommendation is to wait for the worker.

[anthonychu]

@AartBluestoke If you choose to use the new worker, you’ll be creating a .NET 5 app
that references the .NET 5 worker NuGet package. That app should be able to reference .NET Core 3.1 and .NET standard assemblies. Because you are in control of the app and the app runs as a separate process, you shouldn’t have to worry about dependencies conflicting with those from the host.

[deyanp]

@deyanp If you are running in AKS and those are the only triggers you need, a good alternative is to use the WebJobs SDK directly in a .NET 5 console app.

@anthonychu , sorry, I meant in addition to HttpTriggers ... any hints how to migrate away from Azure Functions to .net console app with webjobs sdk for queuetrigger/eventhubtrigger/timertrigger and still be able to serve http api calls (and even grpc which is anyway completely missing in azure functions)?

[c0g1t8]

@anthonychu

Ran across this issue and found quite a few related one spread over _Stack Overflow_ and _GitHub_. Guidance needs to be provided on the use of .NET 5 with Azure Functions V3.

IMO - It may be worthwhile to note this in the Azure Functions documentation. Specifically in https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-dependency-injection#register-services.

[tjrobinson]

@anthonychu Thanks for the updates on this. Will the .NET 5 support be coming to WebJobs too? Functions still sits on top of a lot of the WebJobs libraries I believe?

[aherrick]

I find it really surprising Net 5 would be released (EF Core as well) and Azure Functions wouldn't be released inline with that support. Seems like a team sync failure.

[jjxtra]

I know they are retooling azure functions to avoid this delay in future .net releases, so hopefully this is the last year for this sort of thing :)

[AnthonyIacono]

We have the following package references in our functions project:

<PackageReference Include="Microsoft.Azure.Functions.Extensions" Version="[1.1.0]" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.Storage" Version="[4.0.3]" />
<PackageReference Include="Microsoft.Extensions.Http" Version="[3.1.9]" />
<PackageReference Include="Microsoft.Extensions.Http.Polly" Version="[3.1.9]" />
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="[3.0.11]" />

Is there anything wrong with upgrading Microsoft.Extensions.Http and Microsoft.Extensions.Http.Polly to 5.0.0?

On a related note, it'd be neat to learn how I can figure out these types of compatibility checks on my own without trial and error.

[AartBluestoke]

@AnthonyIacono as i commented in Azure/azure-functions-host#6893

• when you run azure functions, it starts before it loads your code.
• only 1 version of a dll can be loaded at once.

Consequence: if you need a library that is a direct or indirect dependency of azure functions you can only use the version that is loaded. This is a case where azure functions is incorrectly reporting its hard dependencies.

eg: if you are using azure functions 3.0.7, then you must use a library binary compatible with dependencyInjection.abstractions 2.1.0
When your code (eg if you have a asp.netcore dependencency) asks for something that is only found in Abstractions >=5.0 the runtime (correctly) responds "sorry, that function isn't there", because all it has is the 2.1.0 dll in memory.

(searching for the library name when you have azure functions as a dependency shows:)

Therefore the many tickets that will be raised that are like this can only be solved by upgrading azure functions to a newer version which has a dependency on the 5.x line of the abstractions.

In this particular case azure functions has no direct dependencies on Microsoft.Extensions.Http

however they share transitive dependencies such as the logging abstractions:

In this particular case, if azure functions used Microsoft.Extensions.Logging.Abstractions 5.0, then it would be fine because that library appears to be backwards compatible so the reverse error doesn't occur (no runtime failure if you expect 2.1 and actually get 5.0).

If that is not true for all libraries in common between azure functions and the libraries your code uses, then you will be pinned in terms of your dependencies and azure functions versions.

[AnthonyIacono]

@AartBluestoke Gotcha. I appreciate the detailed explanation. I'll put a pin in upgrading these packages for now and leave a comment in our CSPROJ. This is a total bummer since I have a somewhat "OCD" for always upgrading our packages.

[ShockwaverReal]

Currently targeting public preview before end of December but can’t provide a definite date right now.

@deyanp If you are running in AKS and those are the only triggers you need, a good alternative is to use the WebJobs SDK directly in a .NET 5 console app.

You can also run .NET 5 in Functions as a custom handler. But our recommendation is to wait for the worker.

So I wait for the worker... any more precise ETA? Even close to precise? (deadline coming in fast) :)

[cygnim]

This is such a bummer, and a glaring oversight on Microsoft's part. With a set cadence of 12 months per .NET release, these upgrades should be easy to accommodate. .NET 5's release wasn't a surprise to anyone, and this incongruity with the .NET release cycle should be better addressed. I hope this can be remedied quickly as our upgrade is on hold until the support is there.

[alejandromelis]

Currently, .NET functions run inside the Azure Functions host. The host is something that runs in production for all of our customers (regardless of language) and we take upgrading it very seriously. This means when new versions of .NET is released, it’s more than just recompiling against the new framework and shipping it. We need to go through a preview process before we can declare GA.

This is also the reason why we are not updating the host to .NET 5. We’d need to support the host longer than .NET 5’s planned its end of life.

For .NET 5, we are building a completely new language worker that runs in a separate process from the host, like the workers for other languages. Because it’s built from the ground up, it’s taking longer to get ready.

The good news is that we believe the out-of-process model will allow us to do a better job of keeping up with future .NET releases, as it’s just a NuGet package now.

Thanks for your patience on this. We want to ship this as much as you all want to get your hands on it. 🙂

Thanks for your update @anthonychu.

The host for the new .NET 5 language worker will run on .NET 5 or still run on Net Core 3.1? In case of still on .Net Core 3.1 there is any plan to upgrade the host or use a different host based on .NET 5 in order to enjoy all .NET 5 the performance benefits not only in our code but also in the host code?

[Mithras]

AWS Lambdas support .NET 5 but Azure Functions don't. Is there any alternative in Azure?

[anthonychu]

Thanks for your update @anthonychu.

The host for the new .NET 5 language worker will run on .NET 5 or still run on Net Core 3.1? In case of still on .Net Core 3.1 there is any plan to upgrade the host or use a different host based on .NET 5 in order to enjoy all .NET 5 the performance benefits not only in our code but also in the host code?

The host will still be .NET Core 3.1. As mentioned before, the host cannot take a dependency on .NET 5 because it's not LTS. We are planning to update the host for .NET 6.

We are still on track for a preview of the .NET 5 worker later this month.

[ShockwaverReal]

We are planning to update the host for .NET 6

Update it to .NET 6 I guess... Does this mean it will be LTS?

[Methuselah96]

@ShockwaverReal Yes, .NET 6 will be LTS.

[JamesRandall]

This, IMO, is a mess. Historically been doing a lot with Functions but as a fundamental offering how can this be in this state at this point?

I'm currently doing some work with AWS and Lambda and able to target .NET 5 today - cleanly, simply, in a well documented fashion and without the cognitive load involved in reading this thread and this outward facing complexity. Visual Studio tooling, docker image, updated templates, build and I'm done (I'm using Pulumi but fundamentally as per this post here: https://aws.amazon.com/blogs/developer/net-5-aws-lambda-support-with-container-images/ )

To me the bar has been set and I really hope folk in MS are looking at the competition.

[forki]

@JamesRandall but does AWS have PREMIUM?? Ha! Checkmate! :P

[aherrick]

FYI
https://techcommunity.microsoft.com/t5/apps-on-azure/net-5-support-on-azure-functions/ba-p/1973055

[Spaceman1861]

Huzza!

[anthonychu]

In case anyone missed it, the link that @aherrick shared is to our blog post announcing the .NET 5 worker preview. We still have work to do to update all tooling and platform to support it, but we wanted to share it as soon as possible.

[JamesRandall]

I think the Twitter thread on this is worth reading too as some of the limitations are discussed in the comments.

https://twitter.com/AzureFunctions/status/1337120082388905984

[Mithras]

Anybody was able to run .NET 5?
https://github.com/Azure/azure-functions-dotnet-worker-preview breaks the moment I add any 5.0.0 package. E.g. just add
<PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="5.0.0" />
and functions fail to start with

[brminnick]

@Mithras Did you follow steps outlined in the README to upgrade your app from .NET Core 3.1 to .NET 5.0?

https://github.com/Azure/azure-functions-dotnet-worker-preview/blob/main/README.md#install-the-azure-functions-core-tools

[Mithras]

@brminnick I did everything in readme.
Repo steps:

1. Download the repo.
2. Add <PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="5.0.0" />
3. func host start --verbose
4. Error

If I skip step 2, everything works without errors.

Also, adding different 5.0.0 libs result in different exceptions. For example, if you add Microsoft.Extensions.Configuration.Abstractions, exception changes to

[Mithras]

just in case:

[ShockwaverReal]

@brminnick I did everything in readme.
Repo steps:

1. Download the repo.
2. Add <PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="5.0.0" />
3. func host start --verbose
4. Error

If I skip step 2, everything works without errors.

Also, adding different 5.0.0 libs result in different exceptions. For example, if you add Microsoft.Extensions.Configuration.Abstractions, exception changes to

I confirm this...

[Spaceman1861]

For those who are trying to solve the above problems.
https://github.com/Azure/azure-functions-dotnet-worker-preview/issues/13

Helped me.

[ivanakcheurov]

@JamesRandall but does AWS have PREMIUM?? Ha! Checkmate! :P

Do you mean always-on containers so that there is no cold start?
If yes, then AWS released provisioned capacity for lambdas a year ago:
https://aws.amazon.com/blogs/aws/new-provisioned-concurrency-for-lambda-functions/

What advantages does Azure Functions Premium have over AWS Lambda with provisioned capacity?

[forki]

@ivanakcheurov sorry it was a sarcastic remark.

[rubo]

• The suggested workaround for https://github.com/Azure/azure-functions-dotnet-worker-preview/issues/13 is not applicable for the projects that have dependencies that use some v5 packages
• Durable tasks seem not possible which is a blocker
• Configuration settings cannot be read from local.settings.json

Am I missing something or is this stuff pretty much useless and works for some very basic samples only? As of now, it's just impossible to upgrade any real-world Azure Functions project to .NET 5 as nothing works. _Nothing_.

[jjxtra]

You can't use net 5 for azure functions right now. Target net core 3.1 and link any shared source files or use net standard versions of your nugets.

[Methuselah96]

We’re looking at options for .NET 6. Durable Functions is definitely something we want to support.

(source)

It sounds like there is no planned support for Durable Functions for .NET 5 (and no concrete plan yet for .NET 6). This is preventing us from upgrading almost all of our code to .NET 5 (C# 9) which is discouraging. We're looking forward to hearing plans for supporting Durable Functions. Meanwhile we'll probably start looking into alternatives to Azure Functions/Durable Functions as this has become a blocker for us (along with https://github.com/Azure/azure-functions-host/issues/4049) and was a blocker for us during the .NET Core 3.x upgrade as well.

[onionhammer]

@Methuselah96 Can you use the new DOTNET sdk to target 3.1 with C# 9 by setting langversion in csproj?

Nevermind, that used to work back in the day with other upgrades, not so much with C# 9.

[ssa3512]

@onionhammer @Methuselah96 most C#9 features will work by setting langversion latest. The big exception to this is record types, which require the IsExternalInit type in System.Runtime.CompilerServices. I’ve requested a shim package similar to Microsoft.Bcl.AsyncInterfaces and Microsoft.Bcl.HashCode here, hopefully we will get that. https://github.com/dotnet/runtime/issues/43638

[Alxandr]

You don't need a shim package. I have a shim file I copy that contains both support for records and nullable attributes. On phone now though, so can't paste link to it. If there is interest, I can do do later.

[kuromukira]

Would be nice to have Durable Functions support

[ladeak]

There is a separate issue as well for Durble Functions:

https://github.com/Azure/azure-functions-dotnet-worker-preview/issues/9

You can use c# 9 with preview Lang version and a hack linked the issue above with Durble Functions and dotnet 3.1

But will lose all the performance improvements and I did not find a way to reference other net 5 projects.

[StefanSchoof]

You don't _need_ a shim package. I have a shim file I copy that contains both support for records and nullable attributes. On phone now though, so can't paste link to it. If there is interest, I can do do later.

Here is the issue discussion about the IsExternalInit, with a workaround: https://github.com/dotnet/roslyn/issues/45510

[Mithras]

So from my understanding https://github.com/Azure/azure-functions-dotnet-worker-preview doesn't work only because it generates a .dll instead of function.json. Is there an estimate for a fix?

[anthonychu]

@fabiocav Can you please take a look at @Mithras' question above?

[kamyker]

You should think about custom runtimes. In AWS I was able to make both Net 5 ReadyToRun and CoreRT functions. This dropped 128mb function cold start from 8 sec to 1-2 sec and 400ms for CoreRT.

Hopefully System.Text.Json with source generators will make it easy to use with CoreRT as that's the future of C# microservices.

[anthonychu]

@kamyker Azure Functions supports custom runtimes via Custom Handlers.

We should be able to provide support for ReadyToRun in the .NET 5 worker. We currently support ReadyToRun in .NET Core 3.1 functions today.

[deyanp]

@anthonychu, thanks for the hints regarding Webjobs SDK above, I have successfully migrated away from Azure Functions (both HttpTriggers and non-HTTP triggers) and enjoying 2x smaller memory footprint and faster runtime, as well as .NET 5 features on AKS :)

For those interested - I just needed 100 lines of code in a Program.fs (sorry, F# here), will write a blog post if I find time .. HttpTriggers and non-http triggers like TimerTriggers, EventHubTrigger work, even Azure SignalR Service integration is working ..

Clear recommendation for those hosting in AKS (and those who are not should be!) to do the same.

[<EntryPoint>]
let main argv =
    let builder = Host.CreateDefaultBuilder(argv)

    builder.ConfigureServices(fun context services ->
        let aiOptions = ApplicationInsightsServiceOptions(EnableAdaptiveSampling = false)   // disable sampling (turned on by default, see https://docs.microsoft.com/en-us/azure/azure-monitor/app/sampling#brief-summary)
        services.AddApplicationInsightsTelemetry(aiOptions) |> ignore
        services.AddSingleton<ITelemetryInitializer, Framework.Logging.Telemetry.Configuration.CustomTelemetryInitializer>() |> ignore

        if context.HostingEnvironment.IsDevelopment() then
            services.AddCors(fun options ->
                options.AddDefaultPolicy(fun b ->
                    b
                        .AllowCredentials()
                        .WithOrigins("http://localhost:8080")
                        .WithHeaders("authorization","content-type","if-match","etag","content-disposition","x-requested-with")
                        .WithExposedHeaders("authorization","content-type","if-match,etag","content-disposition")
                    |> ignore
                )
            ) |> ignore
        ) |> ignore       

    builder.ConfigureLogging(fun context b ->
        b.AddConsole() |> ignore
    ) |> ignore

    builder.ConfigureWebHostDefaults(fun b ->
        b.Configure(fun context app ->
            app.UseRouting() |> ignore

            if context.HostingEnvironment.IsDevelopment() then        
                app.UseCors() |> ignore

            app.UseEndpoints(fun endpoints ->
                let logger = endpoints.ServiceProvider.GetService<ILogger<Object>>()
                let telemetryClient = endpoints.ServiceProvider.GetService<TelemetryClient>()
                let funcApp = XxxService.QueryHandling.Api.AzureFunctions.FunctionApp(telemetryClient)

                endpoints.MapGet("api/v1/entities/{entityId}", fun context ->
                    let entityId = context.Request.RouteValues.["entityId"] |> string
                    funcApp.GetEntityById(context.Request, entityId, logger)
                    |> Task.bind (HttpContext.fromResponseMessage context)
                    :> Task) |> ignore

                endpoints.MapGet("api/v1/entities", fun context ->
                    funcApp.GetEntitiesByFilters(context.Request, logger)
                    |> Task.bind (HttpContext.fromResponseMessage context)
                    :> Task) |> ignore

            ) |> ignore
        ) |> ignore
    ) |> ignore

    builder.ConfigureWebJobs(fun b ->
        b.AddAzureStorageCoreServices() |> ignore
        b.AddEventHubs() |> ignore
        b.AddTimers() |> ignore)
    |> ignore

    use tokenSource = new CancellationTokenSource()    
    use host = builder.Build()
    host.RunAsync(tokenSource.Token) |> Async.AwaitTask |> Async.RunSynchronously

    0 // return an integer exit code

[kamyker]

@kamyker Azure Functions supports custom runtimes via Custom Handlers.

We should be able to provide support for ReadyToRun in the .NET 5 worker. We currently support ReadyToRun in .NET Core 3.1 functions today.

Isn't that working only for part of an app, not for runtime?

[fabiocav]

@kamyker

Isn't that working only for part of an app, not for runtime?

Can you please clarify? The runtime is deployed with optimizations. All you need to optimize is the payload you're deploying.

[Mithras]

Is there any point waiting for Functions to support .NET 5 or should everybody just migrate to Webjobs SDK?

[drdamour]

Is there any point waiting for Functions to support .NET 5 or should everybody just migrate to Webjobs SDK?

Do webjobs work on consumption plans?
Do they support df?

[chassq]

Maybe the functions team should consider supporting all the versions of dotnet 5+ for all azure function features. Hopefully they will never make us go through this again. This is so very obtuse.

[Mithras]

@drdamour So not everybody can just migrate... Well, at least people who don't need DF and use Service Plan should be able to migrate and use whatever version of .NET they want, right? My main concern is how well Webjobs SDK is being supported. I don't want to migrate to something that'll be abandoned in near future.

[Mithras]

https://docs.microsoft.com/en-us/azure/azure-functions/functions-compare-logic-apps-ms-flow-webjobs#comparison-table
Here is a table that summarizes Functions vs WebJobs. From my understanding of https://github.com/Azure/azure-webjobs-sdk-extensions#other-extension-repositories DF should work in WebJobs as well.

[kuromukira]

Are they abandoning Azure Functions in future .NET releases to focus more on WebJobs SDK? I have tons of functions and almost all rely heavily on DF.

[anthonychu]

Are they abandoning Azure Functions in future .NET releases to focus more on WebJobs SDK? I have tons of functions and almost all rely heavily on DF.

Absolutely not. In fact, we are increasing our investments in .NET in Azure Functions so that we can provide an updated Azure Functions host that supports .NET 6 in the same timeframe as .NET 6's planned GA. It will support all current features, including Durable Functions.

In addition, we will continue investment in the out-of-process .NET worker that is currently in preview. We will announce information about our .NET roadmap after we ship the worker for .NET 5.

[shibayan]

I don't need .NET 5 support, I just need a package that works with .NET Standard 2.1, like Entity Framework Core 5.0, but unfortunately it doesn't work with the current Azure Functions v3. The NuGet package targeting .NET Standard 2.1 should be available for Azure Functions using .NET Core 3.1, but the current implementation blocks it.

I'm really struggling with this issue and I want to help.

[AartBluestoke]

@shibayan

I don't need .NET 5 support, I just need a package that works with .NET Standard 2.1,

That would be a topic for a separate ticket; this ticket concerns support for .net 5; I doubt net standard support will be done as the future of .net is the fusion of net core and net framework. From what i can see the out-of process support for Net 5, and next years support for Net 6 is the future for this.

like Entity Framework Core 5.0,

the inability to use EntityFrameworkCore 5.x with azure functions is unrelated to support of net standard2.1, it is about library dependency incompatibilities between EFCore and Functions.

but the current implementation blocks it.

This is the crux of the issue; azure functions use code patterns not available within .net framework, so there is no easy way to make function cross-compatible without substantial dev effort; my guess is that microsofts dev effort is better spent improving functions itself so that cross-platform availability is available in process at high quality next year.

(fyi i've got a very chatty azure function set that would benefit quite a bit from the move to net5 in terms of memory handling and latency, and i can't currently move because of the in/out processes change for net 5, and i've had to jump through hoops for a mixed functions v1 and functions v3 when i've had to use .net framework. These hoops are only is only getting worse with Microsoft.SqlClient vs System.SqlClient.)

[onionhammer]

Any update on when the preview for .net 5 will actually work? (Without erroring with dependencies loading new nuget packages), or when we can use triggers with byte[]/streams etc?

It's just not usable or even worth testing in the state the preview is in

[manish-jain-1]

Current ETA is a preview by end of year. Thanks for your patience.

Any update? Thank you!

[qsdfplkj]

Current ETA is a preview by end of year. Thanks for your patience.

Any update? Thank you!

Is there any official statement, a release calendar or roadmap?

[ModernRonin]

for anyone else receiving updates from this thread and almost having a heart attack: the quote about the "current ETA (...) by end of year" is from 2020, not 2021 ;-)

[qsdfplkj]

I know but he made it 15 hours ago. So...

[louisoftokyo]

How can I try the preview?

[Mithras]

@louisoftokyo there is no working preview yet. You can try working hello world though: https://github.com/Azure/azure-functions-dotnet-worker-preview

[opolo]

Our production environment is blocked from upgrading to .NET 5 too due to this... Which we found out about, after upgrading everything to .NET 5...

[VaclavElias]

Happened to me in the past 👍.

Now I am always coming to check Issues in this repo before my Azure Functions upgrades/updates, to see what is in the oven and what is/is not already baked :)

[qsdfplkj]

I only need support for ef core 5.

[fabiocav]

@qsdfplkj if you want to give the preview a try with your workload, we'd love to get more feedback there. https://github.com/Azure/azure-functions-dotnet-worker-preview

[Mithras]

@fabiocav was it fixed? Last time I tried it didn't work with any 5.x.x packages.

[louisoftokyo]

Our production environment is blocked from upgrading to .NET 5 too due to this... Which we found out about, after upgrading everything to .NET 5...

Same :(

[jeffhollan]

Just to make sure we’re capturing the issues - for those saying you are blocked are you having issues with the .NET 5 project linked above? We’ve made a number of fixes and improvements, and if so just want to make sure we’re tracking blocking issues if you can also include issue links.

If you’re blocked by preview flag that’s fair too - let us know - plan to move to production ready in next month

[Mithras]

Just to save people's time. Nothing has changed. Preview is still completely useless and doesn't work with any 5.x.x packages. The reason it doesn't work was explained on 11/12/2020 here: https://github.com/Azure/azure-functions-dotnet-worker-preview/issues/13#issuecomment-743412497 Nobody can give an eta for the fix since then.

[fabiocav]

@Mithras thank you for trying it out, but sharing your details on the preview repo would be more helpful than the comment above. The next update is coming within the next couple of days, and that will address the known issues, but many scenarios do work with the current preview, so discouraging others from trying this out is not productive.

Do you have a link to the actual issue you're hitting when you try it?

[Mithras]

@fabiocav I really can't think of any scenario where running .NET 5 without any 5.x.x packages makes sense.

I've already posted repo steps somewhere in one of the dozens similar issues. Can't find it for some reason...
I'll just repeat it here again:

1. Download https://github.com/Azure/azure-functions-dotnet-worker-preview
2. Add any 5.x.x package to FunctionApp.csproj (e.g. Microsoft.EntityFrameworkCore)
3. Try to run it with "func host start --verbose"
4. FunctionApp: Method not found: 'Microsoft.Extensions.DependencyInjection.IServiceCollection Microsoft.Azure.WebJobs.IWebJobsBuilder.get_Services()'.
   Value cannot be null. (Parameter 'provider')

[chassq]

@jeffhollan

Just to make sure we’re capturing the issues - for those saying you are blocked are you having issues with the .NET 5 project linked above? We’ve made a number of fixes and improvements, and if so just want to make sure we’re tracking blocking issues if you can also include issue links.

If you’re blocked by preview flag that’s fair too - let us know - plan to move to production ready in next month

It is worth noting there are several issues already in https://github.com/Azure/azure-functions-dotnet-worker-preview with little or even no response from the MS side. Some are actually pretty old (>5 days). So when you say you have provided a number of fixes could you say whether some of those issues might be resolved? Also, when you say "production ready in the next month" can you define what that means? For example, does it mean the dotnet 5 worker process will be ready to handle any azure function configuration we throw at it? Will it be ready for local development and azure deployments? Some more info would be nice. Any links you can share to talk about details?

[tforkmann]

@fabiocav I really can't think of any scenario where running .NET 5 without any 5.x.x packages makes sense.

I've already posted repo steps somewhere in one of the dozens similar issues. Can't find it for some reason...
I'll just repeat it here again:

1. Download https://github.com/Azure/azure-functions-dotnet-worker-preview
2. Add any 5.x.x package to FunctionApp.csproj (e.g. Microsoft.EntityFrameworkCore)
3. Try to run it with "func host start --verbose"
4. FunctionApp: Method not found: 'Microsoft.Extensions.DependencyInjection.IServiceCollection Microsoft.Azure.WebJobs.IWebJobsBuilder.get_Services()'.
   Value cannot be null. (Parameter 'provider')

This is what blocking me right now.
https://github.com/Azure/azure-functions-dotnet-worker-preview/issues/33

[onionhammer]

@fabiocav @jeffhollan The major blockers for me are not being able to reference 5.x.x packages, and not accepting byte[] or Stream based trigger arguments. Will those be resolved in the next preview release?

[jeffhollan]

Thanks for last set of comments - was able to repro much of this. Let me work with @fabiocav and @anthonychu and try to post an update on next set of updates soon

[fabiocav]

Folks, updating this thread as well for those interested, but we just published preview 3 which addresses many of the issues we've been tracking (including the dependency issues). Please give it a try and report any issues at https://github.com/Azure/azure-functions-dotnet-worker-preview/issues

[onionhammer]

@fabiocav is there a changelog?

[fabiocav]

@onionhammer not a public one at this point, unfortunately, but let me work with the team to make that available.

FYI @anthonychu @ankitkumarr @brettsam

[ssa3512]

@fabiocav just so you aware, this has already been requested here: https://github.com/Azure/azure-functions-dotnet-worker-preview/issues/29 and here https://github.com/Azure/azure-functions-dotnet-worker-preview/issues/10

[mwwhited]

Good thing Microsoft doesn't own the entire stack and good thing competitors haven't been running the latest framework version for months. BTW, we don't care if the framework is LTS or not. We don't care if the hosted runtime is LTS or not... we just want to to be able to keep projects up to date and not be stuck months in the past.

This is now getting so stale I have risk trying to update third party code which exposes security and bug risks.

[jeffhollan]

@mwwhited it's not clear if or where you are blocked today in using the .NET 5 bits for Azure Functions?

[Mithras]

I'm blocked on this https://github.com/Azure/azure-functions-dotnet-worker-preview/issues/39#issuecomment-771280191
I can't store connection strings in .json files. It has to support loading secrets from KeyVault or something.

[mwwhited]

@mwwhited it's not clear if or where you are blocked today in using the .NET 5 bits for Azure Functions?

All of it, using .Net 5 is not possible with Azure Functions and EF Core 5 with DI or Config abstractions. The preview code being started from command line of the emulator does not work. It just throws errors saying it can not load the various Microsoft*Abstractions libraries. And none of the tooling for VS is complete yet either. I'm not sure if you've noticed but people use dotnet because we want access to great tools. If we wanted painful command line experience we would just program in Java and Node.js ... both of which work as their latest version on production azure functions today.

[ModernRonin]

Let me start with the fact that I too am waiting for this to become production-ready. For several reasons of no further relevance it would make my life significantly easier if by the end of Q1/2021 I could use a production-ready version of Functions that allows me to use net5.

That being said, I don't think being aggressively sarcastic about the development timeline of this feature like @mwwhited is helping make this happen any sooner.

Be realistic: It's the same for all of us developers, whether we are working for MS or not: sometimes a big, architectural change simply takes a certain amount of time and there is no way to make that amount less and the change cannot be avoided either. From their description (ie, switching to language workers), the Functions SDK team is currently at such a point.

From MS as a whole point of view, what would you have them do?

Delay the release of net5 until the Functions SDK refactoring is ready, although the users of the Functions SDK are probably less than one percent of the users of NET?

Or throw more people at the problem? This is an architectural refactoring, and this kinda thing simply supports only a few people working on it simultaneously, beyond that you just create friction instead of increasing productivity.

I understand being unhappy that this is not yet ready. I am unhappy about it myself. But unhappiness is no reason to lash out at people trying to do their job.

[chassq]

I agree somewhat with @ModernRonin but do understand and also feel the frustration. It is not like MS did not have plenty of lead time on dot net 5. Also look at the issues list for the worker preview. The responses are sporadic with some issues not being addressed or even replied to in any fashion. That is not good community engagement imho. For example, look at the Blazor or EF Core teams. Your issues are generally engaged there in very short order. Fundamentally for me the lack of clear communication has been the main issue with this situation. They also have delivered test code that simply does not work at what seems a basic level. So we waste time and effort trying to help when there seems to be little engagement on the other side. If you want to ask what is blocking me I have an issue on the github worker preview page (see https://github.com/Azure/azure-functions-dotnet-worker-preview/issues/40 ). To date it is still not clear what the plan is to me. Leaving us in limbo is simply not acceptable for an enterprise cloud implementation like this I feel.

[mwwhited]

It's not like they didn't know this change was coming up. In fact these guys are on the same team as the rest o the .Net. There have been multiple times though out last year were releases and compilations were out of sync leaving the entire platform broken for a month if you tried to stay up to date. I wouldn't expect it to be big ask to have Microsoft ensure their products work with their own products. I am going to ask that if we continue to spend thousands of dollars ever year on development tools those tools get the same respect as the free tools and I am going to ask that they work to ensure their own products are compatible with each other.

I, the end dev should not have to find that Azure Functions are not compatible with Entity Framework when all I'm trying to do is what we have been told for year... keep updated to the latest versions to ensure that any bugs or security defects are handled in a timely manner. I should not be required to regression .Net and it's related libraries on top of my own platform.

On top of that it should not be a big ask that the expensive enterprise class tools such as Visual Studio Professional and Enterprise get access to the proper emulators and runtimes without extensive hacks, delays or toolchains that have to be highly customized by the end dev to get any work done. (Azure Storage Emulator has in theory been replaced by Azurite but Azurite doesn't work with full Visual Studio without external scripting.)

Using all of these scripts and hacks are fine if you are running a small team on a small project. But when trying to handle multiple dev teams with members of varying skill levels to create a multiple products that integrate and is maintainable is very difficult.. especially when the tools we are given are subpar and do not follow the guide lines that have been recommended for decades.

[onionhammer]

From MS as a whole point of view, what would you have them do?

I just want a changelog between preview versions so I know whether they've resolved specific barriers and I know whether its worth retrying.

I agree, though. Lets keep it civil guys

[mwwhited]

From MS as a whole point of view, what would you have them do?

That's easy. Release a .NET 5 version of Azure function with a statement it is not LTS and continue to work on the out of process version they want for .Net 6 LTS.

I would also have the BCL team replace the appdomain platform exception code with a wrapper pattern that will create out of process with an out of process communication pipeline so it looked like the role appdomain remoting model. The pipeline code could be DI injected and by default use named pipes on windows and unixsockets on linux/os-x.

[drdamour]

That's easy. Release a .NET 5 version of Azure function with a statement it is not LTS and continue to work on the out of process version they want for .Net 6 LTS.

Yeah i agree, this only LTS stuff is bad mojo, i get the viewpoint but this mindset means noone can adopt .net 5 and thats dumb. We get that wed be outta support if we dont move to 6..fine give me the checkbox to click so i can use 5.

Alternatively make it so we can have the 3.1 version use some of the core 5.0 assemblies via some mechanism. A bunch of us just want ef core 5

[Mithras]

That "we don't want to update worker to non-LTS" makes no sense to me. What is the problem supporting multiple worker versions similar to this?

You can't have official position: "We only support updating packages on even years".

[hansmbakker]

That "we don't want to update worker to non-LTS" makes no sense to me. What is the problem supporting multiple worker versions similar to this?

I asked the same and they replied this: https://github.com/Azure/azure-functions-dotnet-worker-preview/issues/9#issuecomment-753815075

However, it is not a real answer to the "why", but merely saying what they are doing instead.

Replying, but not answering. I guess more people have that feeling here...

Collaboration with the community has some room for improvement this way.

[cygnim]

The answer to the question has been clearly answered in this thread. https://github.com/Azure/azure-functions-host/issues/6674#issuecomment-712596112

I understand the frustration and I share it. Microsoft's roadmap for .NET 5 and beyond in regard to Azure Functions was clearly not well thought out and it would be nice if they just admitted it and came up with clear guidance to move forward.

But the sarcasm and up-in-arms over how "easy" this problem is to fix is ridiculous. Unless you're an engineer on the team you have no idea the level of effort it takes to support this new version while ensuring it doesn't break others. Maybe take a step back and realize the team has no good reason to withhold this update- it's in everyone's best interest to get it out there. I'm going to trust that they're doing all they can to make this happen and just sit tight.

Instead, let's just hope the plan for future versions is much better orchestrated.

[Mithras]

But the sarcasm and up-in-arms over how "easy" this problem is to fix is ridiculous.

It's usually changing this
<TargetFramework>netcoreapp3.1</TargetFramework>
to this
<TargetFrameworks>netcoreapp3.1;net5.0</TargetFrameworks>
and maybe fixing few errors after

[Methuselah96]

While I agree with trying to keep the conversation positive, I don't have much reason to hope that future versions will be better orchestrated. This transition has been worse than the transition to .NET Core 3.0. During that transition there was feedback from the community that there could have been more clear, up-front communication and coordination regarding the Azure Function release in correspondence with the .NET release.

One practical way to have better up-front communication and coordination would be to publish a roadmap that specifies at what date Azure Functions plans on being (fully) compatible (in production) with each upcoming version of .NET and then sticking to that. Until some practical steps like that are taken, I will assume that there is no plan for increased communication and coordination since this type of feedback has been given in the past to no effect.

Meanwhile I've been working on transitioning some of our Functions to AWS Lambda to see if the grass is greener on the other side.

[jeffhollan]

Yes a lot in this thread to process, and also want to try to keep this issue from becoming a mega-issue that has a bunch of small requests (just make sure there are specific issues for any bugs hit here). That said, can hopefully help some.

First, you should notice a few updates to the Microsoft.Azure.Functions.Worker.Sdk and Microsoft.Azure.Functions.Worker packages that resolve the issue of .NET 5 packages. I was just testing it out with an entity framework 5 sample I'm putting together - it's not quite working just yet, but hoping to get it soon.

In terms of roadmap and comms, gave some background on why .NET 5 is a bit unique for functions in this post. The tl;dr is when we version our runtime (which is shared across all languages and experiences) we have to consider things like support lifecycle. That said we want to provide support for all languages, and this .NET 5 worker will provide support.

Know this worker is still in preview. The hope is that this month a few things will land:

1. Tooling. Visual Studio and VS. We know tooling is an important part of the .NET experience, and working closely with those teams to ship experiences that support authoring .NET 5 functions
2. Improve the features in this preview. Some good discussion around things like the HttpRequestData object, and some other patterns

Once those land, we'll mark this as go-live and hopefully that unblocks everyone.

In terms of past then, a blog post is coming that details more, but we will have a preview for .NET 6 functions (which will allow either traditional in-proc or out-of-proc project structures) in the coming weeks (sometime after the .NET 6 preview releases). Our goal the entire team is behind is that on Day 1 of .NET 6 GA, .NET 6 functions will be GA across all tools.

I know this .NET 5 release has been frustrating. The team has been working as hard as possible to address the issues. At this point our top priority is accomplishing the 2 objectives stated above - I'd ask if folks have issues make sure you have an issue in the right repo so we can address. Feel free to shoot me an email if you have any other questions or concerns - jeff.hollan at microsoft.

[drdamour]

the out of process has too many limitations though, it'd be great if you could find a way to support in process for non LTS releases going forward too

[jeffhollan]

@drdamour agree 100%. We have some stuff we are starting work on this year so that come .NET 7 our hope 🤞 is that it will work just like the in proc stuff, WITH the nice things from out of proc (more control over Main and configuration and startup)

So .NET 5 will be an improved version of this preview, but still have differences. .NET 6 will have all the stuff v3 has, but on .NET 6 (preview out during first half of this year), and .NET 7 should feel like .NET 6 will

[pseabury]

.Net 7 is late 2022 so 2023 really... that's disappointing.

[jeffhollan]

Though to be clear, .NET 6 is the next version that will have full feature parity, and as stated preview coming in the next weeks / months (H1 this year)

[pseabury]

@jeffhollan - I know. I shouldn't have written that but it's frustrating. I know you guys are working hard to support our workflows, and I sincerely appreciate it. We are a tiny company with very limited resources that depends on (prefers?) the ability to deploy all of our bits on a single target. It's a luxury for some but a necessity for us. That was my one shot, and I'm more inclined to help be part of the solution than the problem. I fear that the OOP stuff maybe more of an issue for us with 5/6 than others because we actually use Roslyn in-proc to dynamically parse/run C# code and performance is a feature for us. I hope to have the bandwidth to test this soon, but based on what I can learn here I'm not optimistic that we can stay on one codebase.

[jeffhollan]

Yes If wanting to move from 5 -> 6 with little effort you’d likely stay on the “out of proc” train, which could make some of that tricky (though I don’t know specifics). .NET 6 will have in proc, but would require some refactoring to move from 5 -> 6. Totally get the frustration with that

[Napalmpje]

What would have been so wrong to focus on continuous support of .NET core 5 in language and hosting, and if they really wanted to rewrite the entire approach to create a product on the side.
Make it Azure Functions G2 or something like that.

[mwwhited]

How about an update?

[lbargery]

Also very interested in update here, we tried to move to ef core 5 yesterday but found it didn't work with the old functions run-time so are now blocked on ef core 5 and net core 5 behind functions sadly. Appreciate it's probably not an easy fix though!

[pseabury]

@jeffhollan since the NET5 worker process is new, can you summarize or point to a summary of the limitations the OOP worker will have in relation to the In-Proc v3 functions now? I've already looked here

[VaclavElias]

This might be helpful for some of us..

https://codetraveler.io/2021/02/12/creating-azure-functions-using-net-5/

[Mithras]

There is already an issue https://github.com/Azure/azure-functions-dotnet-worker-preview/issues/39
But I'll repeat it here. There needs to be a way to programmatically provide secrets to the host (from KeyVault, for example). Right now local.settings.json is the only way to specify connection strings, etc which is unacceptable.

[anthonychu]

@Mithras Would .NET user secrets work for you for storing secrets locally? Its values should be accessible by triggers and bindings. Currently not supported in dotnet-isolated projects but added a PR to address: https://github.com/Azure/azure-functions-core-tools/pull/2464

Key Vault References is the recommended approach in production and it works today.

[chris-oswald]

@anthonychu, will "launchSettings.json" work in the future for local testing and development once IDE support is built? That's where I've typically stored a lot of configuration values.

[Mithras]

@anthonychu None of these is working today. Please read the issue I linked. There is no way of passing any secrets to the host.
So if you have
[ServiceBusTrigger("xxx", "yyy", Connection = "zzz")]
there is no way of loading "zzz" from KeyVault or anywhere really. Host is initializing all the triggers before any of the user code is even called.

[hansmbakker]

@anthonychu

Key Vault References is the recommended approach in production and it works today.

I believe that Key Vault references are unpractical if you have network restrictions on your Key Vault (e.g. you limit your access to a VNet). In that case azure cannot access the secrets to inject them in the app service / function app.

See this user voice feedback for reference.

Is there any suggestion for that case?

(As a workaround I usually inject the secrets in program.cs / startup.cs by using key vault as a configuration provider)

[mwwhited]

These workarounds are way to convoluted for large development teams. We are stuck on choosing between staying on 3.1 until 6 is released (and hoping we can actually update and not have more delays) or dropping azure functions and just converting back to webapi and hosted instances. Hosted instances has the advantage it will be easier to port to other platforms so that's my current plan.

[rubo]

Same here.
When .NET 5 has been released, Microsoft promoted it from every corner and advocated to migrate to it. We did and when got to Azure Functions... Voila!
Given the discussions in this thread, the message from the Azure Functions team, let's be honest, sounds like "_We don't care much about .NET 5 cause it's not LTS_". You guys knew that long before the .NET 5 release and could warn the community that the situation will be like this. There are months passed since .NET 5 release but we're far from having .NET 5 in Azure Functions for real-world apps. No durable tasks, strange workarounds for simple things available out-of-the-box in Functions v3, slow overall progress, no feature parity. I just can't believe that the same company is behind .NET 5 and Azure Functions. I do understand there's a ton of work to do to make it out-of-process but couldn't have all this work been started earlier?
We have libraries shared between our .NET 5 projects and Azure Functions project and all those libraries can't be migrated to .NET 5 without voodoo things just because of Azure Functions. And moving away from Azure Functions might bring less pain than handling different .NET versions in our projects.
Total disappointment.

[qsdfplkj]

Just a thought but wouldn't it be possible to create a few forks by building the entre stack with a few different dependencies?

[Mithras]

They don't even need a fork. They can just multitarget: https://github.com/Azure/azure-functions-host/issues/6674#issuecomment-774332688

[fabiocav]

@Mithras the issue is not about a technical challenge making something available with support for .NET 5. That's the easy part, but when running a service, a lot of other considerations need to me made, we just went through a similar process with .NET 2.2, and I can tell you that was not a comfortable position for a lot of our customers.

We are working on the path to eliminate this issue altogether and put customers in control of what .NET versions they use and when, and that is what is happening with the .NET 5 support being worked on here

For .NET 6, our goal is to have support for it the same day it GAs. Once the first Functions preview for .NET 6 is released, we'll also be tracking with the .NET 6 previews as they are released.

[onionhammer]

I dont understand how app service can support .net 5 but azure functions cant.

[cygnim]

@Mithras the issue is not about a technical challenge making something available with support for .NET 5. That's the easy part, but when running a service, a lot of other considerations need to me made, we just went through a similar process with .NET 2.2, and I can tell you that was not a comfortable position for a lot of our customers.

.NET 2.2 was released in December, 2018. Were there no lessons learned to make the next release go smoother?

The part that bothers me more than anything is that the Azure Functions team seems to have been completely surprised that .NET 5 was released and that people would expect to be able to use it right away.

Everyone here is aware that the Azure Function team is now scrambling to come up with a solution. What's been missing is a formal acknowledgement that .NET Core versioning was a huge blind spot for the Azure function team and they weren't prepared for this major release like they should have been. A little contrition would go a long way instead of the "yeah, we hear you, it's a problem, we're fixing it, just wait." What we want to hear is "we're sorry, we screwed up, we should have planned for this and we did not. We'll do better, here's the plan."

The versioning story for .NET Core has been known as far back as 2015. This isn't version 1.0, this is 5 (I know we skipped 4, the point still stands).

I just want a formal acknowledgement that:

1. The Azure Functions team knows and will respect the .NET Core versioning process- that new versions will be supported the day they are released.
2. Acknowledgement that planning was inadequate and what steps will be taken in the future.
3. A timeline for fully-supported Azure Functions on .NET 5.

[mike-jewell]

We've started to move to IHostedServices as this has been a huge problem for us. We have other other issues that exist with functions that haven't been resolved also around hosting on linux containers:

System.IO.IOException: The configured user limit (4096) on the number of inotify instances has been reached, or the per-process limit on the number of open file descriptors has been reached

The lifecycle events seem to prevent app insights from logging and a host of other problems we've tried to work with azure support for resolution without success.

We hoped that this newer version would help resolve those issues, but there is no newer version. I have also attempted to use the preview and been stuck with configuring app settings.

Ranting here a bit, but this thread show most of my frustrations. IHostedServices is the new solution for us as this has become a massive headache keeping our nugets aligned across solutions.

[jeffhollan]

@cygnim

1. Yep - we're very aware and plan (as communicated) to have support for .NET 6 on release day and future versions from there. will likely publish a .NET Functions roadmap blog in the coming weeks
2. I'd correct you here - we were very aware of .NET 5 and have been in conversations and planning around how to support (even before the first .NET 5 bits dropped). It wasn't an issue of planning, it truly was an issue of resourcing. Unsurprisingly 2020 was a pretty big and disruptive year for many, and one of the results was some significant product growth for the functions service. We have been prioritizing improvements to the platform and existing features that were already GA over new languages like .NET 5. That pushed our development time here a bit and put us further back than we intended. We're making the right adjustments and changes from what we saw (platform / runtime improvements that put us in a better spot, as well as resourcing). Realize folks are eager to use bits right away but not accurate to say this caught us by surprise - but still learnings and improvements we are making.
3. We're pushing out preview releases about every week now. Hope to have production ready release in the next few weeks. Keep an eye out

I know folks are frustrated, but if you have issues with the preview please open issues we can track. Hard for us to manage getting these releases out while also keeping the thread under control. @mike-jewell not sure what you are seeing but seems it warrants it's own issue.

[mike-jewell]

I agree, and I have done:

https://github.com/dotnet/runtime/issues/40350

which leads to here:

https://github.com/dotnet/runtime/issues/37664

It seems that the limit increased from 1024 to 4096, which made the problem go away temporarily. Used azure support and hit a wall.

Anyway, its separate from this issue. I was hoping this release would fix it. But its lagged so far behind and made maintenance of our products too hard, so we are looking at IHostedServices

[cygnim]

1. I'd correct you here - we were very aware of .NET 5 and have been in conversations and planning around how to support (even before the first .NET 5 bits dropped). It wasn't an issue of planning, it truly was an issue of resourcing. Unsurprisingly 2020 was a pretty big and disruptive year for many, and one of the results was some significant product growth for the functions service. We have been prioritizing improvements to the platform and existing features that were already GA over new languages like .NET 5. That pushed our development time here a bit and put us further back than we intended. We're making the right adjustments and changes from what we saw (platform / runtime improvements that put us in a better spot, as well as resourcing). Realize folks are eager to use bits right away but not accurate to say this caught us by surprise - but still learnings and improvements we are making.

I'll accept your correction, but if the situation was well known internally, was there ever any PR about .NET 5 and Azure Functions at release? Blog posts? Official documentation? Was any effort made to communicate to the general public that Azure Functions would not support the latest version of .NET at release or anytime soon thereafter?

As far as I can tell, .NET 5 has been in "Preview" for a couple months now, but there is no mention of this at all in the official documentation.

If there was awareness internally, it certainly wasn't communicated to end users who were bombarded with ".NET 5 is out, upgrade today!" messaging.

[EricBos]

We have been prioritizing improvements to the platform and existing features that were already GA over new languages like .NET 5. That pushed our development time here a bit and put us further back than we intended.

The way I interpret this: let's not call call the fire department while our house is on fire, but let's build that awesome shed instead.

[MattJeanes]

I think overall this would have gone down a lot better with proper communication to users, Azure Functions is not some niche little product it's a huge part of many businesses and not to mention created and maintained by Microsoft itself.

Naturally people assume that with a new .NET version, first party products such as Azure Functions were going to be upgraded day one or at least not far behind, and the fact that there was not even a public roadmap and still isn't really on when we can expect a GA Azure Functions on .NET 5 is really disappointing.

For me, this manifested as a huge time waste as I spend a while upgrading our entire codebase to .NET 5 only to find out that Azure Functions doesn't work at all, and by the time it does eventually come out my changes will be very stale and I'll have to do it again. I have no doubt many other users have had the same experience.

If there was some little note on the .NET 5 release blog post or somewhere similar that Azure Functions were not yet running on it, click here to see why it's not ready and our roadmap for when this will be ready, I think it would have saved a lot of headaches.

I don't want to sound like I'm having a go at the team or anyone in particular, I really like the improvements that are being made and I understand that they take time to do, just better communication with the public would have been much appreciated. Thank you.

[mwwhited]

For me, this manifested as a huge time waste as I spend a while upgrading our entire codebase to .NET 5 only to find out that Azure Functions doesn't work at all, and by the time it does eventually come out my changes will be very stale and I'll have to do it again. I have no doubt many other users have had the same experience.

I've done that twice already. Once at Launch just to be all WTF, why doesn't this work to then see a message a few days later saying they decided to do this out of process mess. Then a second time a few months after the first with upgrading everything a second time (including fighting the breaking changes for .Net 5 a second time) just to find out that even if I did jump though all the hoops to get the preview running on my machine, the build/deployment updated to get the hacked version on Azure, and change all of my configuration processes (because again... WTF) I would still have required libraries that are not compatible because of the out-of-process and I would have a hell of a time getting my dev teams to handle all the workarounds.

[louisoftokyo]

@jeffhollan

Is there any word on a date as to when VS support will be released? Are we looking more at April or May now?

[kinetiq]

Can someone please answer this for me?

• What is preventing people from using the .NET Core 5 AF preview today?
• Is it just something people shouldn't even attempt right now?
• We are using EF Core. Am I going to find that this doesn't work in the preview, but will work in the coming GA?

I see a lot of frustrated people referring to issues that all the other frustrated people know about, but that I do not. :) I do see a lack of DF support, which does not impact us, fortunately. I also see a fairly involved upgrade process for the preview, but I can live with that.

We have an app running .NET Core 5, and my functions are still on 3.1 - because of how our AF API works, were able to defer deployment hoping for a GA. It has now been... Longer than expected. There will be changes that require us to move to Core 5 and deploy very soon, so I need to know how much trouble we might be facing. Thanks!

[onionhammer]

@kinetiq most .NET 5 things work in the .NET 5 AF preview today, the bad news is the only things that dont work is the 'Azure Functions' part.. you know, the part where you can bind to things and output things

[jeffhollan]

@kinetiq only potential thing to be aware of is that there may be some minor changes in APIs between preview and when it goes production ready. That said we’re currently at a release candidate for APIs so expect this is a good time to start. I have a sample of EF 5 here https://github.com/jeffhollan/functions-net5-entityframework

@onionhammer input and output bindings work - I believe I have both in my sample. What does not work is binding to SDK types (e.g. CloudBlockBlob instead of string or byte[]) https://docs.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide

[onionhammer]

Yes, lack of byte[], and stream, iasynccollector bindings are a big limitation for me

[kinetiq]

@onionhammer @jeffhollan That's very helpful, thanks!

So I can use bindings like ServiceBusTrigger, TimerTrigger, SendGrid, etc right?

Does the local experience work? I saw some hints that people were having trouble with that.

[jeffhollan]

Yes all bindings should be supported at this point. Local debug works, the thing that’s rolling out this week is more tools to template your project (CLI and VS Code I think are landing even today?).

[kinetiq]

@jeffhollan Great, I'm sure this summary at the end will help other people as well.

[rubo]

@jeffhollan Are durable functions supported? Do they work?

[jeffhollan]

Ah yes I'm sorry, I misspoke, all bindings work but Durable is a very special binding and does not work today https://docs.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide#differences-with-net-class-library-functions

[RichMercer]

Ah yes I'm sorry, I misspoke, all bindings work but Durable is a very special binding and does not work today https://docs.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide#differences-with-net-class-library-functions

I thought bindings like CosmosDB weren't supported either?

There's also no direct support for types inherited from underlying service SDKs, such as DocumentClient and BrokeredMessage.

If they are supported, are there any examples of how to implement them?

[jeffhollan]

The bindings work, you just can't pass in a DocumentClient as a parameter. Only universal types like string and byte[] are supported. You can use a DocumentClient but you'll need to pull in the Cosmos SDK and spin it up in your own code

[qsdfplkj]

Just tell me when it's all done so I can update.

[tjrobinson]

Given a lot of the technology is shared between Azure Functions and Web Jobs - does the above apply to Web Jobs too?

[ModernRonin]

@jeffhollan Does this mean (cosmosdb) change feed triggered functions work now? If yes, great, because soon I will be in the same place as @kinetiq where I have to upgrade my functions :-)

Thanks!

[rubo]

Ah yes I'm sorry, I misspoke, all bindings work but Durable is a very special binding and does not work today https://docs.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide#differences-with-net-class-library-functions

@jeffhollan Does this mean no durable functions for .NET 5 at all? If it doesn't, any ETA? Thank you.

[jeffhollan]

We will be publishing a blog post this week that goes into more details of some of the roadmap. Durable won't be supported in the short term for these isolated process functions (.NET 5). We know it will be supported for .NET 6, it's possible we make some progress this calendar year to get it working in .NET 5 as well, but at this time don't have an ETA or hard commitment on when Durable may light up in these isolated processes. Best case would be sometime later this calendar year.

[onionhammer]

@jeffhollan this list is very helpful

https://docs.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide#differences-with-net-class-library-functions

Can you update it to include whether things like 'byte[]' and 'Stream' are supported? When you say "All bindings work" does that include bindings to byte[] and Stream? I've already migrated twice only to hit a wall and revert changes back to netcoreapp3, so It'd be useful to know what is actually still broken, what's "coming soon" and what wont ever be supported

[Mithras]

Can you also make sure your example app is up to date?
For example, here https://docs.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide#differences-with-net-class-library-functions you are saying that Microsoft.Azure.Functions.Worker.Extensions.* should be used instead of Microsoft.Azure.WebJobs.Extensions.* but that's not what I see in the example app.

I don't think these new packages are working anyway. When I replace Microsoft.Azure.WebJobs.Extensions.Storage with Microsoft.Azure.Functions.Worker.Extensions.Storage I'm getting this

Do I reference both?

Also, your example app is missing [TimerTrigger]. It's especially important because as of right now I have to define my own TimerInfo and ScheduleStatus to make it work. It's not documented anywhere and there is no example. I just found a workaround it in one of the dozens issues here.

[Mithras]

Nevermind, there is now a new example app here: https://github.com/Azure/azure-functions-dotnet-worker/tree/main/samples/SampleApp
Dunno if it works.

[quintusm]

I sincerely hope someone is also looking at how all of this is going to work with that other .Net language, F#. And that there will be templates and samples provided

[skyfrk]

The Azure Functions .NET Worker is now GA!

https://github.com/Azure/azure-functions-dotnet-worker/releases/tag/1.0.0

[fabiocav]

Providing an update here (as mentioned by @skyfrk above); The .NET Worker, with .NET 5 support is now GA, and you can find more information about the .NET roadmap for Azure Functions here: https://techcommunity.microsoft.com/t5/apps-on-azure/net-on-azure-functions-roadmap/ba-p/2197916

Moving forward, for issues related to .NET 5, please open new issues at https://github.com/Azure/azure-functions-dotnet-worker/issues

For in-proc questions and questions related to .NET 6 support, please feel free to continue to use this repo.

Thank you all for the patience!