[release/10.0] Source code updates from dotnet/dotnet

[tomerqodo]

Benchmark PR from qodo-benchmark#94

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (1) 📎 Requirement gaps (0)

1. Block-scoped namespace used 📘 Rule violation ✓ Correctness

Description

• WebSocketCompressionTests.cs uses a block-scoped namespace (namespace ... { ... }) instead of
  a file-scoped namespace declaration.
• This breaks the required C# convention in this repo and reduces consistency with modern C#
  formatting expectations.

Code

src/Components/test/E2ETest/ServerExecutionTests/WebSocketCompressionTests.cs[R16-17]

+namespace Microsoft.AspNetCore.Components.E2ETests.ServerExecutionTests
+{

Evidence

PR Compliance ID 8 requires file-scoped namespace declarations (ending with ; and no braces). The
updated file declares the namespace using braces, which is explicitly the failure condition.

AGENTS.md
src/Components/test/E2ETest/ServerExecutionTests/WebSocketCompressionTests.cs[16-17]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`WebSocketCompressionTests.cs` currently uses a block-scoped namespace. The compliance requirement mandates file-scoped namespace declarations in C# files.

## Issue Context
The file previously used `namespace ...;` but was changed to `namespace ... { ... }`, introducing an extra closing brace at the end of the file.

## Fix Focus Areas
- src/Components/test/E2ETest/ServerExecutionTests/WebSocketCompressionTests.cs[16-18]
- src/Components/test/E2ETest/ServerExecutionTests/WebSocketCompressionTests.cs[208-210]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Xcode path/name mismatch 🐞 Bug ⛯ Reliability

Description

• The macOS pipeline step claims to use Xcode 16.4.0 but still selects the Xcode 15.2.0 developer
  directory, making CI behavior misleading and harder to debug.
• This is duplicated in both public and internal job definitions, so the inconsistency affects all
  macOS runs.
• With the move to macOS-15 images, keeping an old Xcode path increases the chance of macOS CI
  breakage if that Xcode bundle is not present.

Code

.azure/pipelines/jobs/default-build.yml[R165-167]

      - ${{ if eq(parameters.agentOs, 'macOS') }}:
        - script: sudo xcode-select -s /Applications/Xcode_15.2.0.app/Contents/Developer
-          displayName: Use XCode 15.2.0
+          displayName: Use XCode 16.4.0

Evidence

The pipeline uses macOS-15 images but the Xcode selection command still targets Xcode_15.2.0 while
the display name was updated to 16.4.0, which is internally inconsistent and duplicated across
public/internal jobs.

.azure/pipelines/jobs/default-build.yml[104-167]
.azure/pipelines/jobs/default-build.yml[319-393]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The macOS pipeline step labels itself as using Xcode 16.4.0 but still selects `/Applications/Xcode_15.2.0.app/...`, which is inconsistent and can mislead troubleshooting.

### Issue Context
This appears in both the public and internal job template sections and coincides with upgrading macOS agents to macOS-15.

### Fix Focus Areas
- .azure/pipelines/jobs/default-build.yml[165-167]
- .azure/pipelines/jobs/default-build.yml[391-393]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Baseline validation disabled 🐞 Bug ✓ Correctness

Description

• Servicing builds now set ValidateBaseline=false, which disables the guardrail that enforces the
  baseline matches the previous release.
• The checked-in baseline is still 9.0.0, while the repo is configured for 10.0.1 servicing;
  disabling validation masks this drift and risks incorrect dependency/version coherency decisions
  during servicing.
• This can allow servicing builds to proceed with an outdated baseline rather than forcing the
  baseline regeneration/update that the build system expects.

Code

eng/Versions.props[R12-14]

+    <AspNetCorePatchVersion>1</AspNetCorePatchVersion>
    <PreReleaseVersionIteration></PreReleaseVersionIteration>
-    <ValidateBaseline>true</ValidateBaseline>
+    <ValidateBaseline>false</ValidateBaseline>

Evidence

ValidateBaseline was turned off in eng/Versions.props. At the same time, the baseline file
reports AspNetCoreBaselineVersion=9.0.0. The build has an explicit target that errors for
servicing builds when ValidateBaseline==true and the baseline does not match
PreviousAspNetCoreReleaseVersion; disabling validation prevents that enforcement.

eng/Versions.props[10-33]
eng/Baseline.Designer.props[1-6]
eng/targets/Packaging.targets[3-12]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`ValidateBaseline` is disabled for a servicing branch while the checked-in baseline version indicates drift (still 9.0.0). This bypasses an explicit servicing build check intended to force baseline updates.

### Issue Context
Servicing builds rely on baseline coherency for reference/version restrictions. The repo already contains an MSBuild target that enforces baseline freshness when `ValidateBaseline` is true.

### Fix Focus Areas
- eng/Versions.props[10-16]
- eng/Baseline.Designer.props[1-6]
- eng/Baseline.xml[1-15]
- eng/targets/Packaging.targets[3-12]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View more (1)

4. BUILD002 gated to patch1 🐞 Bug ✓ Correctness

Description

• The BUILD002 error (preventing removed baseline references in servicing) is now gated behind
  AspNetCorePatchVersion == 1.
• For later servicing patches (10.0.2+), this disables the stated policy enforcement (“not allowed
  in a servicing update”), increasing risk of shipping breaking dependency removals in a patch.
• This is a long-term regression: the first patch remains checked, but subsequent patches silently
  lose the guardrail.

Code

eng/targets/ResolveReferences.targets[R210-213]

    <Error
-        Condition=" '$(IsServicingBuild)' == 'true' AND '@(UnusedBaselinePackageReference->Count())' != '0' "
+        Condition=" '$(IsServicingBuild)' == 'true' AND '@(UnusedBaselinePackageReference->Count())' != '0' AND '$(AspNetCorePatchVersion)' == '1'"
        Code="BUILD002"
        Text="Package references changed since the last release. This could be a breaking change and is not allowed in a servicing update. References removed:%0A - @(UnusedBaselinePackageReference, '%0A - ')" />

Evidence

The BUILD002 check is explicitly described as disallowing potentially breaking changes in servicing
updates, but the new condition adds a hard gate AspNetCorePatchVersion == 1, which prevents the
check from running for any later servicing patch versions.

eng/targets/ResolveReferences.targets[210-213]
eng/Versions.props[31-33]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The BUILD002 servicing safety check is restricted to patch version 1 only, disabling enforcement for subsequent servicing patches.

### Issue Context
BUILD002’s message states the behavior is “not allowed in a servicing update”, which should apply across all servicing patch versions.

### Fix Focus Areas
- eng/targets/ResolveReferences.targets[210-213]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[qodo-code-review]

1. Block-scoped namespace used 📘 Rule violation ✓ Correctness

• WebSocketCompressionTests.cs uses a block-scoped namespace (namespace ... { ... }) instead of
  a file-scoped namespace declaration.
• This breaks the required C# convention in this repo and reduces consistency with modern C#
  formatting expectations.

Agent prompt

## Issue description
`WebSocketCompressionTests.cs` currently uses a block-scoped namespace. The compliance requirement mandates file-scoped namespace declarations in C# files.

## Issue Context
The file previously used `namespace ...;` but was changed to `namespace ... { ... }`, introducing an extra closing brace at the end of the file.

## Fix Focus Areas
- src/Components/test/E2ETest/ServerExecutionTests/WebSocketCompressionTests.cs[16-18]
- src/Components/test/E2ETest/ServerExecutionTests/WebSocketCompressionTests.cs[208-210]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

2. Xcode path/name mismatch 🐞 Bug ⛯ Reliability

• The macOS pipeline step claims to use Xcode 16.4.0 but still selects the Xcode 15.2.0 developer
  directory, making CI behavior misleading and harder to debug.
• This is duplicated in both public and internal job definitions, so the inconsistency affects all
  macOS runs.
• With the move to macOS-15 images, keeping an old Xcode path increases the chance of macOS CI
  breakage if that Xcode bundle is not present.

Agent prompt

### Issue description
The macOS pipeline step labels itself as using Xcode 16.4.0 but still selects `/Applications/Xcode_15.2.0.app/...`, which is inconsistent and can mislead troubleshooting.

### Issue Context
This appears in both the public and internal job template sections and coincides with upgrading macOS agents to macOS-15.

### Fix Focus Areas
- .azure/pipelines/jobs/default-build.yml[165-167]
- .azure/pipelines/jobs/default-build.yml[391-393]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

3. Baseline validation disabled 🐞 Bug ✓ Correctness

• Servicing builds now set ValidateBaseline=false, which disables the guardrail that enforces the
  baseline matches the previous release.
• The checked-in baseline is still 9.0.0, while the repo is configured for 10.0.1 servicing;
  disabling validation masks this drift and risks incorrect dependency/version coherency decisions
  during servicing.
• This can allow servicing builds to proceed with an outdated baseline rather than forcing the
  baseline regeneration/update that the build system expects.

Agent prompt

### Issue description
`ValidateBaseline` is disabled for a servicing branch while the checked-in baseline version indicates drift (still 9.0.0). This bypasses an explicit servicing build check intended to force baseline updates.

### Issue Context
Servicing builds rely on baseline coherency for reference/version restrictions. The repo already contains an MSBuild target that enforces baseline freshness when `ValidateBaseline` is true.

### Fix Focus Areas
- eng/Versions.props[10-16]
- eng/Baseline.Designer.props[1-6]
- eng/Baseline.xml[1-15]
- eng/targets/Packaging.targets[3-12]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

4. Build002 gated to patch1 🐞 Bug ✓ Correctness

• The BUILD002 error (preventing removed baseline references in servicing) is now gated behind
  AspNetCorePatchVersion == 1.
• For later servicing patches (10.0.2+), this disables the stated policy enforcement (“not allowed
  in a servicing update”), increasing risk of shipping breaking dependency removals in a patch.
• This is a long-term regression: the first patch remains checked, but subsequent patches silently
  lose the guardrail.

Agent prompt

### Issue description
The BUILD002 servicing safety check is restricted to patch version 1 only, disabling enforcement for subsequent servicing patches.

### Issue Context
BUILD002’s message states the behavior is “not allowed in a servicing update”, which should apply across all servicing patch versions.

### Fix Focus Areas
- eng/targets/ResolveReferences.targets[210-213]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools