Skip to content

Tags: dotnet/runtime

Tags

v9.0.16

Toggle v9.0.16's commit message
Merged PR 60607: Updated Versions.props - MicrosoftNativeQuicMsQuicSc…

…hannelVersion 2.4.18

Updated Versions.props -  MicrosoftNativeQuicMsQuicSchannelVersion 2.4.18

----
#### AI description  (iteration 1)
#### PR Classification
Dependency version update to upgrade the MsQuic Schannel package from version 2.4.17 to 2.4.18.

#### PR Summary
This pull request updates the MsQuic Schannel dependency to a newer patch version.

- `/eng/Versions.props`: Updated `MicrosoftNativeQuicMsQuicSchannelVersion` from 2.4.17 to 2.4.18
<!-- GitOpsUserAgent=GitOps.Apps.Server.pullrequestcopilot -->

v8.0.27

Toggle v8.0.27's commit message
Merged PR 60606: Updated Versions.props - MicrosoftNativeQuicMsQuicSc…

…hannelVersion 2.4.18

Updated Versions.props -  MicrosoftNativeQuicMsQuicSchannelVersion 2.4.18

----
#### AI description  (iteration 1)
#### PR Classification
Dependency version update to upgrade the MsQuic Schannel package from version 2.4.17 to 2.4.18.

#### PR Summary
This pull request updates the MsQuic Schannel dependency version in the project's version management file.

- `eng/Versions.props`: Updated `MicrosoftNativeQuicMsQuicSchannelVersion` from 2.4.17 to 2.4.18
<!-- GitOpsUserAgent=GitOps.Apps.Server.pullrequestcopilot -->

v11.0.0-preview.4.26230.115

Toggle v11.0.0-preview.4.26230.115's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
[release/11.0-preview4] Source code updates from dotnet/dotnet (#127418)

> [!NOTE]
> This is a codeflow update. It may contain both source code changes
from
> [the VMR](https://github.com/dotnet/dotnet)
> as well as dependency updates. Learn more
[here](https://github.com/dotnet/dotnet/tree/main/docs/Codeflow-PRs.md).

This pull request brings the following source code changes

[marker]: <> (Begin:fe554d4f-fa8f-4629-9931-ec015ceb97fa)

## From https://github.com/dotnet/dotnet
- **Subscription**:
[fe554d4f-fa8f-4629-9931-ec015ceb97fa](https://maestro.dot.net/subscriptions?search=fe554d4f-fa8f-4629-9931-ec015ceb97fa)
- **Build**:
[20260424.22](https://dev.azure.com/dnceng/internal/_build/results?buildId=2959731)
([311857](https://maestro.dot.net/channel/9588/github:dotnet:dotnet/build/311857))
- **Date Produced**: April 25, 2026 6:28:19 AM UTC
- **Commit**:
[48bd87d899e187fe0e4e2b81a7b4a65a37845213](dotnet/dotnet@48bd87d)
- **Commit Diff**:
[36afe73...48bd87d](dotnet/dotnet@36afe73...48bd87d)
- **Branch**:
[release/11.0.1xx-preview4](https://github.com/dotnet/dotnet/tree/release/11.0.1xx-preview4)

**Updated Dependencies**
- From [5.7.0-1.26211.102 to 5.7.0-1.26224.122][1]
  - Microsoft.CodeAnalysis
  - Microsoft.CodeAnalysis.Analyzers
  - Microsoft.CodeAnalysis.CSharp
  - Microsoft.Net.Compilers.Toolset
- From [11.0.100-preview.4.26211.102 to 11.0.100-preview.4.26224.122][1]
  - Microsoft.CodeAnalysis.NetAnalyzers
  - Microsoft.DotNet.ApiCompat.Task
- Microsoft.NET.Workload.Emscripten.Current.Manifest-11.0.100.Transport
- From [11.0.0-beta.26211.102 to 11.0.0-beta.26224.122][1]
  - Microsoft.DotNet.Arcade.Sdk
  - Microsoft.DotNet.Build.Tasks.Archives
  - Microsoft.DotNet.Build.Tasks.Feed
  - Microsoft.DotNet.Build.Tasks.Installers
  - Microsoft.DotNet.Build.Tasks.Packaging
  - Microsoft.DotNet.Build.Tasks.TargetFramework
  - Microsoft.DotNet.Build.Tasks.Templating
  - Microsoft.DotNet.Build.Tasks.Workloads
  - Microsoft.DotNet.CodeAnalysis
  - Microsoft.DotNet.GenAPI
  - Microsoft.DotNet.GenFacades
  - Microsoft.DotNet.Helix.Sdk
  - Microsoft.DotNet.PackageTesting
  - Microsoft.DotNet.RemoteExecutor
  - Microsoft.DotNet.SharedFramework.Sdk
  - Microsoft.DotNet.XliffTasks
  - Microsoft.DotNet.XUnitExtensions
- From [0.11.5-preview.26211.102 to 0.11.5-preview.26224.122][1]
  - Microsoft.DotNet.Cecil
- From [3.2.2-beta.26211.102 to 3.2.2-beta.26224.122][1]
  - Microsoft.DotNet.XUnitAssert
- From [2.9.3-beta.26211.102 to 2.9.3-beta.26224.122][1]
  - Microsoft.DotNet.XUnitConsoleRunner
- From [11.0.0-preview.4.26211.102 to 11.0.0-preview.4.26224.122][1]
  - Microsoft.NET.Sdk.IL
  - Microsoft.NETCore.App.Ref
  - Microsoft.NETCore.ILAsm
  - runtime.native.System.IO.Ports
  - System.Reflection.Metadata
  - System.Reflection.MetadataLoadContext
  - System.Text.Json
- From [7.6.0-rc.21202 to 7.7.0-rc.22522][1]
  - NuGet.Frameworks
  - NuGet.Packaging
  - NuGet.ProjectModel
  - NuGet.Versioning
- From [3.0.0-preview.4.26211.102 to 3.0.0-preview.4.26224.122][1]
  - System.CommandLine
- From [19.1.0-alpha.1.26173.1 to
19.1.0-alpha.1.26208.2](dotnet/dotnet@adb0185...db9a80a)
  - runtime.linux-arm64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
  - runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.JIT.Tools
- runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
  - runtime.linux-musl-x64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
  - runtime.linux-x64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
  - runtime.osx-arm64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
  - runtime.osx-x64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
  - runtime.win-arm64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.win-x64.Microsoft.NETCore.Runtime.JIT.Tools
  - runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Libclang
  - runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk
  - runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools
- From [11.0.0-alpha.1.26173.2 to
11.0.0-alpha.1.26208.5](dotnet/dotnet@0077cd1...cfe285c)
  - runtime.linux-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
  - runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
  - runtime.linux-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
  - runtime.osx-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
  - runtime.osx-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
  - runtime.win-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
  - runtime.win-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport

[marker]: <> (End:fe554d4f-fa8f-4629-9931-ec015ceb97fa)

[1]: dotnet/dotnet@36afe73...48bd87d
[marker]: <> (Start:Footer:CodeFlow PR)

## Associated changes in source repos
-
dotnet/arcade@30f8bf5...a08169b
-
dotnet/aspnetcore@3b9acb9...11a9d22
-
dotnet/cecil@82f47fc...187393d
-
dotnet/command-line-api@d3de878...99db1e3
-
dotnet/efcore@ebc5a87...c945994
-
dotnet/emsdk@4cdda38...5258a0e
-
dotnet/fsharp@1f46886...ec82b94
-
dotnet/msbuild@8a330c4...933255e
-
NuGet/NuGet.Client@779eff1...de3b92c
-
dotnet/razor@1eaf86c...229087c
-
dotnet/roslyn@e3a102f...5e5ee32
-
ce3e716...a28fe52
-
dotnet/scenario-tests@5745f74...7bc6a69
-
dotnet/sdk@a1f2e26...e259547
-
dotnet/symreader@e87544a...ddef017
-
dotnet/templating@695767d...4c17ee5
-
microsoft/vstest@5c5c4f1...4b1316b
-
dotnet/windowsdesktop@8350252...c96077e
-
dotnet/winforms@9bff4e6...2f889a2
-
dotnet/wpf@7bb98f6...6eaec56
-
dotnet/xdt@a37116d...0d57d4b

<details>
<summary>Diff the source with this PR branch</summary>

```bash
darc vmr diff --name-only https://github.com/dotnet/dotnet:48bd87d899e187fe0e4e2b81a7b4a65a37845213..https://github.com/dotnet/runtime:darc-release/11.0-preview4-fc6d5772-ad96-4a2e-861f-40d0c2998897
```
</details>

[marker]: <> (End:Footer:CodeFlow PR)

---------

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Larry Ewing <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Michal Strehovský <[email protected]>

v10.0.8

Toggle v10.0.8's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
[Release/10.0] Pass down DJI and MethodDesc to avoid unnecessary PtrH…

…ashMap lookup (#126247)

Fixes #126096

main fixes this issue via #123492
- a different approach that's too risky for servicing.
#123651 had tried a targeted
approach and this completes the targeted fix for the path.

# Description

PR #123651 fixed the `GetJitInfo` call in `BindPatch` to avoid a
deadlock-prone `HashMap::LookupValue` -> `GCCoopHackNoThread` ->
`DisablePreemptiveGC` path while holding the DebuggerController lock.
However, the same function has a second call to
`CodeRegionInfo::GetCodeRegionInfo(NULL, NULL, startAddr)` that follows
the exact same deadlock path when `dji` is NULL, `GetCodeRegionInfo`
calls `InitializeFromStartAddress` -> `GetMethodRegionInfo` ->
`EECodeInfo` constructor -> `ReadyToRunJitManager::JitCodeToMethodInfo`
-> `HashMap::LookupValue` -> GC cooperative mode transition.

This one-line fix passes the already-available `info` (DebuggerJitInfo)
and `pMD` (MethodDesc) to `GetCodeRegionInfo`, matching every other
callsite in controller.cpp. When `info` is non-null and has a cached
`m_addrOfCode`, `GetCodeRegionInfo` returns the cached
`m_codeRegionInfo` immediately without constructing an `EECodeInfo`,
avoiding the HashMap and the GC mode transition entirely. The change in
#126249 tries to find other
locations that can face this issue. So far, they are all around the
thread starter added in r2r delay call transitions. This change fixes
most of those cases.

# Customer Impact

Without this fix, customers debugging ReadyToRun applications can
experience debugger hangs. The deadlock occurs when:

1. A thread holds the DebuggerController lock in `BindPatch` (e.g.,
during `MapAndBindFunctionPatches` from `JITComplete` or
`AddBindAndActivateILReplicaPatch`)
2. `GetCodeRegionInfo` constructs an `EECodeInfo` for a R2R method,
entering `HashMap::LookupValue` which transitions to GC cooperative mode
3. A GC or debugger suspension is pending `DisablePreemptiveGC` ->
`RareDisablePreemptiveGC` -> `WaitSuspendEvents` blocks indefinitely
4. Other threads waiting on the DebuggerController lock (or the GC
needing threads at safe points) deadlock

The result is the debugger and IDE hang, requiring force-close and loss
of the debugging session.

# Regression

No. The root cause has existed since ReadyToRun support was added. The
original issue (#123650) notes that timing changes may have made it more
likely to hit recently, but this specific `GetCodeRegionInfo` path has
always been vulnerable. The bug has become a lot more visible in 10.0
nonetheless.

# Testing

- The fix is a single-line change that passes already-available local
variables (`info`, `pMD`) to `GetCodeRegionInfo` instead of `(NULL,
NULL)`, matching all other callsites in controller.cpp (see lines ~6173,
~6219, ~8054 for the same pattern).
- Debugger tests pass with this change.

# Risk

**Very Low.** This is a one-line change that passes two existing local
variables to a function instead of NULL. The `info` and `pMD` variables
are already computed earlier in the same function and used in the lines
immediately surrounding this call. Every other `GetCodeRegionInfo`
callsite in controller.cpp already passes the DJI and MethodDesc. The
only effect is avoiding an unnecessary `EECodeInfo` construction (and
its HashMap lookup) when cached data is available.

v11.0.0-preview.3.26207.106

Toggle v11.0.0-preview.3.26207.106's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
[release/11.0-preview3] Fix publish-time Framework materialization fo…

…r multi-client WASM and add test (#126378)

Backport of #126211 to release/11.0-preview3

/cc @lewing

## Customer Impact

- [ ] Customer reported
- [ ] Found internally

[Select one or both of the boxes. Describe how this issue impacts
customers, citing the expected and actual behaviors and scope of the
issue. If customer-reported, provide the issue number.]

## Regression

- [ ] Yes
- [ ] No

[If yes, specify when the regression was introduced. Provide the PR or
commit if known.]

## Testing

[How was the fix verified? How was the issue missed previously? What
tests were added?]

## Risk

[High/Medium/Low. Justify the indication by mentioning how risks were
measured and addressed.]

**IMPORTANT**: If this backport is for a servicing release, please
verify that:

- For .NET 8 and .NET 9: The PR target branch is `release/X.0-staging`,
not `release/X.0`.
- For .NET 10+: The PR target branch is `release/X.0` (no `-staging`
suffix).

## Package authoring no longer needed in .NET 9

**IMPORTANT**: Starting with .NET 9, you no longer need to edit a NuGet
package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older
versions.

---------

Co-authored-by: Larry Ewing <[email protected]>
Co-authored-by: Copilot <[email protected]>

v9.0.15

Toggle v9.0.15's commit message
Merge commit '152085126a3dc5063aac6e9ae9ed2cda2be2f4bf'

v10.0.7

Toggle v10.0.7's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
[release/10.0] Fix bug in LowerCallMemmove (#125175)

Backport of #123907 to
release/10.0 to fix #123748

/cc @EgorBo

## Customer Impact

- [x] Customer reported
- [ ] Found internally

JIT crashes with an access violation (0xC0000005) when compiling calls
to C++/CLI functions returning structs with aggregate initialization.
The crash occurs in `LowerCallMemmove` during JIT compilation because
`BlkOpKindUnroll` was used for `CORINFO_HELP_MEMCPY`, which bypasses the
memmove-aware lowering paired with `genCodeForMemmove`. This leads to
contained address nodes being passed where non-contained nodes are
expected, causing the null dereference.

## Regression

- [x] Yes
- [ ] No

## Fix

Use `BlkOpKindUnrollMemmove` uniformly for both `Memmove` and `MEMCPY`
helpers. While slightly more expensive for LSRA (no addressing modes),
`CORINFO_HELP_MEMCPY` is rarely used, so the impact is negligible. Also
adds asserts to catch contained address nodes early.

## Testing

No diffs in [SPMI
replay](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1287687&view=ms.vss-build-web.run-extensions-tab).
Verified on main via PR #123907.

## Risk

Low. The change makes memcpy use the same safe code path as memmove,
which is already well-tested. The only behavioral difference is slightly
different register allocation for the rare `CORINFO_HELP_MEMCPY` case.

Co-authored-by: egorbot <[email protected]>
Co-authored-by: Copilot <[email protected]>

v8.0.26

Toggle v8.0.26's commit message
Merge commit 'fcdfb09f932c592f5f69e2ca8f1bd54165796b04'

v11.0.0-preview.2.26159.112

Toggle v11.0.0-preview.2.26159.112's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
[release/11.0-preview2] Revert "Increase number of assertions (Global…

…AP) + VN cache (#124132)" (#124955)

Backport of #124928 to release/11.0-preview2

/cc @akoeplinger @AndyAyersMS

## Customer Impact

- [ ] Customer reported
- [x] Found internally

This was causing excessive memory allocation during jitting (see
dotnet/dotnet#4933).
## Regression

- [X] Yes
- [ ] No

Caused by:
92741be

## Testing

Manual testing.

## Risk

Low. Reverts an earlier change.

[High/Medium/Low. Justify the indication by mentioning how risks were
measured and addressed.]

**IMPORTANT**: If this backport is for a servicing release, please
verify that:

- For .NET 8 and .NET 9: The PR target branch is `release/X.0-staging`,
not `release/X.0`.
- For .NET 10+: The PR target branch is `release/X.0` (no `-staging`
suffix).

## Package authoring no longer needed in .NET 9

**IMPORTANT**: Starting with .NET 9, you no longer need to edit a NuGet
package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older
versions.

Co-authored-by: Andy Ayers <[email protected]>