Skip to content

Update WorkerExtension project generation to net10.0 in SDK#3447

Draft
jviau wants to merge 2 commits into
mainfrom
u/jviau/workerextension-net10-sdk
Draft

Update WorkerExtension project generation to net10.0 in SDK#3447
jviau wants to merge 2 commits into
mainfrom
u/jviau/workerextension-net10-sdk

Conversation

@jviau

@jviau jviau commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Issue describing the changes in this PR

resolves #3444

Pull request checklist

  • My changes do not require documentation changes
    • Otherwise: Documentation issue linked to PR
  • My changes should not be added to the release notes for the next release
    • Otherwise: I've added my notes to release_notes.md
  • My changes do not need to be backported to a previous version
    • Otherwise: Backport tracked by issue/PR #issue_or_pr
  • I have added all required tests (Unit tests, E2E tests)

Additional information

Summary

Updates the SDK's generated WorkerExtensions.csproj to target net10.0 instead of net8.0 for v4 function apps. .NET 8 reaches end-of-life on November 10, 2026.

Changes

  • sdk/Sdk/ExtensionsCsprojGenerator.cs — the generated WorkerExtensions.csproj (v4 apps) now defaults to net10.0.
  • sdk/Sdk/Constants.cs — replaced the unused Net80 constant with Net100 = "net10.0".
  • test/Sdk.Generator.Tests/FunctionMetadata/ExtensionsCsProjGeneratorTests.cs — updated the expected v4 csproj to net10.0.
  • eng/build/extensionValidationProjectTemplate.txt — CI extension-validation template bumped net8.0 → net10.0 (matches the exact file called out in WorkerExtension still uses .NET 8 #3444).
  • sdk/release_notes.md — added a release note under Microsoft.Azure.Functions.Worker.Sdk.

The v3 path (netcoreapp3.1) is unchanged.

🚫 Blocked

This PR is blocked pending the rollout of the Functions host. We must wait until the net10 version of the Functions host has rolled out broadly and customers have migrated, to ensure the generated extension project (net10) is compatible with the host environment they run on. Merging before then risks generating extension projects that customers' hosts cannot load.

Do not merge until host rollout is confirmed.

Verification

  • Built sdk/Sdk/Sdk.csproj cleanly (0 warnings/errors).
  • Invoked the generator against the built assembly and confirmed v4 emits <TargetFramework>net10.0</TargetFramework> (plus the _VerifyTargetFramework guard), while v3 still emits netcoreapp3.1.

Note: The full test project doesn't build in this environment due to a pre-existing MSB3030 issue in two unrelated test resource projects (reproduces on a clean tree), so unit tests should be validated in CI.

The generated WorkerExtensions.csproj (v4 apps) now targets net10.0 instead of net8.0. .NET 8 reaches EOL on November 10, 2026.

Fixes #3444
@jviau jviau added the blocked Items that cannot move forward at the moment. label Jul 1, 2026
@jviau

jviau commented Jul 1, 2026

Copy link
Copy Markdown
Contributor Author

🚫 BLOCKED — do not merge.

This PR is blocked pending the rollout of the Functions host. We must wait until the net10 version of the Functions host has rolled out broadly and customers have migrated to it before merging.

Rationale: this change makes the SDK generate the WorkerExtensions project targeting net10. If customers are still running on a host that predates net10 support, the generated extension project would be incompatible with their host environment. Merging must wait until host rollout is confirmed so we can be sure customers are on the net10 version of the host.

Unblock criteria: net10 Functions host rollout complete / customers confirmed migrated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

blocked Items that cannot move forward at the moment.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

WorkerExtension still uses .NET 8

1 participant