Skip to content

Added note about caching to DllImportResolver #11864

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 29, 2025
Merged

Added note about caching to DllImportResolver #11864

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions xml/System.Runtime.InteropServices/DllImportResolver.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,6 +39,8 @@
The runtime does not do any lifetime management around the handle returned by a <xref:System.Runtime.InteropServices.DllImportResolver>. It is left to the implementation and consuming code to keep the library loaded for as long as necessary and free it if/when desired.
The resolver delegate is called everytime when a PInvoke call is done. It is fine to cache the handle, as long as the consuming code does not call <xref:System.Runtime.InteropServices.NativeLibrary.Free>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The resolver delegate is called every time when a PInvoke call is done.

This does not look right.

The resolver is called first time a PInvoke call is done. It is not called every time PInvoke call is done.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also please change everytime to "every time".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The resolver is called first time a PInvoke call is done. It is not called every time PInvoke call is done.

Ah, I mis-interpreted the (debug) output from dotnet/runtime#86088 (comment) and from my test program.

test program 
using System.Reflection;
using System.Runtime.InteropServices;

for (int i = 0; i < 10; ++i)
{
    string version = Native.GetVersion();
    int versionNumber = Native.cairo_version();

    Console.WriteLine($"{version}\t{versionNumber}");
}

internal static unsafe partial class Native
{
    [LibraryImport("cairo")]
    internal static partial int cairo_version();

    [LibraryImport("cairo")]
    internal static partial sbyte* cairo_version_string();
    public static string GetVersion() => new string(cairo_version_string());

    static Native()
    {
        NativeLibrary.SetDllImportResolver(Assembly.GetExecutingAssembly(), static (libraryName, assembly, searchPath) =>
        {
            Console.WriteLine($"DllResolver called for lib {libraryName}");

            return 0;
        });
    }
}

In a larger project I saw a call to the resolver quite often, but actually it's called the first time a native method is called, not every time.

So for $n$ entrypoints for the same library, the resolver will be called $n$ times.
And to avoid repeated building of paths, etc. the returned handle can be cached e.g. in a static field, as long the library is not unloaded.

Now I understand how it works. Maybe the woding isn't perfect here, but I'll open a PR that corrects this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Runtime does not take any locks around the resolver callback, so the resolver callback can be called from multiple threads at the same time for the same entrypoint.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is fine to cache the handle, as long as the consuming code does not call

This looks misleading without the context from the discussion that this was copied from.

Where is it fine to cache the handle? What is the consuming code?

]]></format>
</remarks>
</Docs>
Expand Down
Loading