Skip to content

[release/10.0] Pass correct search path to DllImportResolver for default flags on Mono#129862

Open
github-actions[bot] wants to merge 1 commit into
release/10.0from
backport/pr-129831-to-release/10.0
Open

[release/10.0] Pass correct search path to DllImportResolver for default flags on Mono#129862
github-actions[bot] wants to merge 1 commit into
release/10.0from
backport/pr-129831-to-release/10.0

Conversation

@github-actions

@github-actions github-actions Bot commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

Backport of #129831 to release/10.0

/cc @elinor-fung

Customer Impact

  • Customer reported
  • Found internally

Customer reported in #129798.

On Mono, when no search flags are user-specified, the runtime ends up passing an explicit DllImportSeachPath.AssemblyDirectory value was passed to any registered DllImportResolver instead of null. The expected DllImportResolver contract is that search path is the attribute value, or null when neither the P/Invoke nor the assembly has the attribute.

Before #114756, specifying only DllImportSearchPath.AssemblyDirectory would still do the default search, so the Mono behaviour of explicitly passing AssemblyDirectory instead of null didn't really matter. After that change, specifying only DllImportSeachPath.AssemblyDirectory meant only assembly directory. This means that when a resolver that forwards the (wrongly non-null) AssemblyDirectory to NativeLibrary.Load, it no longer does the default search.

This change propagates the tracking of whether flags were user-specified to the resolver invocation, so the resolver is given the attribute value or null for non-user-specified.

Fixes #129798

Regression

  • Yes
  • No

#114756

Testing

Automated tests added.

Risk

Low. Mono-only, propagating a boolean value correctly.

When neither the P/Invoke nor the assembly has a DefaultDllImportSearchPaths
attribute, Mono passed DllImportSearchPath.AssemblyDirectory to a registered
DllImportResolver instead of null. lookup_pinvoke_call_impl defaults the flags
to ASSEMBLY_DIRECTORY for the built-in probing logic, and
netcore_resolve_with_dll_import_resolver derived "has search flags" from
(flags != 0), so the defaulted value leaked to the resolver.

Combined with #114756 - which made an explicit AssemblyDirectory no longer fall
back to the OS search - this broke resolvers that forward the search path to
NativeLibrary.Load, such as loading iOS @rpath frameworks.

Thread the existing user_specified_flags signal through to the resolver so it
receives the attribute value, or null when none was specified, matching CoreCLR
and NativeAOT.

Fixes #129798

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@elinor-fung elinor-fung added Servicing-consider Issue for next servicing release review area-Interop-mono and removed area-VM-meta-mono labels Jun 25, 2026
@elinor-fung elinor-fung added this to the 10.0.x milestone Jun 25, 2026
@elinor-fung elinor-fung linked an issue Jun 25, 2026 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-Interop-mono Servicing-consider Issue for next servicing release review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Native Library loading IOS Frameworks in .NET 10

3 participants