From 525127ea367a483db5b8eecac6b4095d44da4a85 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Mon, 27 Jul 2026 19:35:59 +0000 Subject: [PATCH 1/3] doc: explain Assembly.LoadFrom AssemblyResolve handler ordering behavior --- docs/core/dependency-loading/loading-managed.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/core/dependency-loading/loading-managed.md b/docs/core/dependency-loading/loading-managed.md index 73f5281109187..e77159c607610 100644 --- a/docs/core/dependency-loading/loading-managed.md +++ b/docs/core/dependency-loading/loading-managed.md @@ -33,6 +33,9 @@ The direct use of the following APIs will also trigger loads: > [!IMPORTANT] > Unlike .NET Framework, the `assemblyFile` parameter of is treated as a file path in .NET, not a URI. In .NET Framework, you can pass a file URI (for example, `file:///C:/path/to/assembly.dll`)—such as one constructed from —and the assembly loads successfully. In .NET, the `assemblyFile` value is passed to , which doesn't properly handle URIs, so the load fails. If you already have a file URI string, first create a instance and use its property to get the file path before calling . To get the file path of an already-loaded assembly, use instead of `CodeBase`. +> [!NOTE] +> When you call , the runtime registers an handler at that point. Handlers for are invoked in registration order. The first handler that returns a non-null assembly ends the resolution. If you register your own handler before calling `LoadFrom`, your handler is invoked first. If your handler returns `null`, the `LoadFrom` handler is invoked next and might resolve the dependency from the same directory as the loaded assembly. This means that you might see the event fire for a dependency even when your own handler returned `null` for it—because another registered handler (such as the one from `LoadFrom`) successfully resolved it afterward. + ## Algorithm The following algorithm describes how the runtime loads a managed assembly. From 39653e00288fc4eb9a7a44d1fffa7a29a2cac881 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Tue, 28 Jul 2026 18:08:40 +0000 Subject: [PATCH 2/3] doc: move handler-ordering info into algorithm section --- docs/core/dependency-loading/loading-managed.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/docs/core/dependency-loading/loading-managed.md b/docs/core/dependency-loading/loading-managed.md index e77159c607610..54a07f087e40a 100644 --- a/docs/core/dependency-loading/loading-managed.md +++ b/docs/core/dependency-loading/loading-managed.md @@ -33,9 +33,6 @@ The direct use of the following APIs will also trigger loads: > [!IMPORTANT] > Unlike .NET Framework, the `assemblyFile` parameter of is treated as a file path in .NET, not a URI. In .NET Framework, you can pass a file URI (for example, `file:///C:/path/to/assembly.dll`)—such as one constructed from —and the assembly loads successfully. In .NET, the `assemblyFile` value is passed to , which doesn't properly handle URIs, so the load fails. If you already have a file URI string, first create a instance and use its property to get the file path before calling . To get the file path of an already-loaded assembly, use instead of `CodeBase`. -> [!NOTE] -> When you call , the runtime registers an handler at that point. Handlers for are invoked in registration order. The first handler that returns a non-null assembly ends the resolution. If you register your own handler before calling `LoadFrom`, your handler is invoked first. If your handler returns `null`, the `LoadFrom` handler is invoked next and might resolve the dependency from the same directory as the loaded assembly. This means that you might see the event fire for a dependency even when your own handler returned `null` for it—because another registered handler (such as the one from `LoadFrom`) successfully resolved it afterward. - ## Algorithm The following algorithm describes how the runtime loads a managed assembly. @@ -52,8 +49,8 @@ The following algorithm describes how the runtime loads a managed assembly. - Check its `cache-by-name`. - Call the function. - Check the instance's cache and run [managed assembly default probing](default-probing.md#managed-assembly-default-probing) logic. If an assembly is newly loaded, a reference is added to the instance's `cache-by-name`. - - Raise the event for the active AssemblyLoadContext. - - Raise the event. + - Raise the event for the active AssemblyLoadContext. Handlers are invoked in registration order. The first handler that returns a non-null assembly ends the resolution. + - Raise the event. Handlers are invoked in registration order. The first handler that returns a non-null assembly ends the resolution. Note that registers its own handler for this event when called, so if you register your own handler first, your handler is invoked before the `LoadFrom` handler. 3. For the other types of loads, the `active` loads the assembly in the following priority order: From 27b4a7b51536226d10a7ee5a016ea7fea1420f78 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Tue, 28 Jul 2026 18:17:11 +0000 Subject: [PATCH 3/3] doc: drop redundant LoadFrom note from AssemblyResolve bullet --- docs/core/dependency-loading/loading-managed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core/dependency-loading/loading-managed.md b/docs/core/dependency-loading/loading-managed.md index 54a07f087e40a..6b8518b1983cf 100644 --- a/docs/core/dependency-loading/loading-managed.md +++ b/docs/core/dependency-loading/loading-managed.md @@ -50,7 +50,7 @@ The following algorithm describes how the runtime loads a managed assembly. - Call the function. - Check the instance's cache and run [managed assembly default probing](default-probing.md#managed-assembly-default-probing) logic. If an assembly is newly loaded, a reference is added to the instance's `cache-by-name`. - Raise the event for the active AssemblyLoadContext. Handlers are invoked in registration order. The first handler that returns a non-null assembly ends the resolution. - - Raise the event. Handlers are invoked in registration order. The first handler that returns a non-null assembly ends the resolution. Note that registers its own handler for this event when called, so if you register your own handler first, your handler is invoked before the `LoadFrom` handler. + - Raise the event. Handlers are invoked in registration order. The first handler that returns a non-null assembly ends the resolution. 3. For the other types of loads, the `active` loads the assembly in the following priority order: