Skip to content
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.

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

Different DLL names on native dlls for multiple platforms #111833

Closed
jogibear9988 opened this issue Jan 25, 2025 · 4 comments
Closed

Different DLL names on native dlls for multiple platforms #111833

jogibear9988 opened this issue Jan 25, 2025 · 4 comments
Labels
area-System.Runtime.InteropServices question Answer questions and provide assistance, not an issue with source code or documentation.

Comments

@jogibear9988
Copy link

jogibear9988 commented Jan 25, 2025

I try to use a native dll (openssl) on different platforms, and my assembly should also support net 4.7

Now is there a way, to specify different dll names for each platform, but keep the dotnet included native dll resolver?

Problem is, openssl has different dll names on each platform.

And I don't like to copy the the whole imports.

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Jan 25, 2025
Copy link
Contributor

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

@jkotas
Copy link
Member

jkotas commented Jan 26, 2025

my assembly should also support net 4.7

There is no good built-in way to do this in .NET Framework 4.7.

The best you can do is to multi-target your assembly: one build configuration that targets Windows .NET Framework 4.7, and one configuration that targets modern .NET and takes advantage of all new APIs as appropriate (including System.Runtime.InteropServices.NativeLibrary APIs designed for this scenario)

It is the approach that we use to solve issues like this in packages published by this repo. For example, System.Data.Odbc package includes multiple configurations: https://github.com/dotnet/runtime/blob/main/src/libraries/System.Data.Odbc/src/System.Data.Odbc.csproj#L4. The Unix configurations have custom native library loading logic: https://github.com/dotnet/runtime/blob/main/src/libraries/Common/src/Interop/Unix/Interop.Odbc.cs#L17-L36 .

@jkotas jkotas closed this as completed Jan 26, 2025
@jkotas jkotas added the question Answer questions and provide assistance, not an issue with source code or documentation. label Jan 26, 2025
@dotnet-policy-service dotnet-policy-service bot removed the untriaged New issue has not been triaged by the area owner label Jan 26, 2025
@jkotas jkotas added area-System.Runtime.InteropServices question Answer questions and provide assistance, not an issue with source code or documentation. and removed question Answer questions and provide assistance, not an issue with source code or documentation. area-Interop-coreclr labels Jan 26, 2025
@huoyaoyuan
Copy link
Member

On .NET Core, you can use SetDllImportResolver or AssemblyLoadContext.ResolvongUnmanagedDll to handle the name difference on different operating systems.

@MichalPetryka
Copy link
Contributor

For .Net Framework/Standard you can also PInvoke into LoadLibrary/dlopen instead and then call the method via cached function pointers like if you'd use NativeLibrary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-System.Runtime.InteropServices question Answer questions and provide assistance, not an issue with source code or documentation.
Projects
Status: No status
Development

No branches or pull requests

4 participants