Skip to content

ci: Fix CI for .NET 10 SDK and Windows runner compatibility#3476

Merged
tippmar-nr merged 7 commits into
mainfrom
ci/dotnet-build-integration-tests
Mar 11, 2026
Merged

ci: Fix CI for .NET 10 SDK and Windows runner compatibility#3476
tippmar-nr merged 7 commits into
mainfrom
ci/dotnet-build-integration-tests

Conversation

@tippmar-nr

@tippmar-nr tippmar-nr commented Mar 11, 2026

Copy link
Copy Markdown
Member

Summary

  • Fix MSI installer signtool discovery: Replace hardcoded Windows SDK path (10.0.19041.0) with dynamic glob-based discovery, and add required /fd SHA256 flag for newer signtool versions
  • Use windows-2025-vs2026 (beta) runners for integration test build and run jobs, which provides MSBuild 18.x needed by .NET 10 SDK 10.0.200+
  • Switch NuGetHelper build to dotnet build in siteextension_release workflow, removing unnecessary setup-msbuild dependency
  • Standardize .NET 10 SDK setup step naming across all workflows

Context

.NET 10 SDK 10.0.200 was released and setup-dotnet with dotnet-version: 10.0.x began resolving to it. Unlike the 10.0.1xx band (which requires MSBuild 17.14+), the 10.0.2xx band requires MSBuild 18.0+. This broke integration test builds on windows-2022 runners which only have VS 2022 / MSBuild 17.x.

Separately, moving to windows-2025 runners exposed two issues in the MSI installer project:

  1. signtool.exe path was hardcoded to SDK version 10.0.19041.0 which doesn't exist on newer runners
  2. Newer signtool.exe versions require an explicit /fd digest algorithm flag

Test plan

  • build-integration-tests job succeeds on windows-2025-vs2026
  • build-unbounded-tests job succeeds on windows-2025-vs2026
  • run-integration-tests jobs pass
  • run-unbounded-tests jobs pass
  • MSI installer builds succeed with dynamic signtool discovery
  • siteextension_release workflow NuGetHelper build succeeds with dotnet build

🤖 Generated with Claude Code

@codecov-commenter

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.68%. Comparing base (4cc20d0) to head (9394ba3).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3476      +/-   ##
==========================================
- Coverage   81.69%   81.68%   -0.02%     
==========================================
  Files         508      508              
  Lines       33972    33972              
  Branches     4006     4006              
==========================================
- Hits        27753    27749       -4     
- Misses       5260     5263       +3     
- Partials      959      960       +1     
Flag Coverage Δ
Agent 82.66% <ø> (-0.02%) ⬇️
Profiler 71.75% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1 file with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@tippmar-nr tippmar-nr marked this pull request as ready for review March 11, 2026 20:06
@tippmar-nr tippmar-nr requested a review from a team as a code owner March 11, 2026 20:06

@jaffinito jaffinito left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

@tippmar-nr tippmar-nr merged commit 1799395 into main Mar 11, 2026
330 of 344 checks passed
@tippmar-nr tippmar-nr deleted the ci/dotnet-build-integration-tests branch March 11, 2026 20:25
dotnet nuget list source
Write-Host "MSBuild.exe -restore -m -p:Configuration=Release -p:AllowUnsafeBlocks=true ${{ env.nuget_helper_project_path }}"
MSBuild.exe -restore -m -p:Configuration=Release -p:AllowUnsafeBlocks=true ${{ env.nuget_helper_project_path }}
dotnet build --configuration Release ${{ env.nuget_helper_project_path }}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the build no longer require the AllowUnsafeBlocks setting?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants