Repository navigation
Correct MetadataLoadContext docs on binding loaded assemblies - #13154
Merged
Merged
Conversation
Updated remarks and summaries for assembly loading methods to clarify that loading an assembly doesn't bind its name and that references are resolved through the MetadataAssemblyResolver.
dotnet-policy-service
Bot
added
the
community-contribution
jkotas
reviewed
Oct 8, 2026
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The documentation accurately matches the implementation and linked runtime tests.
0 open findings
What changed in this PR
Corrects MetadataLoadContext documentation to reflect resolver-controlled assembly binding.
Changes:
- Clarifies that loading an assembly doesn’t bind its name.
- Documents resolver-only reference resolution and cached failures.
- Updates summaries to present tense.
| File | Description |
|---|---|
xml/System.Reflection/MetadataLoadContext.xml |
Corrects assembly binding and resolution documentation. |
🧠 Review effort: Balanced
Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.
jkotas
reviewed
Oct 8, 2026
jkotas
reviewed
Oct 9, 2026
Use the suggested wording in the LoadFromAssemblyPath, LoadFromByteArray and LoadFromStream remarks.
gewarren
approved these changes
Oct 9, 2026
Member
|
@gewarren System.Reflection.MetadataLoadContext is relatively small assembly/package without legacy baggage. Do you think it would make sense to move its docs to dotnet/runtime? Would the script/process that you have been working on be able to handle it? |
caraioniurie47
added a commit
to caraioniurie47/runtime-kos
that referenced
this pull request
Oct 10, 2026
Take the class summary and the LoadFrom* resolution remark from the wording merged in dotnet/dotnet-api-docs#13154. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Collaborator
I will try to get it done this month. |
caraioniurie47
added a commit
to caraioniurie47/runtime-kos
that referenced
this pull request
Oct 13, 2026
Port the rest of dotnet/dotnet-api-docs#13154 into the doc comments: drop the ReflectionOnlyLoad note from both LoadFromAssemblyName overloads, and say "the prior assembly is returned" in the LoadFromAssemblyPath, LoadFromByteArray and LoadFromStream summaries. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
jkotas
pushed a commit
to dotnet/runtime
that referenced
this pull request
Oct 13, 2026
Since dotnet/corefx#33734, loading an assembly into a `MetadataLoadContext` doesn't bind its name: a name is bound only to the assembly the `MetadataAssemblyResolver` returns for it. The `FileNotFoundAssembly` message and the `LoadFrom*` doc comments still say otherwise, so following the message's advice to load the assembly first changes nothing. ### Changes - `FileNotFoundAssembly` now says the resolver didn't return the assembly, and that a loaded assembly is used for the name only if the resolver returns it. - The class and `LoadFrom*` doc comments no longer say loading binds the name, and the `LoadFromAssemblyName` ones note that a null result from the resolver is remembered. Two typos are fixed ("bound by to", "has already loaded been loaded"). - New test `ResolverReturnsNullForLoadedAssembly`. This includes the `LoadFrom*` doc edits from #129050, which was approved but closed without being merged. The published docs come from dotnet/dotnet-api-docs for this library; the same doc corrections are in dotnet/dotnet-api-docs#13154. Resolves #113353 > [!NOTE] > AI-generated, written at my direction and reviewed by me before posting. The tests above ran on a local Windows x64 build of this branch. --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
MetadataLoadContext.LoadFromAssemblyPath,LoadFromByteArray, andLoadFromStreamare documented as binding the loaded assembly's name, and the type remarks say names are bound to assemblies "that were previously loaded into the context". That hasn't been true since dotnet/corefx#33734: a name is bound only to the assembly theMetadataAssemblyResolverreturns for it, so loading a dependency first doesn't by itself satisfy a later reference to it. dotnet/runtime#113353 reports this.LoadFrom*summaries no longer say the name is bound and use the present tense, and each one's remarks say that references are resolved only through the resolver.LoadFromAssemblyNameoverloads note that a null result from the resolver is remembered.The same corrections to the source comments and the exception message are in dotnet/runtime#135237.
Contributes to dotnet/runtime#113353
Note
AI-generated, written at my direction and reviewed by me before posting. The binding behaviour was checked on .NET 10.0.12 with the System.Reflection.MetadataLoadContext 10.0.12 package, and the remembered failure by a test in dotnet/runtime#135237.
Internal previews
Build report