chore(samples): move the Azure Functions sample to Azure.Functions.Sdk and net11.0 by jamescrosswell · Pull Request #5752 · getsentry/sentry-dotnet

jamescrosswell · 2026-10-20T01:33:48Z

Moves Sentry.Samples.OpenTelemetry.AzureFunctions, the last sample still on net10.0, to net11.0.

Microsoft.Azure.Functions.Worker.Sdk will not get .NET 11 support. Its 2.1.0 targets warn that .NET 11 needs the new Azure.Functions.Sdk MSBuild SDK, which reached 1.0 in September. This follows that package's migration guide: Sdk="Azure.Functions.Sdk", drop the Worker.Sdk reference, OutputType and AzureFunctionsVersion. Microsoft.Azure.Functions.Worker goes to 2.52.0, the version the guide expects.

Why the SDK version is in `global.json`

The SDK version is pinned under msbuild-sdks in global.json rather than in the Sdk attribute. During restore the SDK generates obj/azure_functions/azure_functions.g.csproj with a version-less <Project Sdk="Azure.Functions.Sdk">, expecting it to reuse the outer project's resolution. With Sdk="Azure.Functions.Sdk/1.0.1" that works for a single-node build or restore + build --no-restore. A default multi-node dotnet build fails in GetFunctionsExtensionFiles with MSB4236: The SDK 'Azure.Functions.Sdk' specified could not be found. msbuild-sdks is where the NuGet SDK resolver looks for a version when the project gives none. Related upstream: Azure/azure-functions-dotnet-worker#3506.

Not a user-facing change. #skip-changelog

Closes #5548

🤖 Generated with Claude Code

…k and net11.0 Microsoft.Azure.Functions.Worker.Sdk won't support .NET 11; its 2.1.0 targets point to the new Azure.Functions.Sdk MSBuild SDK instead. The SDK version is pinned in global.json's msbuild-sdks: the generated obj/azure_functions/azure_functions.g.csproj references the SDK without a version, which fails to resolve in a multi-node dotnet build (MSB4236) when the version is only in the outer project's Sdk attribute. Closes #5548 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

codecov · 2026-10-20T01:56:00Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.17%. Comparing base (2194c92) to head (72a532f).

Additional details and impacted files

@@            Coverage Diff            @@
##           version7    #5752   +/-   ##
=========================================
  Coverage     76.17%   76.17%           
=========================================
  Files           526      526           
  Lines         19265    19265           
  Branches       3729     3729           
=========================================
  Hits          14676    14676           
  Misses         3734     3734           
  Partials        855      855

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

…s-sdk-net11

jamescrosswell · 2026-10-20T22:18:50Z

@@ -1,18 +1,12 @@
-<Project Sdk="Microsoft.NET.Sdk">
+<Project Sdk="Azure.Functions.Sdk">


Explanation for reviewers

Microsoft.NET.Sdk.Web is Microsoft.NET.Sdk plus ASP.NET defaults. Azure.Functions.Sdk works the same way. Its Sdk.props and Sdk.targets start by importing Microsoft.NET.Sdk.Worker, which builds on Microsoft.NET.Sdk:

Azure.Functions.Sdk → Microsoft.NET.Sdk.Worker → Microsoft.NET.Sdk

l
So everything we had before is still here, with a Functions layer on top:

OutputType and AzureFunctionsVersion are defaults now, set by the Worker SDK and the Functions SDK. That's why these have been deleted from the project.

It adds the Functions build steps: generating function metadata, writing worker.config.json and extensions.json, wiring dotnet run to start the Functions host, and publishing to Azure.

Package reference vs SDK

The old setup did roughly the same work, but delivered it as an ordinary package, Microsoft.Azure.Functions.Worker.Sdk:

PackageReference (old) Sdk attribute (new)

When its logic loads After restore. NuGet generates obj/*.nuget.g.props/.targets, and the next evaluation imports the package's build/ files from there Before anything else, when MSBuild first evaluates the project

Can it change restore itself? No. Restore has already happened by the time it loads Yes. It hooks Restore to generate and restore azure_functions.g.csproj

Can it supply defaults you override? Not cleanly. Its .props come in through NuGet's import, so you had to set properties yourself Yes. Sdk.props runs before your body, the same way Microsoft.NET.Sdk does

Versioning Ordinary NuGet resolution Attribute or global.json, and never pulled in transitively

jamescrosswell · 2026-10-20T22:29:58Z

    "allowPrerelease": false
+  },
+  "msbuild-sdks": {
+    "Azure.Functions.Sdk": "1.0.1"


A bit annoying that we have to include this in the global.json file, for a single sample project, but there doesn't seem to be a way around that.

<Project Sdk="Azure.Functions.Sdk"> creates an extension project as an intermediate artefact of the build process, which has no version... Without this in global.json NuGet fails with MSB4236. Because it's done via an SDK reference, there's no way to do this as a build property :-(

msbuild-sdks in global.json is where the resolver looks when a project gives no version, so pinning it here covers both the sample project and the intermediate extension project.

There's a suggestion to fix this upstream:

[MSBUILD SDK] Building azure_functions.g.csproj outside the outer build fails with MSB4236 instead of AZFW0109 Azure/azure-functions-dotnet-worker#3506

Got it, but fair.
I've added a comment, maybe we just mention this on the code as well.

Covered by the comment now at the top of the sample project (db0e2b9), which is where someone copying the sample will look. global.json itself stays comment-free.

🤖 Addressed by Claude Code

…rsion Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…s-sdk-net11

The macOS leg of build.yml built Sentry.Maui.Device.TestApp for net9.0-android, net10.0-android and net10.0-ios, and nothing in build.yml runs it. In the run for #5752 on version7 that was the last 6 minutes of the 24.7-minute Build step, on the critical path. The Linux and Windows filters already exclude the app, and both device test workflows build it themselves. The macOS leg of verify-api builds the same filter, so it no longer builds the app either. The device test path filters now also cover what the app compiles and they didn't list: Sentry.Analyzers, Sentry.Testing.CrashableApp, the nested Directory.Build files and .editorconfig, which can fail the build because warnings are errors. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…verify-api and format-code (#5758) * ci: stop building the device test app in the macOS build job The macOS leg of build.yml built Sentry.Maui.Device.TestApp for net9.0-android, net10.0-android and net10.0-ios, and nothing in build.yml runs it. In the run for #5752 on version7 that was the last 6 minutes of the 24.7-minute Build step, on the critical path. The Linux and Windows filters already exclude the app, and both device test workflows build it themselves. The macOS leg of verify-api builds the same filter, so it no longer builds the app either. The device test path filters now also cover what the app compiles and they didn't list: Sentry.Analyzers, Sentry.Testing.CrashableApp, the nested Directory.Build files and .editorconfig, which can fail the build because warnings are errors. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * ci: serialize only the jobs that push in verify-api and format-code Both workflows put the whole run in the pr-auto-commit concurrency group, so each waited for the other to finish. On one PR, format-code started 35 minutes after its run was created, and on another verify-api waited 13 minutes. The group exists to keep their git pushes apart, so it now covers only accept-api-changes and the format-code job, and the API test matrix starts right away. Both still push from the head they checked out and fail as non-fast-forward if the branch moved in the meantime. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

jamescrosswell mentioned this pull request Oct 20, 2026

Migrate the Azure Functions sample to Azure.Functions.Sdk and net11.0 #5548

Closed

Merge remote-tracking branch 'origin/version7' into ai/azure-function…

6291d56

…s-sdk-net11

jamescrosswell linked an issue Oct 20, 2026 that may be closed by this pull request

Migrate the Azure Functions sample to Azure.Functions.Sdk and net11.0 #5548

Closed

jamescrosswell commented Oct 20, 2026

View reviewed changes

jamescrosswell marked this pull request as ready for review October 20, 2026 22:30

jamescrosswell requested a review from ric-oliv as a code owner October 20, 2026 22:30

github-actions Bot added the risk: medium PR risk score: medium label Oct 20, 2026

ric-oliv reviewed Oct 21, 2026

View reviewed changes

Comment thread ...ntry.Samples.OpenTelemetry.AzureFunctions/Sentry.Samples.OpenTelemetry.AzureFunctions.csproj

ric-oliv approved these changes Oct 21, 2026

View reviewed changes

chore(samples): note where the Azure Functions sample gets its SDK ve…

db0e2b9

…rsion Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ric-oliv mentioned this pull request Oct 21, 2026

ci: skip the device test app in the macOS build and stop serializing verify-api and format-code #5758

Merged

Merge remote-tracking branch 'origin/version7' into ai/azure-function…

72a532f

…s-sdk-net11

jamescrosswell merged commit 7f1d32c into version7 Oct 21, 2026
36 checks passed

jamescrosswell deleted the ai/azure-functions-sdk-net11 branch October 21, 2026 23:17

Navigation Menu

Repository navigation

chore(samples): move the Azure Functions sample to Azure.Functions.Sdk and net11.0 - #5752

chore(samples): move the Azure Functions sample to Azure.Functions.Sdk and net11.0#5752
jamescrosswell merged 4 commits into
version7from
ai/azure-functions-sdk-net11

jamescrosswell commented Oct 20, 2026

Uh oh!

codecov Bot commented Oct 20, 2026 •

edited

Loading

Uh oh!

jamescrosswell Oct 20, 2026

Uh oh!

jamescrosswell Oct 20, 2026

Uh oh!

ric-oliv Oct 21, 2026

Uh oh!

jamescrosswell Oct 21, 2026

Uh oh!

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		@@ -1,18 +1,12 @@
		<Project Sdk="Microsoft.NET.Sdk">
		<Project Sdk="Azure.Functions.Sdk">

	`PackageReference` (old)	`Sdk` attribute (new)
When its logic loads	After restore. NuGet generates `obj/*.nuget.g.props/.targets`, and the next evaluation imports the package's `build/` files from there	Before anything else, when MSBuild first evaluates the project
Can it change restore itself?	No. Restore has already happened by the time it loads	Yes. It hooks `Restore` to generate and restore `azure_functions.g.csproj`
Can it supply defaults you override?	Not cleanly. Its `.props` come in through NuGet's import, so you had to set properties yourself	Yes. `Sdk.props` runs before your body, the same way `Microsoft.NET.Sdk` does
Versioning	Ordinary NuGet resolution	Attribute or `global.json`, and never pulled in transitively

Conversation

jamescrosswell commented Oct 20, 2026

Why the SDK version is in global.json

Uh oh!

codecov Bot commented Oct 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

jamescrosswell Oct 20, 2026

Choose a reason for hiding this comment

Explanation for reviewers

Package reference vs SDK

Uh oh!

jamescrosswell Oct 20, 2026

Choose a reason for hiding this comment

Uh oh!

ric-oliv Oct 21, 2026

Choose a reason for hiding this comment

Uh oh!

jamescrosswell Oct 21, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Why the SDK version is in `global.json`

codecov Bot commented Oct 20, 2026 •

edited

Loading