Updating WorkerExtensions.csproj to net8

[jviau]

Description

Now that the functions host is net8, we should update the WorkerExtensions.csproj to net8.

Important

.NET6 being out of support is not a concern with WorkerExtensions.csproj. This project is purely a compile time mechanism to create an extension bundle for the functions host to load. The actual runtime used is determined by the functions host, which for dotnet isolated is NET8. Additionally, the .NET SDK used is determined by the build environment, not the TFM.

Concern

Some special cases may still load in the net6 in-proc host, such as logic apps. We will need to provide a way to ensure they remain on net6.

[kescherCode]

Concern: .NET 6 is out of support and will not receive security fixes. As such, this is security-relevant: If .NET 6 happens to have a security issue within it that is not purely in the dotnet 6 runtime, the WorkerExtensions would be affected.

[jviau]

@kescherCode that will not matter here: .net6 runtime is out of support. WorkerExtensions.csproj only uses net6 for a compile time dependency. The runtime is determined by the function host, which with dotnet-isolated is net8.

[kescherCode]

@jviau please read my comment again. I specifically pointed out that security issues can not only occur in the runtime.

[jviau]

@jviau please read my comment again. I specifically pointed out that security issues can not only occur in the runtime.

Can you give an example of a security issue?

[tbuquet]

Our use case is a custom trigger that pushes data from Salesforce and that needs to be updated. The client package has a dependency to net7.0, itself having a dependency to Microsoft.Extensions.Logging.Abstractions targetting net.7.0

When trying to update, I first tried to target net8.0 and WorkerExtensions wouldn't build. I then tried to target 6.0 and it built.

But then during runtime on Azure, I got the following error:
Could not load file or assembly 'System.Memory.Data, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
All I did was to update several Microsoft.Extensions.XXX packages to 8.0.X, and Azure.Data.Tables from 12.9.1 and 12.10.0
This also doesn't happen while debugging locally.

Are customer triggers simply not going to be supported in the future?
Because if they are, they would need to be targeting a version that is still supported.

Hope that's helpful!

[jviau]

The client package has a dependency to net7.0, itself having a dependency to Microsoft.Extensions.Logging.Abstractions targetting net.7.0

Microsoft.Extensions.Logging.Abstractions/7.0.0 has no requirement for net7. It supports many versions lower than net7.0, including net6.0 (also netstandard2.0 and others). https://www.nuget.org/packages/Microsoft.Extensions.Logging.Abstractions/7.0.0#supportedframeworks-body-tab

Could not load file or assembly 'System.Memory.Data, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.

This was an issue with the host and unrelated to the TFM of the worker extension project. System.Memory.Data was pinned to a lower version by the host. We have since addressed this, pending deployment still. Azure/azure-functions-host#10610

Are customer triggers simply not going to be supported in the future?
Because if they are, they would need to be targeting a version that is still supported

I understand how this can block custom triggers from taking on dependencies that rely on >net6.0. However, this isn't outright blocked today. It will just take manual effort on your part to hook into MSBuild targets and update WorkerExtension.csproj to be net8.0. #2763 would help with this also as you can take full control of the extension project, including targeting net8.0. But this is a power-user scenario - our SDK will no longer be verifying you are building a valid extension bundle.

[kescherCode]

@jviau so far, I am of course talking about hypotheticals. This has not happened yet.